Subject: Exercising Version Negotiation

From: Eric Rescorla <[email-masked]>
Date: Thu, 22 Mar 2018 12:03:36 +0000

Following up on the discussion at the mic, I do think it is useful to
exercise the VN function, but I don't think it's useful to have those
versions be different, because that creates perverse incentives.

Here's what I suggest instead: create two versions (we can call them QUIC
v1+i  and QUIC v1-i), each with its own code point [0]. They should be
essentially identical except for two trivial differences, intended to
ensure that if you screw up version negotiation, you get failed interop.

- The constant in the handshake salt (5.2.2)
- The HKDF expansion constants

I suggest we handle each of these by just inverting the bits.

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). This will almost always result in matching versions, but will
occasionally result in a mismatch, thus forcing us to test VN.

-Ekr

[0] Obviously we can do this for draft versions. We just say that the two
versions are
ff0000XX and ffffffXX.

---

From: Ryan Hamilton <[email-masked]>
Date: Thu, 22 Mar 2018 07:10:20 -0700

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?

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 22 Mar 2018 14:25:53 +0000

It would exercise the former.

-Ekr

---

From: Mike Bishop <[email-masked]>
Date: Thu, 22 Mar 2018 15:46:18 +0000

Technically, no, it wouldn’t.  Servers accept if they’re capable/willing to speak the version the client selected, so a server that supports both would always accept no matter what the client chooses.  You’d need the server to be contrarian a small percentage of the time instead.

From: QUIC <[email-masked]> On Behalf Of Eric Rescorla
Sent: Thursday, March 22, 2018 2:26 PM
To: Ryan Hamilton <[email-masked]>
Cc: IETF QUIC WG <[email-masked]>
Subject: Re: Exercising Version Negotiation

-Ekr

On Thu, Mar 22, 2018 at 2:10 PM, Ryan Hamilton <[email-masked]<mailto:[email-masked]>> 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?

On Thu, Mar 22, 2018 at 5:03 AM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:
Following up on the discussion at the mic, I do think it is useful to exercise the VN function, but I don't think it's useful to have those versions be different, because that creates perverse incentives.

Here's what I suggest instead: create two versions (we can call them QUIC v1+i  and QUIC v1-i), each with its own code point [0]. They should be essentially identical except for two trivial differences, intended to ensure that if you screw up version negotiation, you get failed interop.

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). This will almost always result in matching versions, but will occasionally result in a mismatch, thus forcing us to test VN.

-Ekr

[0] Obviously we can do this for draft versions. We just say that the two versions are
ff0000XX and ffffffXX.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 22 Mar 2018 16:07:33 +0000

Without referring to any of the details that smarter people than me are
chatting their way through, I'd like to thank EKR for sending this note.

Now that I have 80-percent confidence that QUIC can close on how, and when,
the working group will engage on the Spin Bit when Lars and Mark say, "it's
time", our ability to negotiate off gQUIC and onto IETF QUICv1, and off
QUICv1 and onto QUICv1,1 or QUICv2, is the only thing in QUIC that I'm
losing sleep about.

I mentioned this in the first QUIC session this week, and expect that most
people who saw that were spinning on the Spin Bit and didn't notice, which
is fine. I trust the chairs to manage that topic at the appropriate time,
but I would really like for that to not be a late surprise for QUICv1, at
an inappropriate time.

Thanks,

Spencer, sending perhaps his last email to QUIC speaking as the responsible
AD for this IETF week ...

---

From: Roberto Peon <[email-masked]>
Date: Thu, 22 Mar 2018 16:19:57 +0000

Love it. This is a great idea!

I'd suggest being more agressive with deployment,  e.g. recommend that servers negotiate speaking version +1 to more like 50% of the clients, and swap guid/ip mappings to have clients formerly using +1 switch  to -1 and vice versa weekly or so.

-=R

Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone

-------- Original message --------
From: Eric Rescorla <[email-masked]>
Date: 3/22/18 5:05 AM (GMT-08:00)
To: IETF QUIC WG <[email-masked]>
Subject: Exercising Version Negotiation

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 22 Mar 2018 16:45:14 +0000

