Re: Exercising Version Negotiation

[Roberto Peon <[e-mail]>]

I was thinking that you’d advertise different versions based on the client IP and day, including the alt-svc stuff, thus (as you point out) the QUIC version negotiation logic would match up with the alt-svc logic.
This depends to some extent on how we actually advertise QUIC in alt-svc (e.g. do we advertise all versions, or just say ‘quic’, and let the client sort it out?).

I’d imagine that 33% of the time, a particular IP will see ALT-SVC: v+, and QUIC will negotiate v+. 33% of the time, that IP will see ALT-SVC: v+, v- and QUIC will negotiate either, etc.
I suspect that there are better proposals which could exercise more of the state space (v-, v+ advertised instead of v+, v-, etc.), but the overall mechanism would be the same—a particular client sees the world as a slowly changing rainbow of version combinations.

-=R

From: Ryan Hamilton <[e-mail]>
Date: Monday, March 26, 2018 at 11:38 AM
To: Roberto Peon <[e-mail]>
Cc: Eric Rescorla <[e-mail]>, IETF QUIC WG <[e-mail]>, Mike Bishop <[e-mail]>
Subject: Re: Exercising Version Negotiation

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]<mailto:[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]<mailto:[e-mail]>> on behalf of Ryan Hamilton <rch=[e-mail]<mailto:[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]<mailto:[e-mail]>> wrote:

Wouldn’t it be best to do all 3 combinations? ☺

-=R



From: QUIC <[e-mail]<mailto:[e-mail]>> on behalf of Ryan Hamilton <rch=[e-mail]<mailto:[e-mail]>>
Date: Friday, March 23, 2018 at 1:20 PM
To: Eric Rescorla <[e-mail]<mailto:[e-mail]>>
Cc: IETF QUIC WG <[e-mail]<mailto:[e-mail]>>, Mike Bishop <[e-mail]<mailto:[e-mail]>>
Subject: Re: Exercising Version Negotiation



On Fri, Mar 23, 2018 at 1:48 AM, Eric Rescorla <[e-mail]<mailto:[e-mail]>> wrote:

On Thu, Mar 22, 2018 at 8:53 PM, Ryan Hamilton <[e-mail]<mailto:[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?