Subject: [QUIC] Version Negotiation vs. Option Negotiation

From: Jana Iyengar <[email-masked]>
Date: Tue, 17 May 2016 17:37:12 -0700

Greetings,

I am modifying the charter text that currently says "loss detection and
recovery, congestion control, and negotiation" to say "loss detection and
recovery, congestion control, version negotiation, and option negotiation",
and I wanted to clarify the roles of version negotiation and option
negotiation in the current version of QUIC, since it may be a source of a
bit of confusion.

Version negotiation is used for determining how to read and parse a QUIC
packet. Any "on-the-wire" change to the core protocol or generally any
change that impacts interoperability results in a version change. Version
negotiation, as described in Section 7.1 of draft-tsvwg-quic-protocol-02
<https://tools.ietf.org/html/draft-tsvwg-quic-protocol-02#section-7.1>,
allows the two ends to agree on the version to use for communication. This
is, as Christian puts it, a "blunt" instrument, and it should be treated as
such. Versioning is not generally intended to be used for negotiating the
equivalent of TCP options. The expectation is that versioning will also
allow continued experimentation with QUIC.

I believe that no current IETF transport has versioning.

In addition to versioning, QUIC currently exchanges transport parameters --
the equivalent of TCP options -- during the handshake. This is described,
though not in much detail, in Section 9 of draft-quic-protocol-02
<https://tools.ietf.org/html/draft-tsvwg-quic-protocol-02#section-9>.
Examples of things that may be negotiated via these parameters include max
open streams, among other things. This mechanism may be used for
negotiating features as well, such as use of multipath.

The initial drafts will contain both of these mechanisms.

- jana

---

From: Ian Swett <[email-masked]>
Date: Wed, 18 May 2016 12:03:44 -0400

Thanks Jana, the clarification is appreciated.

On Tue, May 17, 2016 at 8:37 PM, Jana Iyengar <[email-masked]> wrote:

> In addition to versioning, QUIC currently exchanges transport parameters
> -- the equivalent of TCP options -- during the handshake. This is
> described, though not in much detail, in Section 9 of
> draft-quic-protocol-02
> _______________________________________________
> QUIC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/quic
>
>

---

From: Niklas Widell <[email-masked]>
Date: Thu, 19 May 2016 08:48:28 +0000

Hi,
While I understand the need to explicitly identify versions when doing experimentation with a new protocol, I do have a couple of concerns based on the fact that QUIC assumedly will be a very widely deployed protocol:

  *   Keeping client/server versions deployed in synch is no problem if the same entity controls both endpoints and can update them freely (like Google does for QUIC in Chrome today). However, in the wild I expect different versions to be deployed, some in places where they might be very hard to upgrade (like IoT and other embedded devices). I thus see a maintenance headache to keep several simultaneous versions of QUIC server code running just to be able to serve different clients.
  *   Who will bump the version? Is it IETF?
  *   Maybe the idea is to keep increasing the version of QUIC until the QUIC specs are final, and use that final version as THE version that hosts need to implement, but then maybe that should be stated in the charter, or is it implicitly assumed?

Cheers,
Niklas Widell
Ericsson AB

--

On 18/05/16 18:03, "QUIC on behalf of Ian Swett" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

On Tue, May 17, 2016 at 8:37 PM, Jana Iyengar <[email-masked]<mailto:[email-masked]>> wrote:
Greetings,

I am modifying the charter text that currently says "loss detection and recovery, congestion control, and negotiation" to say "loss detection and recovery, congestion control, version negotiation, and option negotiation", and I wanted to clarify the roles of version negotiation and option negotiation in the current version of QUIC, since it may be a source of a bit of confusion.

Version negotiation is used for determining how to read and parse a QUIC packet. Any "on-the-wire" change to the core protocol or generally any change that impacts interoperability results in a version change. Version negotiation, as described in Section 7.1 of draft-tsvwg-quic-protocol-02<https://tools.ietf.org/html/draft-tsvwg-quic-protocol-02#section-7.1>, allows the two ends to agree on the version to use for communication. This is, as Christian puts it, a "blunt" instrument, and it should be treated as such. Versioning is not generally intended to be used for negotiating the equivalent of TCP options. The expectation is that versioning will also allow continued experimentation with QUIC.