Hi Subodh,

I'm sorry, I'm not following you. I'm not talking about the spin bit here,
just about exercising the regular negotiation function.

-Ekr

On Thu, Mar 22, 2018 at 4:26 PM, Subodh Iyengar <[email-masked]> wrote:

> I don't think using version negotiation is as simple as it seems:
>
>
>    1. My understanding is that the current draft and the data that was
>    shown doesn't even look at the handshake negotiation and only looks at
>    short headers.
>    2. Short headers have no version. So to use version negotiation
>    correctly as a signal of the spin bit, the middlebox MUST intercept the
>    handshake negotiation.
>    3. Each 5 tuple could potentially have multiple connections and we are
>    apparently designing for that use case, so the middlebox needs to use
>    connection id
>    4. Some implementations are thinking of changing connection ids very
>    frequently, maybe in each RTT.
>
>
> Given these are we saying that when using the spin version you must not
> change the conn id per RTT so that the middlebox can observe the spin?
>
>
> Subodh
>
> ------------------------------
> *From:* QUIC <[email-masked]> on behalf of Roberto Peon <
> [email-masked]>
> *Sent:* Thursday, March 22, 2018 9:19:57 AM
> *To:* Eric Rescorla; IETF QUIC WG
> *Subject:* [Potential Spoof] Re: Exercising Version Negotiation
>
> I'd suggest being more agressive with deployment,  e.g. recommend that
> servers negotiate speaking version +1 to more like 50% of the clients, and
> swap guid/ip mappings to have clients formerly using +1 switch  to -1 and
> vice versa weekly or so.
>
> -=R
>
>
>

---

From: Subodh Iyengar <[email-masked]>
Date: Thu, 22 Mar 2018 16:49:53 +0000

My understanding is that your proposal says that the interpretation of a particular bit in the public header is determined by the version, i.e. the server and client will negotiate a particular version if they need a spin bit. What I was saying is that if that is true, the middlebox needs to look at the negotiated version and hence creates the aforementioned concerns.

Subodh

________________________________
From: Eric Rescorla <[email-masked]>
Sent: Thursday, March 22, 2018 9:45:14 AM
To: Subodh Iyengar
Cc: Roberto Peon; IETF QUIC WG
Subject: Re: Exercising Version Negotiation

Hi Subodh,

I'm sorry, I'm not following you. I'm not talking about the spin bit here, just about exercising the regular negotiation function.

-Ekr

On Thu, Mar 22, 2018 at 4:26 PM, Subodh Iyengar <[email-masked]<mailto:[email-masked]>> wrote:

  1.  My understanding is that the current draft and the data that was shown doesn't even look at the handshake negotiation and only looks at short headers.
  2.  Short headers have no version. So to use version negotiation correctly as a signal of the spin bit, the middlebox MUST intercept the handshake negotiation.
  3.  Each 5 tuple could potentially have multiple connections and we are apparently designing for that use case, so the middlebox needs to use connection id
  4.  Some implementations are thinking of changing connection ids very frequently, maybe in each RTT.

Given these are we saying that when using the spin version you must not change the conn id per RTT so that the middlebox can observe the spin?

Subodh

________________________________
From: QUIC <[email-masked]<mailto:[email-masked]>> on behalf of Roberto Peon <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, March 22, 2018 9:19:57 AM
To: Eric Rescorla; IETF QUIC WG
Subject: [Potential Spoof] Re: Exercising Version Negotiation

-=R

-------- Original message --------
From: Eric Rescorla <[email-masked]<mailto:[email-masked]>>
Date: 3/22/18 5:05 AM (GMT-08:00)
To: IETF QUIC WG <[email-masked]<mailto:[email-masked]>>
Subject: Exercising Version Negotiation

-Ekr

---

From: Subodh Iyengar <[email-masked]>
Date: Thu, 22 Mar 2018 16:53:15 +0000

