Re: Exercising Version Negotiation

[Roberto Peon <[e-mail]>]

There are any number of ways it could be done. I’m just proposing one!
2b happens as often as you want it to happen. I’m proposing one makes it happen once a week or so.
You could force that set of the IP population to do the version negotiation for a new connections during a particular minute each week, for instance
-=R


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

I think that ekr's proposal was directed only at 2b.  Namely:

It would exercise the former.

-Ekr

On Thu, Mar 22, 2018 at 2:10 PM, Ryan Hamilton <[e-mail]<mailto:[e-mail]>> wrote:
When you say Version Negotiation, do you mean the process of sending an receiving a version negotiation packet, or simply the act of speaking two different versions? Your proposal seems to be the latter but I don't think I follow how it would exercise the former, though maybe that's intentional?

​So while #1 and #2a are interesting, I'm specifically trying to understand the case ekr originally proposed, namely sending and receiving a version negotiation packet (aka #2b). If servers use Alt-Svc and, as you say, that prevents on the wire version negotiation (2b) then it doesn't sound like we're achieving the objective initially proposed, are we?

On Mon, Mar 26, 2018 at 3:04 PM, Roberto Peon <[e-mail]<mailto:[e-mail]>> wrote:
There are two sets of entities that we’re greasing.

  1.  Middleboxes
  2.  Implementation endpoints.

#1 is greased whenever multiple versions are spoken by any set of clients/servers
#2 is greased whenever the client/server use multiple versions simultaneously. There is a subset of the problems space which is negotiation. Within negotiation there are two subsets:

  1.  Negotiation where the client picks something it likes
  2.  Negotiation where the client must throw away old state and use something new.

Users incur a hit only when 2b happens. <bad joke> 2b or not 2b, that is the question. </bad joke>
How often we pick 2b is the question. If we’re slowly rotating between versions, then how often depends on which path the client uses to know it should do QUIC.
If it is being told to use a version via alt-svc, then we’re unlikely to see the QUIC version negotiation happen on the wire.
If it is not told via alt-svc, then, once a week or so (if following my example), the client will learn that its version is no longer the version the server wishes to speak. It will incur that penalty once per week per connection per ip.

-=R

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

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]<mailto:[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]<mailto:[e-mail]>>
Date: Monday, March 26, 2018 at 11:38 AM
To: Roberto Peon <[e-mail]<mailto:[e-mail]>>
Cc: Eric Rescorla <[e-mail]<mailto:[e-mail]>>, IETF QUIC WG <[e-mail]<mailto:[e-mail]>>, Mike Bishop <[e-mail]<mailto:[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?