In addition to versioning, QUIC currently exchanges transport parameters -- the equivalent of TCP options -- during the handshake. This is described, though not in much detail, in Section 9 of draft-quic-protocol-02<https://tools.ietf.org/html/draft-tsvwg-quic-protocol-02#section-9>. Examples of things that may be negotiated via these parameters include max open streams, among other things. This mechanism may be used for negotiating features as well, such as use of multipath.

- jana

_______________________________________________
QUIC mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/quic

---

From: Niklas Widell <[email-masked]>
Date: Fri, 20 May 2016 13:17:12 +0000

Hi Patrick,
Thanks for the explanation, no reason to worry then I suppose.

Cheers
Niklas

--

On 19/05/16 16:27, "Patrick McManus" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Niklas,

You're basically envisioning the process that was used for versioning http/2 during standardization.. it was known as various "http2-draft-N" with a variety of N's that were negotiated at each connection setup. Each token corresponded to a specific Internet-Draft. The last version was simply renamed "h2" and the draft versions faded from the Internet.

This worked quite well at enabling experimental deployments - especially because the fallback to HTTP/1 was realistically always possible in the case there wasn't a shared version between client and server. Some deployments supported just 1 version at a time, and relied more heavily on HTTP/1 fallback, others offered a small set of options in order to get the most experience possible. This worked very well and could work for this effort too as long as the higher level service had a TCP fallback available. The Internet-Drafts also took the, un-necessary imo, step of declaring some drafts as "for implementation" and others not. There were a few deployments of non-implementable drafts anyhow between consenting peers.

During development this is a much cleaner approach than a matrix of mix and match features negotiated on a per feature basis - especially when you're trying to make sense of the data gathered from the running code.

-Patrick

On Thu, May 19, 2016 at 4:48 AM, Niklas Widell <[email-masked]<mailto:[email-masked]>> wrote:
Hi,
While I understand the need to explicitly identify versions when doing experimentation with a new protocol, I do have a couple of concerns based on the fact that QUIC assumedly will be a very widely deployed protocol:

Cheers,
Niklas Widell
Ericsson AB

--

- jana

---

From: Jana Iyengar <[email-masked]>
Date: Fri, 20 May 2016 15:49:09 -0700

Hi Niklas,

In addition to what Patrick already said about revving versions through the
initial standardization process, one goal of QUIC is to allow iterability
in the protocol beyond the initial standard. I expect that the IETF will
remain the arbiter of new standardized versions, but individual deployments
should be able to do their own experimental versions as well. We will
probably need an IETF-mediated process using which folks can get and use
experimental version numbers, and this is part of the proposed charter of
work.

- jana

On Fri, May 20, 2016 at 6:17 AM, Niklas Widell <[email-masked]>
wrote:

> On 19/05/16 16:27, "Patrick McManus" <[email-masked]> wrote:
>
> Hi Niklas,
>
> You're basically envisioning the process that was used for versioning
> http/2 during standardization.. it was known as various "http2-draft-N"
> with a variety of N's that were negotiated at each connection setup. Each
> token corresponded to a specific Internet-Draft. The last version was
> simply renamed "h2" and the draft versions faded from the Internet.
>
> This worked quite well at enabling experimental deployments - especially
> because the fallback to HTTP/1 was realistically always possible in the
> case there wasn't a shared version between client and server. Some
> deployments supported just 1 version at a time, and relied more heavily on
> HTTP/1 fallback, others offered a small set of options in order to get the
> most experience possible. This worked very well and could work for this
> effort too as long as the higher level service had a TCP fallback
> available. The Internet-Drafts also took the, un-necessary imo, step of
> declaring some drafts as "for implementation" and others not. There were a
> few deployments of non-implementable drafts anyhow between consenting peers.
>
> During development this is a much cleaner approach than a matrix of mix
> and match features negotiated on a per feature basis - especially when
> you're trying to make sense of the data gathered from the running code.
>
> -Patrick
>
>
>
> On Thu, May 19, 2016 at 4:48 AM, Niklas Widell <[email-masked]
> > wrote:
>
>> Hi,
>> While I understand the need to explicitly identify versions when doing
>> experimentation with a new protocol, I do have a couple of concerns based
>> on the fact that QUIC assumedly will be a very widely deployed protocol:
>>
>>
>>    - Keeping client/server versions deployed in synch is no problem if
>>    the same entity controls both endpoints and can update them freely (like
>>    Google does for QUIC in Chrome today). However, in the wild I expect
>>    different versions to be deployed, some in places where they might be very
>>    hard to upgrade (like IoT and other embedded devices). I thus see a
>>    maintenance headache to keep several simultaneous versions of QUIC server
>>    code running just to be able to serve different clients.
>>    - Who will bump the version? Is it IETF?
>>    - Maybe the idea is to keep increasing the version of QUIC until the
>>    QUIC specs are final, and use that final version as THE version that hosts
>>    need to implement, but then maybe that should be stated in the charter, or
>>    is it implicitly assumed?
>>
>>
>> Cheers,
>> Niklas Widell
>> Ericsson AB
>>
>> --
>>
>>
>> On 18/05/16 18:03, "QUIC on behalf of Ian Swett" <[email-masked]
>> on behalf of [email-masked]> wrote:
>>

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 23 May 2016 14:27:34 +1000