Oh sorry i completely misunderstood what you're saying, ignore my previous email.

Subodh

________________________________
From: QUIC <[email-masked]> on behalf of Subodh Iyengar <[email-masked]>
Sent: Thursday, March 22, 2018 9:49:53 AM
To: Eric Rescorla
Cc: IETF QUIC WG; Roberto Peon
Subject: [Potential Spoof] Re: Exercising Version Negotiation

Subodh

Hi Subodh,

-Ekr

Subodh

-=R

-------- Original message --------
From: Eric Rescorla <[email-masked]<mailto:[email-masked]>>
Date: 3/22/18 5:05 AM (GMT-08:00)
To: IETF QUIC WG <[email-masked]<mailto:[email-masked]>>
Subject: Exercising Version Negotiation

-Ekr

---

From: Subodh Iyengar <[email-masked]>
Date: Thu, 22 Mar 2018 16:26:32 +0000

Subodh

From: QUIC <[email-masked]> on behalf of Roberto Peon <[email-masked]>

-=R

-------- Original message --------
From: Eric Rescorla <[email-masked]>
Date: 3/22/18 5:05 AM (GMT-08:00)
To: IETF QUIC WG <[email-masked]>
Subject: Exercising Version Negotiation

-Ekr

---

From: Ian Swett <[email-masked]>
Date: Thu, 22 Mar 2018 17:18:26 +0000

I think you were poking holes in my suggestion from this morning :)  And I
agree that's an issue.

!Ekr

On Thu, Mar 22, 2018 at 12:53 PM Subodh Iyengar <[email-masked]> wrote:

> *From:* QUIC <[email-masked]> on behalf of Subodh Iyengar <
> [email-masked]>
> *Sent:* Thursday, March 22, 2018 9:49:53 AM
> *To:* Eric Rescorla
> *Cc:* IETF QUIC WG; Roberto Peon
> My understanding is that your proposal says that the interpretation of a
> particular bit in the public header is determined by the version, i.e. the
> server and client will negotiate a particular version if they need a spin
> bit. What I was saying is that if that is true, the middlebox needs to look
> at the negotiated version and hence creates the aforementioned concerns.
>
>
> Subodh
> *From:* Eric Rescorla <[email-masked]>
> *Sent:* Thursday, March 22, 2018 9:45:14 AM
> *To:* Subodh Iyengar
> *Cc:* Roberto Peon; IETF QUIC WG
> *Subject:* Re: Exercising Version Negotiation
>
> Hi Subodh,
>

---

From: Subodh Iyengar <[email-masked]>
Date: Thu, 22 Mar 2018 17:22:23 +0000

> Just curious, what is the use case for this? I assume the server still controls its own connection ID and would prefer to keep it consistent for routing purposes.

I feel bad for hijacking ekr's thread. But you can have an algorithm that generates multiple connection ids that route to the same server. We can discuss the use cases for this on another thread.

!Ekr

________________________________
From: Ian Swett <[email-masked]>
Sent: Thursday, March 22, 2018 10:18:26 AM
To: Subodh Iyengar
Cc: Eric Rescorla; IETF QUIC WG; Roberto Peon
Subject: Re: Exercising Version Negotiation

I think you were poking holes in my suggestion from this morning :)  And I agree that's an issue.

!Ekr

On Thu, Mar 22, 2018 at 12:53 PM Subodh Iyengar <[email-masked]<mailto:[email-masked]>> wrote:

Subodh

From: QUIC <[email-masked]<mailto:[email-masked]>> on behalf of Subodh Iyengar <[email-masked]<mailto:[email-masked]>>

Subodh

Hi Subodh,

-Ekr

Subodh

-=R

-------- Original message --------
From: Eric Rescorla <[email-masked]<mailto:[email-masked]>>
Date: 3/22/18 5:05 AM (GMT-08:00)
To: IETF QUIC WG <[email-masked]<mailto:[email-masked]>>
Subject: Exercising Version Negotiation

-Ekr

---

