Re: Exercising Version Negotiation

[Ryan Hamilton <[e-mail]>]

So if a client sees Alt-Svc v+, and the server supports v+, then there will
be no version negotiation. Same for:
  Alt-Svc v- Server supports v-
  Alt-Svc v+, v- Server supports v+, v-
I think we'll only get version negotiation when the client attempts to
speak a version of QUIC that the server does not support. But the client
will only attempt to speak a version of QUIC that the server advertises. So
to get negotiation we need one of:
  Alt-Svc v+,v- Server supports v- (client prefers v+)
​  ​
Alt-Svc v-
​, v+​
Server supports v
​+​ (client prefers v-)
​If this is the setup, I think that every connection the client makes to
the server will incur a version negotiation 1-RTT hit. I don't think it
will be only a single hit per day. Can you explain how this setup will only
impact the client once per day (for connections to this server?)

Cheers,

Ryan

On Mon, Mar 26, 2018 at 12:18 PM, Roberto Peon <[e-mail]> wrote:

> 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]> 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?
>
>
>
>
>