Subject: [QUIC] Protocol identifiers for drafts

From: Martin Thomson <[email-masked]>
Date: Tue, 8 Nov 2016 08:01:44 +1100

I'm getting a lot of questions from people who are starting to
implement.  I'm guessing that I'm only seeing a small proportion of
the total volume.  That's great.

But it's going to be hard to deploy unless we have some ground rules
about how to identify the protocol version.

Here's a strawman, loosely based on what I've learned from HTTP/2 and TLS 1.3:

QUIC version numbers are 32-bits.  We reserve everything in the range
0xffff0000-0xffffffff for experimentation.  We designate 0xffff5100
and up as corresponding to versions of the draft.  That is, 0xffff5101
would correspond to a potential -01 version of the core protocol
draft.  (Obviously, this would be post-WG-adoption, which I hope
happens soon.)

Similarly, we designate ALPN labels to match.  "quic-01" would
correspond to the same version of the HTTP mapping draft.  Hopefully
the mapping draft would progress in lock-step, but if it doesn't, then
the core protocol version that corresponds to the ALPN label would be
determined by what version of the core protocol is referenced by the
mapping document.

I think that we should agree to a scheme for protocol identifiers (it
doesn't have to be this) at the meeting next week.

---

From: Ted Hardie <[email-masked]>
Date: Mon, 7 Nov 2016 13:40:44 -0800

On Mon, Nov 7, 2016 at 1:01 PM, Martin Thomson <[email-masked]>
wrote:

> QUIC version numbers are 32-bits.

This is, presumably, one of the things we can change.  More broadly, I
think we need to think about a more granular approach to this, so we can
have multiple folks experimenting without either needless conflict or
over-much coordination.

There are a lot of folks who have deeply held opinions about extensions,
negotiation, and version, and I don't want to  tread over all that ground,
but I think we should not assume that we should start from where we are.

Just my personal opinion,

Ted

>   We reserve everything in the range

---

From: Patrick McManus <[email-masked]>
Date: Mon, 7 Nov 2016 17:26:21 -0500

I'm eager to get a plan on this as well - its essential for iteration and
diversity.

I would push back just a tad against Ted's message - this might be the one
place in the protocol where we have some backwards compatible constraints.
There is already trail blazing code running on UDP/443 but we also want to
allow ietf-quic to run on UDP/443 simultaneously during development to get
experience with that So I'm not sure we really can change the location of
the version field, at least not in a way that isn't cleverly compatible. It
is essentially the magic number of the format.

However, I think we're in a good place here if we can agree that network
byte order is the way to go. If we do that, Google can 'squat' on the high
byte (which would include what I understand are the 34 existing versions if
expressed as low endian) for now and the IETF space can have the low three
bytes without worry.. by the time it gets up to the 25th bit I would hope
old proto-quic implementations were no longer a going concern. A similarly
high range could also be carved out for permissionless experimentations in
the pre-rfc period - but we wouldn't have to settle on that right away.

And this makes for a nice document - just say the first draft is verison 1
and is in network byte order and that packets received with a version >=
0x01000000 MUST NOT be replied to with ietf-quic.

-Patrick

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 7 Nov 2016 18:04:02 -0800

I agree that we should have a plan for iteration and diversity, and should
have versioning figured out early. FWIW, I don't think compatibility is an
issue (it would be convenient if the placement of the version field were
not changed,) since this version space is quite humongous.

QUIC currently treats this as a 32-bit space, into which the QUIC version
made up of 4 ASCII characters is encoded. "Q034" is encoded on the wire as
0x 51 30 33 36. There's no interesting structure here since these aren't
treated as numbers... so unfortunately Patrick, I don't think your clever
trick is going to do much. Google servers and Chrome use lists of
currently-supported versions on each side, and there's no expectation of
continuity in the 32-bit space, since the versions are simply arbitrary
points in this space.

So, I'll take Martin's arrangement and change it slightly:

The IETF reserves versions 0x00000001 to 0x0000ffff (16K versions) for
standards work (drafts and standards.)
- In this space, designate  0x00000001 - 0x0000fff (4096 versions) to QUIC
standards
- Designate the rest of the IETF-reserved space, 0x00001000 - 0x0000ffff
(~60K versions), for corresponding draft versions. That is, 0x00001001
would correspond to a potential -01 version of the core protocol draft.

This leaves the space from 0x00010000 upwards (~4 billion versions) for
uncoordinated and distributed experimentation. Since current QUIC sits at
0x51303336, this shouldn't interfere with future draft versions.

---

From: Ian Swett <[email-masked]>
Date: Tue, 8 Nov 2016 15:09:14 -0500

> 0x51303336, this shouldn't interfere with future draft versions.
Distributed is great, uncoordinated sounds a bit dangerous to me.  Before a
larger number of experiments with different versions start, I'd suggest we
allocate a 256 or so versions to each organization which has a need to
experiment, in order to prevent conflicts.

Until we have a process for that, ideally we can focus on the core drafts
and any experimentation can mostly be done with feature negotiation, not
full version negotiation?  In a similar direction, possibly we want to
allocate a QuicTag for each organization to use to negotiate features?

>> I would push back just a tad against Ted's message - this might be the
>> one place in the protocol where we have some backwards compatible
>> constraints. There is already trail blazing code running on UDP/443 but we
>> also want to allow ietf-quic to run on UDP/443 simultaneously during
>> development to get experience with that So I'm not sure we really can
>> change the location of the version field, at least not in a way that isn't
>> cleverly compatible. It is essentially the magic number of the format.
>>
>> And this makes for a nice document - just say the first draft is verison
>> 1 and is in network byte order and that packets received with a version >=
>>> On Mon, Nov 7, 2016 at 1:01 PM, Martin Thomson <[email-masked]
>>> > wrote:
>>>

---

From: Patrick McManus <[email-masked]>
Date: Tue, 8 Nov 2016 16:32:04 -0500

maybe just a wiki page for self-registration during the pre-rfc period
would suffice? permissionless is good.

On Tue, Nov 8, 2016 at 3:09 PM, Ian Swett <[email-masked]> wrote:

>> I agree that we should have a plan for iteration and diversity, and
>> should have versioning figured out early. FWIW, I don't think compatibility
>> is an issue (it would be convenient if the placement of the version field
>> were not changed,) since this version space is quite humongous.
>>
>> - In this space, designate  0x00000001 - 0x0000fff (4096 versions) to
>> QUIC standards
> Distributed is great, uncoordinated sounds a bit dangerous to me.  Before
> a larger number of experiments with different versions start, I'd suggest
> we allocate a 256 or so versions to each organization which has a need to
>>> I'm eager to get a plan on this as well - its essential for iteration
>>> and diversity.
>>>
>>>> On Mon, Nov 7, 2016 at 1:01 PM, Martin Thomson <
>>>> [email-masked]> wrote:
>>>>
>>>> There are a lot of folks who have deeply held opinions about
>>>> extensions, negotiation, and version, and I don't want to  tread over all
>>>> that ground, but I think we should not assume that we should start from
>>>> where we are.
>>>>
>>>>

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 8 Nov 2016 21:37:48 +0000

> Distributed is great, uncoordinated sounds a bit dangerous to me.  Before a larger number of experiments with different versions start, I'd suggest we allocate a 256 or so versions to each organization which has a need to experiment, in order to prevent conflicts.

Do we need larger allocations?  Maybe identify classes, A B C D or something?

	/r$, those who forget history ...

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 8 Nov 2016 13:41:11 -0800

> would suffice? permissionless is good.

A wiki seems fine here. If people are going to be malicious, they're going
to be malicious.

-Ekr

>>> QUIC currently treats this as a 32-bit space, into which the QUIC
>>> version made up of 4 ASCII characters is encoded. "Q034" is encoded on the
>>> wire as 0x 51 30 33 36. There's no interesting structure here since these
>>> aren't treated as numbers... so unfortunately Patrick, I don't think your
>>> clever trick is going to do much. Google servers and Chrome use lists of
>>>> However, I think we're in a good place here if we can agree that
>>>> network byte order is the way to go. If we do that, Google can 'squat' on
>>>> the high byte (which would include what I understand are the 34 existing
>>>> versions if expressed as low endian) for now and the IETF space can have
>>>> the low three bytes without worry.. by the time it gets up to the 25th bit
>>>> I would hope old proto-quic implementations were no longer a going concern.
>>>> A similarly high range could also be carved out for permissionless
>>>> experimentations in the pre-rfc period - but we wouldn't have to settle on
>>>> that right away.
>>>>
>>>> And this makes for a nice document - just say the first draft is
>>>> verison 1 and is in network byte order and that packets received with a
>>>> version >= 0x01000000 MUST NOT be replied to with ietf-quic.
>>>>
>>>> -Patrick
>>>>
>>>>
>>>>
>>>>
>>>>

---

From: Ian Swett <[email-masked]>
Date: Tue, 8 Nov 2016 16:43:01 -0500

A wiki sounds fine to me.

On Tue, Nov 8, 2016 at 4:41 PM, Eric Rescorla <[email-masked]> wrote:

>>>> - Designate the rest of the IETF-reserved space, 0x00001000 -
>>>> 0x0000ffff (~60K versions), for corresponding draft versions. That is,
>>>> 0x00001001 would correspond to a potential -01 version of the core protocol
>>>> draft.
>>>>
>>> Distributed is great, uncoordinated sounds a bit dangerous to me.
>>> Before a larger number of experiments with different versions start, I'd
>>> suggest we allocate a 256 or so versions to each organization which has a
>>> need to experiment, in order to prevent conflicts.
>>>
>>> Until we have a process for that, ideally we can focus on the core
>>> drafts and any experimentation can mostly be done with feature negotiation,
>>> not full version negotiation?  In a similar direction, possibly we want to
>>>>>> This is, presumably, one of the things we can change.  More broadly,
>>>>>> I think we need to think about a more granular approach to this, so we can

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 8 Nov 2016 15:52:46 -0600

For what it's worth ...

> A wiki seems fine here. If people are going to be malicious, they're going

I'm OK with the wiki page for self-registration happening, but I'm hoping
that experimental versions aren't widely deployed for long periods of time,
which is what would justify more elaborate version number allocation
schemes.

I'm happy to listen to people explain to me that I have nothing to worry
about, of course.

Spencer, as AD

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 8 Nov 2016 14:14:49 -0800

Wiki SGTM, though honestly I don't think it's going to be useful. Let's be
clear that we are talking about (i) folks who can change both servers and
clients, and (ii) a space of ~4G versions, and the chances of version
collision in this space are astronomically low.

Spencer -- my expectation is that the experimental version space will be
used for continued experimentation on QUIC, whcih will hopefully feed back
into the standards process. This is useful now as we're working towards the
first standards, but I expect this will be useful after the first standards
are published for continued experimentation that can inform a subsequent
QUIC standard version. If an experimental version is deployed for a longer
period of time, that's still fine IMO, there's 4G versions in that space.
We won't run out of versions for several lifetimes.

On Tue, Nov 8, 2016 at 1:52 PM, Spencer Dawkins at IETF <
[email-masked]> wrote:

>> A wiki seems fine here. If people are going to be malicious, they're
>> going to be malicious.
>>
>> -Ekr
>>
>