From: "Lubashev, Igor" <[email-masked]>
Date: Thu, 22 Mar 2018 18:53:42 +0000

I think technically this is correct that when “the interpretation of a public header [by middleboxes] determined by version”, the middleboxes must be stateful.

However, in this particular case, I see three possible outcomes (if we stick to the London decision).

  1.  Spin Bit text reaches consensus by the time V1 text is ready, and it gets incorporated into V1, so there is no issue.
  2.  Spin Bit “dies in committee” (or is replaced by something very different that we cannot anticipate now), so there is no issue.
  3.  Spin Bit is late for V1, but reaches consensus rather soon after V1 and makes it into V1.1.  In this case, there are probably not many (none) deployed production implementations, and all in-progress implementations will implement V1.1, since it is such an easy change.  So there is no V1 “in the wild”, so there is no issue.

  *   Igor

From: Ian Swett [mailto:ianswett=[email-masked]]
Sent: Thursday, March 22, 2018 5:18 PM
To: Subodh Iyengar <[email-masked]>
Cc: Eric Rescorla <[email-masked]>; IETF QUIC WG <[email-masked]>; Roberto Peon <[email-masked]>
Subject: Re: Exercising Version Negotiation

!Ekr

Subodh

Subodh

Hi Subodh,

-Ekr

Subodh

-=R

-------- Original message --------
From: Eric Rescorla <[email-masked]<mailto:[email-masked]>>
Date: 3/22/18 5:05 AM (GMT-08:00)
To: IETF QUIC WG <[email-masked]<mailto:[email-masked]>>
Subject: Exercising Version Negotiation

-Ekr

---

From: "Lubashev, Igor" <[email-masked]>
Date: Thu, 22 Mar 2018 18:53:42 +0000

*   Igor

!Ekr

Subodh

Subodh

Hi Subodh,

-Ekr

Subodh

-=R

-------- Original message --------
From: Eric Rescorla <[email-masked]<mailto:[email-masked]>>
Date: 3/22/18 5:05 AM (GMT-08:00)
To: IETF QUIC WG <[email-masked]<mailto:[email-masked]>>
Subject: Exercising Version Negotiation

-Ekr

---

From: Ryan Hamilton <[email-masked]>
Date: Thu, 22 Mar 2018 13:53:39 -0700

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.

Further, it's complicated for the server to (some fraction of the time)
send a VN packet in response to a connection attempt that uses a version
the server actually does support. It will, obviously, need to exclude this
version from the VN packet it sends to the client. That's easy. But it also
needs to ensure that the list of QUIC versions it provides in the
subsequent TLS handshake matches this version list. This, I suspect, is
more complicated as version negotiation is typically stateless.

On Thu, Mar 22, 2018 at 8:46 AM, Mike Bishop <[email-masked]> wrote:

> Technically, no, it wouldn’t.  Servers accept if they’re capable/willing
> to speak the version the client selected, so a server that supports both
> would always accept no matter what the client chooses.  You’d need the
> server to be contrarian a small percentage of the time instead.
>
>
>
> *From:* QUIC <[email-masked]> *On Behalf Of * Eric Rescorla
> *Sent:* Thursday, March 22, 2018 2:26 PM
> *To:* Ryan Hamilton <[email-masked]>
> *Cc:* IETF QUIC WG <[email-masked]>

---

From: Ryan Hamilton <[email-masked]>
Date: Thu, 22 Mar 2018 13:54:31 -0700

Version Negotiation adds 1-RTT to the connection attempt, so I don't think
that's practical for 50% of connections.

---

From: "Lubashev, Igor" <[email-masked]>
Date: Thu, 22 Mar 2018 23:45:06 +0000

The easiest solution is the client sometimes trying a bogus version. It would be fully under client's control when to engage in such network policing.

-----Original Message-----
From: Ryan Hamilton [rch=[email-masked]]
Received: Thursday, 22 Mar 2018, 8:53PM
To: Mike Bishop [[email-masked]]
CC: Eric Rescorla [[email-masked]]; IETF QUIC WG [[email-masked]]
Subject: Re: Exercising Version Negotiation

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.

