Subject: Moving the version 4 bytes earlier in the long header

From: Ian Swett <[email-masked]>
Date: Thu, 16 Nov 2017 03:15:05 -0500

I am very supportive of Martin's work to define QUIC invariants.

It seems ideal to make the invariants as early in the packet as possible,
so I'd suggest we move the 4 byte version in front of the 4 byte packet
number in the long header.  This is filed in Issue #926
<https://github.com/quicwg/base-drafts/issues/926>.  For reference, it is
proposed the size and location of the version is an invariant, but nothing
about the packet number is.

Just because the packet number is before the version doesn't mean the
packet number length can't change, but it does mean we're stuck with those
4 bytes in that location, which makes future changes to the packet number
length very awkward.

I don't anticipate future changes, but this is going to be an invariant for
a very long time, so I'd like to move it now.

Thanks, Ian

---

From: Mike Bishop <[email-masked]>
Date: Thu, 16 Nov 2017 10:56:28 +0000

Actually, “the location and size of the Packet Number field in long headers” is currently listed as an invariant.  It’s the semantics of that field that are mutable per version, though as Brian has observed, some semantics may get ossified on us if we’re not careful.

It needs to be an invariant, because the Version Negotiation packet (and how you generate one) needs to be invariant, and a value is read from the incoming packet and set in the Version Negotiation packet as part of version negotiation.

From: QUIC [mailto:[email-masked]] On Behalf Of Ian Swett
Sent: Thursday, November 16, 2017 4:15 PM
To: IETF QUIC WG <[email-masked]>
Subject: Moving the version 4 bytes earlier in the long header

It seems ideal to make the invariants as early in the packet as possible, so I'd suggest we move the 4 byte version in front of the 4 byte packet number in the long header.  This is filed in Issue #926<https://github.com/quicwg/base-drafts/issues/926>.  For reference, it is proposed the size and location of the version is an invariant, but nothing about the packet number is.

Just because the packet number is before the version doesn't mean the packet number length can't change, but it does mean we're stuck with those 4 bytes in that location, which makes future changes to the packet number length very awkward.

I don't anticipate future changes, but this is going to be an invariant for a very long time, so I'd like to move it now.

Thanks, Ian

---

From: Ian Swett <[email-masked]>
Date: Thu, 16 Nov 2017 06:11:56 -0500

Thanks for the reminder on the version negotiation packet, Mike.

I would expect the version negotiation packet could echo the connection ID
and do anything with the packet number, given the connection ID provides 8
bytes of entropy?

If we no longer randomize the initial packet number(#850
<https://github.com/quicwg/base-drafts/issues/850>), it would not be
providing much entropy anyway.

That would mean we'd be echoing the portion of the packet up to the end of
the version(like before), but wouldn't say anything about the portion
afterwards.

On Thu, Nov 16, 2017 at 5:56 AM, Mike Bishop <[email-masked]> wrote:

> Actually, “the location and size of the Packet Number field in long
> headers” is currently listed as an invariant.  It’s the *semantics* of
> that field that are mutable per version, though as Brian has observed, some
> semantics may get ossified on us if we’re not careful.
>
>
>
> It needs to be an invariant, because the Version Negotiation packet (and
> how you generate one) needs to be invariant, and a value is read from the
> incoming packet and set in the Version Negotiation packet as part of
> version negotiation.
>
>
>
> *From:* QUIC [mailto:[email-masked]] *On Behalf Of *Ian Swett
> *Sent:* Thursday, November 16, 2017 4:15 PM
> *To:* IETF QUIC WG <[email-masked]>
> *Subject:* Moving the version 4 bytes earlier in the long header
>
>
>
> I don't anticipate future changes, but this is going to be an invariant
> for a very long time, so I'd like to move it now.
>
>
>
> Thanks, Ian
>

---

From: Christian Huitema <[email-masked]>
Date: Fri, 17 Nov 2017 16:20:20 +0100

If we move the version up, maybe we should move it up before the connection ID. Right now, implementations of draft 7 cannot understand the version number proposed by a draft 8 implementation, if the sequence number uses varint encoding. Which means it is a good time for a spec change. But someone is bound to invent variable length coding of the connection ID. And we will have the same issue.

-- Christian Huitema 

> On Nov 16, 2017, at 11:56 AM, Mike Bishop <[email-masked]> wrote:
> 
> It seems ideal to make the invariants as early in the packet as possible, so I'd suggest we move the 4 byte version in front of the 4 byte packet number in the long header.  This is filed in Issue #926.  For reference, it is proposed the size and location of the version is an invariant, but nothing about the packet number is.
>

---

From: Roberto Peon <[email-masked]>
Date: Fri, 17 Nov 2017 18:13:15 +0000

If we're going to cause a bunch of migration pain for those folks using QUIC in production, them or is best to do it all at once!

Does the benefit of moving these bytes around accomplish anything interesting, however? I don't mean this to say it should or shouldn't happen, just asking the question.

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

-------- Original message --------
From: Christian Huitema <[email-masked]>
Date: 11/17/17 7:21 AM (GMT-08:00)
To: Mike Bishop <[email-masked]>
Cc: Ian Swett <[email-masked]>, IETF QUIC WG <[email-masked]>
Subject: Re: Moving the version 4 bytes earlier in the long header

-- Christian Huitema

On Nov 16, 2017, at 11:56 AM, Mike Bishop <[email-masked]<mailto:[email-masked]>> wrote:

From: QUIC [mailto:[email-masked]] On Behalf Of Ian Swett
Sent: Thursday, November 16, 2017 4:15 PM
To: IETF QUIC WG <[email-masked]<mailto:[email-masked]>>
Subject: Moving the version 4 bytes earlier in the long header

Thanks, Ian

---

From: Ian Swett <[email-masked]>
Date: Fri, 17 Nov 2017 19:55:34 -0500

Christian, having the connection id in a fixed spot is really nice for
routing, so I'd prefer not to move version before connection ID.

The packet number in the header doesn't change in draft 8, since it's not
using the new varint format, but rather the defined codepoints in the
header.  But yes, if we wanted to make such a change soon or in the future,
it's a LOT easier if the version comes before the packet number.

Roberto, agreed.  In particular, Google QUIC is currently putting version
before packet number when version is present.  We have written code to move
it in IETF QUIC and support both IETF QUIC headers and GQUIC at once, but
once that's out, moving version again is going to become VERY difficult for
us.  And of course the location of the version is an invariant as Martin
presented.  Both are good reasons why IF we're going to move it we should
do it soon.  And I think it is slightly better to have version before
packet number.

On Fri, Nov 17, 2017 at 1:13 PM, Roberto Peon <[email-masked]> wrote:

> If we're going to cause a bunch of migration pain for those folks using
> QUIC in production, them or is best to do it all at once!
>
> Does the benefit of moving these bytes around accomplish anything
> interesting, however? I don't mean this to say it should or shouldn't
> happen, just asking the question.
>
>
>
> If we move the version up, maybe we should move it up before the
> connection ID. Right now, implementations of draft 7 cannot understand the
> version number proposed by a draft 8 implementation, if the sequence number
> uses varint encoding. Which means it is a good time for a spec change. But
> someone is bound to invent variable length coding of the connection ID. And
> we will have the same issue.
>
> -- Christian Huitema
>
> *From:* QUIC [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Ian Swett