Hi Jana,

That's a good clarification.

The word "negotiation" can be read as a certain style of protocol operation by some people; could you just say "protocol versioning and configuration"?

Cheers,

> On 18 May 2016, at 10:37 AM, Jana Iyengar <[email-masked]> wrote:
> 
> Greetings,
> 
> Version negotiation is used for determining how to read and parse a QUIC packet. Any "on-the-wire" change to the core protocol or generally any change that impacts interoperability results in a version change. Version negotiation, as described in Section 7.1 of draft-tsvwg-quic-protocol-02, allows the two ends to agree on the version to use for communication. This is, as Christian puts it, a "blunt" instrument, and it should be treated as such. Versioning is not generally intended to be used for negotiating the equivalent of TCP options. The expectation is that versioning will also allow continued experimentation with QUIC.
> 
> In addition to versioning, QUIC currently exchanges transport parameters -- the equivalent of TCP options -- during the handshake. This is described, though not in much detail, in Section 9 of draft-quic-protocol-02. Examples of things that may be negotiated via these parameters include max open streams, among other things. This mechanism may be used for negotiating features as well, such as use of multipath.
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 23 May 2016 19:36:08 -0700

Hi Mark,

The word "negotiation" can be read as a certain style of protocol operation
> by some people; could you just say "protocol versioning and configuration"?
>

I can see multipath as "configurable" protocol behavior; if folks think
thats reasonable, I'm fine with using "configuration" instead of "options
negotiation".

The use of "versioning" is a bit ambiguous though because it seems to apply
to both the process of creating new versions and the process of negotiating
a version for use. "Versioning" is actually used later in the charter:
"[...] this work will describe a versioning process that enables
distributed experimentation with QUIC."

How about "version negotiation and protocol configuration"?

- jana

---

From: Ian Swett <[email-masked]>
Date: Mon, 23 May 2016 23:34:18 -0400

In TCP, I believe options negotiation is known as options negotiation.  So
unless there is an important difference between QUIC's options and TCP's, I
would prefer the same naming as TCP.  My understanding is that they're
sufficiently similar they should use the same name.

Configuration implies pre-configuration on both ends.  In this case, I
believe we expect clients to offer up new features and have the server
accept or deny the offer.

On Mon, May 23, 2016 at 10:36 PM, Jana Iyengar <[email-masked]> wrote:

> Hi Mark,
>
> The word "negotiation" can be read as a certain style of protocol
>> operation by some people; could you just say "protocol versioning and
>> configuration"?
>>
>
> The use of "versioning" is a bit ambiguous though because it seems to
> apply to both the process of creating new versions and the process of
> negotiating a version for use. "Versioning" is actually used later in the
> charter: "[...] this work will describe a versioning process that enables

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 24 May 2016 13:54:53 +1000

In H2, it's not really a negotiation mechanism; it's configuration advertisement.

Is the intent that this will cover things like SETTINGS, or is that separate?

Cheers,