Further, it's complicated for the server to (some fraction of the time) send a VN packet in response to a connection attempt that uses a version the server actually does support. It will, obviously, need to exclude this version from the VN packet it sends to the client. That's easy. But it also needs to ensure that the list of QUIC versions it provides in the subsequent TLS handshake matches this version list. This, I suspect, is more complicated as version negotiation is typically stateless.

On Thu, Mar 22, 2018 at 8:46 AM, Mike Bishop <[email-masked]<mailto:[email-masked]>> wrote:
Technically, no, it wouldn't.  Servers accept if they're capable/willing to speak the version the client selected, so a server that supports both would always accept no matter what the client chooses.  You'd need the server to be contrarian a small percentage of the time instead.

From: QUIC <[email-masked]<mailto:[email-masked]>> On Behalf Of Eric Rescorla
Sent: Thursday, March 22, 2018 2:26 PM
To: Ryan Hamilton <[email-masked]<mailto:[email-masked]>>
Cc: IETF QUIC WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: Exercising Version Negotiation

-Ekr

-Ekr

---

From: "Lubashev, Igor" <[email-masked]>
Date: Thu, 22 Mar 2018 23:45:06 +0000

-----Original Message-----
From: Ryan Hamilton [rch=[email-masked]]
Received: Thursday, 22 Mar 2018, 8:53PM
To: Mike Bishop [[email-masked]]
CC: Eric Rescorla [[email-masked]]; IETF QUIC WG [[email-masked]]
Subject: Re: Exercising Version Negotiation

-Ekr

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 23 Mar 2018 08:48:03 +0000

On Thu, Mar 22, 2018 at 8:53 PM, Ryan Hamilton <[email-masked]> 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

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.

-Ekr

---

From: Ryan Hamilton <[email-masked]>
Date: Fri, 23 Mar 2018 13:19:20 -0700

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

---

From: Roberto Peon <[email-masked]>
Date: Fri, 23 Mar 2018 21:00:29 +0000

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

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

On Fri, Mar 23, 2018 at 1:48 AM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:
On Thu, Mar 22, 2018 at 8:53 PM, Ryan Hamilton <[email-masked]<mailto:[email-masked]>> 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?

---

From: Roberto Peon <[email-masked]>
Date: Fri, 23 Mar 2018 21:00:29 +0000

---

From: Ryan Hamilton <[email-masked]>
Date: Fri, 23 Mar 2018 15:26:59 -0700

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 <[email-masked]> wrote:

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

---

From: Roberto Peon <[email-masked]>
Date: Fri, 23 Mar 2018 22:35:24 +0000

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

-=R

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

---

From: Roberto Peon <[email-masked]>
Date: Fri, 23 Mar 2018 22:35:24 +0000

switch (day_mod) {

  case 0:

    break;

  case 1:

    break;

  case 2:

    break;
}

-=R

-=R

---

From: Christian Huitema <[email-masked]>
Date: Sat, 24 Mar 2018 11:30:37 +0000

On 3/23/2018 10:26 PM, Ryan Hamilton wrote:

> 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.

There is of course no way to exercise version negotiation without
incurring a 1-RTT penalty. Following the "use it or lose it" paradigm,
we know that if we do not use version negotiation for a while, various
middle-boxes will "learn" that it is not needed and will start blocking
VN packets, in the same way that various middle boxes block various ICMP
packets today. Greasing VN has a cost. If we grease VN for X% of
connections, X% of connections will suffer an additional 1-RTT delay.
There is just no way around it.

Let's assume that we will grease VN on X% of connections. How do we
decide how much that X% is? If it is too low, middle-boxes will learn
that blocking VN only affects a small fraction of connections. They will
think that they can block it, and clients will probably react by
retrying with a different version. Grease fails. If it is too high, too
many clients suffer. So we need some kind of Goldilocks value, not too
big, not too high, just right. Anything below 1% will probably be too
low, but I don't know what would be too high. 5%? 10%? The trade-off is
not very appealing.

