Re: Exercising Version Negotiation

[Ryan Hamilton <[e-mail]>]

Mixing day as well as client IP into the experiment group function makes
sense, but it's not clear to me how this only ends up impacted 1 connection
per day, because of Alt-Svc. Is it your vision that the server will
advertise v- and v+ for all users, or will the QUIC version negotiation
logic match up with the Alt-Svc advertisement logic? I ask because if the
server keeps advertising v- and v+, and the client prefers, say v+, I would
imagine that the client would attempt to use v+ on each new connection
attempt.

On Fri, Mar 23, 2018 at 3:35 PM, Roberto Peon <[e-mail]> wrote:

> This is roughly what I'm thinking:
>
> auto versions = std::vector<std::string>();
>
> int day = date_as_unix_epoch_in_ms() / ms_in_day;
>
> int day_mod = (day + hash(client_ip)) % 3;
>
> switch (day_mod) {
>
>   case 0:
>
>     versions.push_back("v+");
>
>     break;
>
>   case 1:
>
>     versions.push_back("v-");
>
>     break;
>
>   case 2:
>
>     versions.push_back("v+");
>
>     versions.push_back("v-");
>
>     break;
> }
>
> With such a scheme, the client would incur an extra RTT on a new
> connection once a day.
>
> -=R
> ------------------------------
> *From:* QUIC <[e-mail]> on behalf of Ryan Hamilton <rch=
> [e-mail]>
> *Sent:* Friday, March 23, 2018 3:26:59 PM
> *To:* Roberto Peon
> *Cc:* Eric Rescorla; IETF QUIC WG; Mike Bishop
> *Subject:* Re: Exercising Version Negotiation
>
> Maybe. :) I'm just trying to get my arms around a concrete proposal. For
> example, if the server always advertises both versions, but only supports 1
> version based on hash(client IP), and those client typically prefer the
> other version, then they'll incur an extra RTT on every connection, which
> seems undesirable. But I'm not sure if that's the proposal.
>
> On Fri, Mar 23, 2018 at 2:00 PM, Roberto Peon <[e-mail]> wrote:
>
> Wouldn’t it be best to do all 3 combinations? ☺
>
> -=R
>
>
>
> *From: *QUIC <[e-mail]> on behalf of Ryan Hamilton <rch=
> [e-mail]>
> *Date: *Friday, March 23, 2018 at 1:20 PM
> *To: *Eric Rescorla <[e-mail]>
> *Cc: *IETF QUIC WG <[e-mail]>, Mike Bishop <[e-mail]>
> *Subject: *Re: Exercising Version Negotiation
>
>
>
> On Fri, Mar 23, 2018 at 1:48 AM, Eric Rescorla <[e-mail]> wrote:
>
> On Thu, Mar 22, 2018 at 8:53 PM, Ryan Hamilton <[e-mail]> wrote:
>
> Agreed. As specified, I don't see how the server would be induced to send
> a version negotiation packet in this case. Ekr, perhaps you can provide
> some sample flows. If the server supports versions A and B, and the client
> supports versions A and B, then it doesn't matter which version the client
> prefers. In either case, the server supports the version the client is
> attempting to speak and will not send a version negotiation packet.
>
>
>
> I'm not suggesting that you flip the preferences, but rather that the each
> side configure itself with one version for a given connection. This is
> obviously trivial for a client. For the server, you can just hash the
> client's IP address to get a stable choice.
>
>
>
> ​Ah, I misunderstood what you meant by, "We would then suggest to people
> that they somewhat randomize their preferences (e.g., 99% of the time
> prefer v1+i, 1% of the time prefer v1-i)."
>
>
>
> How would you envision this working with Alt-Svc advertisements? Would the
> server advertise support for both versions but only support a single one,
> or would it advertise only the single version?
>
>
>