Re: alternative service probability parameter

For anything stable for experimental selection,  it seems you'd want a seed
that mixes in also communicated as you don't want hosts to always be opted
in to everyone's rollouts and experiments.   Anything per-client
deterministic seems like it could be a path to identify users if not

Sent from my mobile device
On May 8, 2015 5:09 PM, "Ryan Hamilton" <> wrote:

> On Fri, May 8, 2015 at 12:49 PM, Amos Jeffries <>
> wrote:
>> On 9/05/2015 1:37 a.m., Bence Béky wrote:
>> > Hello httpbis,
>> >
>> > This is a heads up about a parameter that we have been using in
>> > Alternate-Protocol headers, and are planning to use in Alt-Svc headers
>> > and ALTSVC frames.  It is "p=" (probability), that Google servers emit
>> > and Chrome observes.  This takes a numerical value between 0.0 and 1.0
>> > inclusive, and tells the client to only observe the alternative
>> > service with that given probability (and ignore it otherwise).  This
>> > parameter can be used for finer grade load balancing, for gradual
>> > rollout of a new protocol, and for performance testing.
>> Why not reusing the standard qvalue / ranking, like other standard
>> documents do?
>>   <>
> ​Interesting idea! I can definitely see reusing the syntax, but I suspect
> it needs some added semantics. In particular, the way we use p= at Google
> is to ​make sure that if p=.5 then 50% of users will use the alternative
> and 50% will not. But more strongly than that, we need to have all users in
> the "use it" group to use it for all servers that advertise p=.5. Because
> page loads often pull in resources from multiple domains/server it is
> critical that we be able to do realistic A/B comparisons. From reading the
> qvalue section it doesn't sound like it fits exactly. But I could imagine a
> small change to the Alt-Svc draft to clarify this in the Alt-Svc context.
> The other question I have is if we want to do 50% use the alternative 50%
> don't, I assume we would need to emit 2 alternatives both with the same q=
> value. The first is the "real" alternative, the second is the default
> protocol. Is that how you would imagine this working?
> Cheers,
> Ryan

Received on Friday, 8 May 2015 22:05:57 UTC