Perhaps we should look at it differently. What do we really want to
teach to the middle-boxes? I think the message should really be, "do not
try to lock on a specific version number". And doing that with just two
versions will not work. The middle boxes will just learn those two
versions, and we will not be able to introduce a third one. We want to
see plenty of mostly unpredictable versions proposed by clients, and we
want these unpredictable version numbers to result in successful
connections most of the time.

-- Christian Huitema

---

From: Mike Bishop <[email-masked]>
Date: Sat, 24 Mar 2018 14:45:04 +0000

There's already language in the HTTP/QUIC spec suggesting that servers include reserved versions in the Alt-Svc header.  Clients will, of course, tend to ignore those as versions they don't speak.  But it seems like our starting point ought to be that clients will, with some probability, offer one of the reserved versions as their first Initial and let the server negotiate to one (or several) defined versions.

-----Original Message-----
From: QUIC <[email-masked]> On Behalf Of Christian Huitema
Sent: Saturday, March 24, 2018 5:31 AM
To: [email-masked]
Subject: Re: Exercising Version Negotiation

> every connection, which seems undesirable. But I'm not sure if that's 

There is of course no way to exercise version negotiation without incurring a 1-RTT penalty. Following the "use it or lose it" paradigm, we know that if we do not use version negotiation for a while, various middle-boxes will "learn" that it is not needed and will start blocking VN packets, in the same way that various middle boxes block various ICMP packets today. Greasing VN has a cost. If we grease VN for X% of connections, X% of connections will suffer an additional 1-RTT delay.
There is just no way around it.

Let's assume that we will grease VN on X% of connections. How do we decide how much that X% is? If it is too low, middle-boxes will learn that blocking VN only affects a small fraction of connections. They will think that they can block it, and clients will probably react by retrying with a different version. Grease fails. If it is too high, too many clients suffer. So we need some kind of Goldilocks value, not too big, not too high, just right. Anything below 1% will probably be too low, but I don't know what would be too high. 5%? 10%? The trade-off is not very appealing.

Perhaps we should look at it differently. What do we really want to teach to the middle-boxes? I think the message should really be, "do not try to lock on a specific version number". And doing that with just two versions will not work. The middle boxes will just learn those two versions, and we will not be able to introduce a third one. We want to see plenty of mostly unpredictable versions proposed by clients, and we want these unpredictable version numbers to result in successful connections most of the time.

-- Christian Huitema

---

From: Ryan Hamilton <[email-masked]>
Date: Mon, 26 Mar 2018 11:36:52 -0700

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 <[email-masked]> wrote:

> *From:* QUIC <[email-masked]> on behalf of Ryan Hamilton <rch=
> *Sent:* Friday, March 23, 2018 3:26:59 PM
> *To:* Roberto Peon
> *Cc:* Eric Rescorla; IETF QUIC WG; Mike Bishop

---

From: Roberto Peon <[email-masked]>
Date: Mon, 26 Mar 2018 19:08:35 +0000

What the user cares about is the quality of the experience. This is influenced by the number of times the version changes for them.
That is de-coupled from the number of versions deployed simultaneously across all users.
Thus, have x == 50%. Use as many versions as equally as possible. Sometimes use both.

So long as the rate of change on an individual user/IP basis is slow enough, the user won't see any real performance penalty or degraded experience.
As an example, I think that changing version negotiation on someone once a week would be pretty safe.

Agreed that we want to teach middle-boxes to not expect a specific version. Agreed we need a Goldilocks value (caveated with above). 
We also want to teach *clients* to not expect a single version. Ekr's suggestion of really deploying two versions makes it likely that most endpoint implementations (and not just middleboxes) would build the appropriate scaffolding to deal with versioning.
-=R

On 3/24/18, 4:31 AM, "QUIC on behalf of Christian Huitema" <[email-masked] on behalf of [email-masked]> wrote:

    

    
    -- Christian Huitema

---

