Re: Exercising Version Negotiation

[Ryan Hamilton <[e-mail]>]

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]> 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]> 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]> on behalf of Ryan Hamilton <rch=
> [e-mail]>
> *Date: *Monday, March 26, 2018 at 1:05 PM
> *To: *Roberto Peon <[e-mail]>
> *Cc: *Eric Rescorla <[e-mail]>, IETF QUIC WG <[e-mail]>, Mike
> Bishop <[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]> 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?
>
>
>
>
>
>
>