> On 24 May 2016, at 1:34 PM, Ian Swett <[email-masked]> wrote:
> 
> In TCP, I believe options negotiation is known as options negotiation.  So unless there is an important difference between QUIC's options and TCP's, I would prefer the same naming as TCP.  My understanding is that they're sufficiently similar they should use the same name.
> 
> Configuration implies pre-configuration on both ends.  In this case, I believe we expect clients to offer up new features and have the server accept or deny the offer.  
> 
> I can see multipath as "configurable" protocol behavior; if folks think thats reasonable, I'm fine with using "configuration" instead of "options negotiation".
> 
> The use of "versioning" is a bit ambiguous though because it seems to apply to both the process of creating new versions and the process of negotiating a version for use. "Versioning" is actually used later in the charter: "[...] this work will describe a versioning process that enables distributed experimentation with QUIC."
>

---

From: Ryan Hamilton <[email-masked]>
Date: Mon, 23 May 2016 21:07:11 -0700

I would imagine that the H2 over QUIC mapping can specify how to map the
HTTP/2 SETTINGS onto QUIC. The simplest choice would be to send an HTTP/2
SETTINGS frame on the headers stream, but it might also make sense to use
the underlying QUIC mechanisms. In any case I would expect this to be a
work item of the HTTP/2 mapping focus area.

On Mon, May 23, 2016 at 8:54 PM, Mark Nottingham <[email-masked]> wrote:

> > In TCP, I believe options negotiation is known as options negotiation.
> So unless there is an important difference between QUIC's options and
> TCP's, I would prefer the same naming as TCP.  My understanding is that
> they're sufficiently similar they should use the same name.
> >

---

From: Göran Eriksson AP <[email-masked]>
Date: Tue, 24 May 2016 05:51:38 +0000

>thats reasonable, I'm fine with using "configuration" instead of "options

I understand that to mean QUIC can be “configured” to be turned on or off
multi path at least, or more advanced, detailed configuration of it multi
path selection?

Regards
Göran

---

From: Ian Swett <[email-masked]>
Date: Tue, 24 May 2016 11:46:59 -0400

Mark, I think I understand the confusion.  You're thinking of a third
feature advertisement that's separate from version negotiation and options
negotiation.

To provide some examples:
1) Version negotiation: Allows changing critical protocol elements, such as
what the encoding of the public flags mean.  For example, one could imagine
we decide QUIC needs 0, 8 or 16 byte connection ids.  That would require
protocol version negotiation.
2) Option negotiation:  Allows adding new functionality, likely within the
encrypted envelope.  For example, the ability to do multipath or FEC or any
transport level feature.  This allows different organizations to experiment
with different features, similar to how TCP does with options, but without
the deployment challenges of unencrypted TCP options.
3) Application level negotiation: This would be specific to the application
running on top of QUIC, and hopefully as Ryan said, would be in the scope
of any mapping document.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 25 May 2016 11:09:35 +1000

That's a good list, but I was thinking more about the specific word "negotiation" -- to many people, it implies that one peer will offer zero to many options, the other peer will select zero or more of them, and communicate that choice back to the first peer (or a roughly similar process).

We consciously didn't call it "negotiation" in HTTP/2 because we didn't want the RT; instead, a peer advertises its configuration and the other side accommodates it, or they fail to communicate. It's true that you can hammer SETTINGS into a negotiation mechanism, but it's designed not to require that style of interaction.

I'm probably focusing too much on one word :) -- just wanted to make sure that people didn't assume a particular style of interaction here.

Cheers,

> On 25 May 2016, at 1:46 AM, Ian Swett <[email-masked]> wrote:
> 
> Mark, I think I understand the confusion.  You're thinking of a third feature advertisement that's separate from version negotiation and options negotiation.
> 
> 1) Version negotiation: Allows changing critical protocol elements, such as what the encoding of the public flags mean.  For example, one could imagine we decide QUIC needs 0, 8 or 16 byte connection ids.  That would require protocol version negotiation.
> 2) Option negotiation:  Allows adding new functionality, likely within the encrypted envelope.  For example, the ability to do multipath or FEC or any transport level feature.  This allows different organizations to experiment with different features, similar to how TCP does with options, but without the deployment challenges of unencrypted TCP options.
> 3) Application level negotiation: This would be specific to the application running on top of QUIC, and hopefully as Ryan said, would be in the scope of any mapping document.
> 
> On Tue, May 24, 2016 at 1:51 AM, Göran Eriksson AP <[email-masked]> wrote:
>