From: Roberto Peon <[email-masked]>
Date: Mon, 26 Mar 2018 19:18:47 +0000

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

switch (day_mod) {

  case 0:

    break;

  case 1:

    break;

  case 2:

    break;
}

-=R

-=R

---

From: Ryan Hamilton <[email-masked]>
Date: Mon, 26 Mar 2018 13:04:32 -0700

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

---

From: Ted Hardie <[email-masked]>
Date: Mon, 26 Mar 2018 21:30:05 +0100

> connections most of the time.

So, the key second part to this question is "what am I willing to pay to
teach the middleboxes this?"  Everyone in the thread agrees that the basic
currency is round trips, but we seem to be divided on what the going rate
is (in percentage of flows that should pay).

I have a terrible idea about that, but it does shift the currency from
"round trips" to "additional connections".  The precis is:  exercise
version negotiation by opening additional connections that use the
functionality.

In this model,  a client with a successful open connection to server $foo
knows what versions it supports and can construct a flow that will incur
version negotiation.  Periodically, it will open such a flow, successfully
negotiate a version after paying the RTT, then ask for a small set of
resources which it already has.  It can throw them out at the end, as they
will not impact application functionality (since this is all on the main
flow).  If it is in a constrained environment (low available bandwidth,
battery, etc.), it can skip the whole thing.

Middleboxes will thus see some number of flows that exercise version
negotiations, but the impact to the application running QUIC is small.  The
impact on the network is variable to the tuning of the rate.

Some potential objections:

The middlebox operators will read the spec and decide they can ignore these
flows entirely.
While this is possible, nat variability will mean middleboxes at later
stages of the path may not see these as on the same 5-tuple, and so
ignoring them will be hard.

This is too expensive in client and server resources, since the data will
be tossed.
This is subject to tuning, so the expense can be managed.  You could also
decide to use the second connection to retrieve newly needed resources, if
the application is appropriate to that, but deciding when that is
appropriate is fairly difficult.

What connection id do you use for this?
Personally, I'd use a new one, but if we start looking at connection
replacement strategies more generally, we can throw this into the mix.

As I said this is a bad idea, given the potentially wastefulness, but
hopefully it will unstick a better one.

Ted

---

From: Roberto Peon <[email-masked]>
Date: Mon, 26 Mar 2018 22:04:31 +0000

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

Date: Monday, March 26, 2018 at 1:05 PM

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 <[email-masked]<mailto:[email-masked]>> 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?).

-=R

From: Ryan Hamilton <[email-masked]<mailto:[email-masked]>>
Date: Monday, March 26, 2018 at 11:38 AM
To: Roberto Peon <[email-masked]<mailto:[email-masked]>>
Cc: Eric Rescorla <[email-masked]<mailto:[email-masked]>>, IETF QUIC WG <[email-masked]<mailto:[email-masked]>>, Mike Bishop <[email-masked]<mailto:[email-masked]>>

switch (day_mod) {

  case 0:

    break;

  case 1:

    break;

  case 2:

    break;
}

-=R

-=R

---

From: Roberto Peon <[email-masked]>
Date: Mon, 26 Mar 2018 22:04:31 +0000

1.  Middleboxes

-=R

Cheers,

Ryan

-=R

switch (day_mod) {

  case 0:

    break;

  case 1:

    break;

  case 2:

    break;
}

-=R

-=R

---

From: Ryan Hamilton <[email-masked]>
Date: Mon, 26 Mar 2018 15:32:15 -0700

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

-Ekr

> 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 <[email-masked]> wrote:

> #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:
>
> 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
>
>
>
> *Date: *Monday, March 26, 2018 at 1:05 PM
> So if a client sees Alt-Svc v+, and the server supports v+, then there
> will be no version negotiation. Same for:
>
> (e..g. do we advertise all versions, or just say ‘quic’, and let the client
> sort it out?).
>
>

---

From: Ryan Hamilton <[email-masked]>
Date: Mon, 26 Mar 2018 15:32:15 -0700

-Ekr

---

From: Roberto Peon <[email-masked]>
Date: Tue, 27 Mar 2018 00:02:21 +0000

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 <[email-masked]>
Date: Monday, March 26, 2018 at 3:33 PM
To: Roberto Peon <[email-masked]>
Cc: Ryan Hamilton <rch=[email-masked]>, Eric Rescorla <[email-masked]>, IETF QUIC WG <[email-masked]>, Mike Bishop <[email-masked]>
Subject: Re: Exercising Version Negotiation

-Ekr

​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 <[email-masked]<mailto:[email-masked]>> wrote:
There are two sets of entities that we’re greasing.

  1.  Middleboxes

-=R

Cheers,

Ryan

-=R

switch (day_mod) {

  case 0:

    break;

  case 1:

    break;

  case 2:

    break;
}

-=R

-=R

---

From: Roberto Peon <[email-masked]>
Date: Tue, 27 Mar 2018 00:02:21 +0000

-Ekr

  1.  Middleboxes

-=R

Cheers,

Ryan

-=R

switch (day_mod) {

  case 0:

    break;

  case 1:

    break;

  case 2:

    break;
}

-=R

-=R

---

From: "Philipp S. Tiesel" <[email-masked]>
Date: Tue, 27 Mar 2018 10:54:31 +0200

> On 26. Mar 2018, at 22:30, Ted Hardie <[email-masked]> wrote:
> 
> On Sat, Mar 24, 2018 at 11:30 AM, Christian Huitema <[email-masked] <mailto:[email-masked]>> wrote:
>  
> So, the key second part to this question is "what am I willing to pay to teach the middleboxes this?"  Everyone in the thread agrees that the basic currency is round trips, but we seem to be divided on what the going rate is (in percentage of flows that should pay).
> 
> I have a terrible idea about that, but it does shift the currency from "round trips" to "additional connections".  The precis is:  exercise version negotiation by opening additional connections that use the functionality.   

I think if you are connection regularly to certain endpoints, one could
also use “the next connection” for greasing. 
 - The server includes a “version alias frame” in the encrypted connection
   that maps regular versions into experimental space
 - The client caches this information and uses it on subsequent connections.

This comes at the risk of accidentally getting involved into experiments, 
but thus also tests parsing error handling ;-)

Other than this, I guess the best  way to really exercise version negotiation
is using experimental versions often. Google has already demonstrated that 
supporting several versions in parallel is feasible, others should be able to
do the same. If all the big players always have some experiments running that
exercise version negotiation, ossifying around this will most likely become
too expensive.

AVE!
  Philipp S. Tiesel / phils…
-- 
   {phils}--->---([email-masked])--->---(http://phils.in-panik.de)----,
      wenn w eine   aube ist dn      man au dran dre en                   |
           o     Schr        an muss     hc         h   (Kurt Schwitters) |
:wq!  <----(phone: +49-179-6737439)---<---(jabber: [email-masked])----'

---

From: Christian Huitema <[email-masked]>
Date: Tue, 27 Mar 2018 12:44:05 -0700

On 3/27/2018 1:54 AM, Philipp S. Tiesel wrote:
>
>
>> On 26. Mar 2018, at 22:30, Ted Hardie <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>> On Sat, Mar 24, 2018 at 11:30 AM, Christian Huitema
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>      
>> So, the key second part to this question is "what am I willing to pay
>> to teach the middleboxes this?"  Everyone in the thread agrees that
>> the basic currency is round trips, but we seem to be divided on what
>> the going rate is (in percentage of flows that should pay).
>>
>> I have a terrible idea about that, but it does shift the currency
>> from "round trips" to "additional connections".  The precis is: 
>> exercise version negotiation by opening additional connections that
>> use the functionality.  
>

I think you are onto something there. If the server publishes something
like "I could also support V=XYZ as an alias for the current version",
the client could remember that and try it next time. This will teach
middle-boxes that it is OK to see various random values in the version
field, and that it is costly to drop packets just because they don't
understand the version.

-- Christian Huitema