---

From: Ryan Hamilton <[email-masked]>
Date: Tue, 24 May 2016 18:17:33 -0700

This is a totally fair point, Mark. The way QUIC works today, the handshake
"negotiates" (in the way you're using the word) things like the cipher
suite and key exchange methods. But the handshake also "negotiates" (in the
way HTTP/2 SETTINGS work) a number of other features.

So if "configuration" is perhaps problematic because it seems too static
(to Ian) and "negotiation is perhaps problematic because it seems too
dynamic (to you) we could say "protocol feature negotiation and
configuration".

Perhaps that's too verbose and clunky though?

On Tue, May 24, 2016 at 6:09 PM, Mark Nottingham <[email-masked]> wrote:

> That's a good list, but I was thinking more about the specific word
> "negotiation" -- to many people, it implies that one peer will offer zero
> to many options, the other peer will select zero or more of them, and
> communicate that choice back to the first peer (or a roughly similar
> process).
>
> We consciously didn't call it "negotiation" in HTTP/2 because we didn't
> want the RT; instead, a peer advertises its configuration and the other
> side accommodates it, or they fail to communicate. It's true that you can
> hammer SETTINGS into a negotiation mechanism, but it's designed not to
> require that style of interaction.
>
> I'm probably focusing too much on one word :) -- just wanted to make sure
> that people didn't assume a particular style of interaction here.
>
> Cheers,
>
>
> > 1) Version negotiation: Allows changing critical protocol elements, such
> as what the encoding of the public flags mean.  For example, one could
> imagine we decide QUIC needs 0, 8 or 16 byte connection ids.  That would
> require protocol version negotiation.
> > 2) Option negotiation:  Allows adding new functionality, likely within
> the encrypted envelope.  For example, the ability to do multipath or FEC or
> any transport level feature.  This allows different organizations to
> experiment with different features, similar to how TCP does with options,
> but without the deployment challenges of unencrypted TCP options.
> > 3) Application level negotiation: This would be specific to the
> application running on top of QUIC, and hopefully as Ryan said, would be in
> the scope of any mapping document.
> >

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 25 May 2016 11:20:22 +1000

Honestly, as long as people don't read too much into that word I'm happy. Having this discussion serves the purpose enough for me, we don't need to wordsmith too much.

Cheers,

> On 25 May 2016, at 11:17 AM, Ryan Hamilton <[email-masked]> wrote:
> 
> This is a totally fair point, Mark. The way QUIC works today, the handshake "negotiates" (in the way you're using the word) things like the cipher suite and key exchange methods. But the handshake also "negotiates" (in the way HTTP/2 SETTINGS work) a number of other features.
> 
> So if "configuration" is perhaps problematic because it seems too static (to Ian) and "negotiation is perhaps problematic because it seems too dynamic (to you) we could say "protocol feature negotiation and configuration". 
>

---

From: Martin Thomson <[email-masked]>
Date: Tue, 24 May 2016 21:23:36 -0700

> Honestly, as long as people don't read too much into that word I'm happy. Having this discussion serves the purpose enough for me, we don't need to wordsmith too much.

I see the following things being "negotiated" in the loosest sense of the word:

QUIC protocol version
Application protocol version
QUIC options/extensions/experiments
Application protocol settings (i.e., SETTINGS)
TLS version, cipher suite, etc...

Pretty much all of these things might be in scope, but the order of my
list is the order of importance.  I would like to see the last two
unchanged, but realize that we might discover a need to tweak those.
Versions and options do seem to be important, particularly if we
intend to maintain the spirit of the never-ending experiment.

---

From: Göran Eriksson AP <[email-masked]>
Date: Wed, 25 May 2016 12:15:05 +0000

>the encrypted envelope.  For example, the ability to do multipath or FEC
>or any transport level feature.  This allows different organizations to

+1

>application running on top of QUIC, and hopefully as Ryan said, would be
>in the scope of any mapping document.

+1

I like the list. Especially the “option” negotiation part. Covers much of
the concerns I have about relation http layer and multipath.

Tnx for taking this discussion a step further (Martin’s enhanced it even
more, which is great.)