Subject: [quicwg/base-drafts] use the 0x8 short header bit for demultiplexing gQUIC (#1120)

From: Marten Seemann <[email-masked]>
Date: Wed, 21 Feb 2018 02:01:42 +0000 (UTC)

This PR changes the code points for the short header packet types, such that the 0x8 bit is always unset. This will allow implementations of gQUIC to demultiplex gQUIC packets with short header packets sent by the client (gQUIC clients will always set the 0x8 bit).

For implementers, the only thing that needs to be changed is the short header packet type:
- 0x1F => 0x17
- 0X1E => 0x16
- 0x1D => 0x15

Apparently Github doesn't allow me to request reviews, but probably @ianswett, @martinthomson, @janaiyengar and @csperkins should have a look at this.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/1120

-- Commit Summary --

  * use the 0x8 short header bit for demultiplexing gQUIC

-- File Changes --

    M draft-ietf-quic-transport.md (19)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/1120.patch
https://github.com/quicwg/base-drafts/pull/1120.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1120

---

From: Martin Thomson <[email-masked]>
Date: Tue, 20 Feb 2018 18:11:45 -0800

martinthomson commented on this pull request.

This seems OK.

> @@ -486,9 +486,18 @@ Key Phase Bit:
   recipient of a packet to identify the packet protection keys that are used to
   protect the packet.  See {{QUIC-TLS}} for details.
 
+Google QUIC Demultipexing Bit:
+
+: The fifth bit (0x8) of octet 0 is set to 0. This allows implementations of
+  Google QUIC to distinguish Google QUIC packets from short header packets sent
+  by a client.
+  The special interpretation of this bit SHOULD be removed from this

This is fine, but you might be better prefixing this with a note to the RFC editor.  You can see one of those in the section on versioning.  In that note, request removal of the bit.  Hopefully we will get to that before this goes to publication.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1120#pullrequestreview-98057536

---

From: Martin Thomson <[email-masked]>
Date: Tue, 20 Feb 2018 18:12:50 -0800

You need write access to request review apparently.  And reviewers need to be in the organization.  The mention should suffice.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1120#issuecomment-367190647

---

From: Marten Seemann <[email-masked]>
Date: Wed, 21 Feb 2018 03:09:50 +0000 (UTC)

@marten-seemann pushed 1 commit.

4413a91  add note to RFC editor

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1120/files/9593edbfd41c7a8b077c9810cd3bc09bd4720a42..4413a91eb44ffebac613249cfeeba3249d7a911f

---

From: Marten Seemann <[email-masked]>
Date: Tue, 20 Feb 2018 19:10:21 -0800

marten-seemann commented on this pull request.

I added the note. Just removing this bit won't be enough though, we'll need to add this bit to whatever greasing mechanism we decide for.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1120#discussion_r169525761

---

From: Colin Perkins <[email-masked]>
Date: Wed, 21 Feb 2018 23:11:53 +0000 (UTC)

Looks okay to me.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1120#issuecomment-367510253

---

From: ianswett <[email-masked]>
Date: Thu, 22 Feb 2018 13:12:17 -0800

ianswett approved this pull request.

One suggestion, but this looks good to me.

> @@ -486,9 +486,21 @@ Key Phase Bit:
 
+\[\[RFC editor: please remove the Google QUIC Demultipexing bit before
+publication.]]
+
+Google QUIC Demultipexing Bit:
+
+: The fifth bit (0x8) of octet 0 is set to 0. This allows implementations of
+  Google QUIC to distinguish Google QUIC packets from short header packets sent
+  by a client.

How about "from short header packets sent by a client because Google QUIC servers expect the connection ID to always be present." to clarify why this approach works.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1120#pullrequestreview-98729299

---

From: Marten Seemann <[email-masked]>
Date: Thu, 22 Feb 2018 22:36:21 -0800

b077776  Ian's comment

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1120/files/4413a91eb44ffebac613249cfeeba3249d7a911f..b077776de554ac3908e9cb45c218ba578d1bc673

---

From: Marten Seemann <[email-masked]>
Date: Fri, 23 Feb 2018 06:36:34 +0000 (UTC)

Updated.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1120#discussion_r170176064

---

From: ianswett <[email-masked]>
Date: Fri, 23 Feb 2018 13:31:23 +0000 (UTC)

ianswett commented on this pull request.

In an ideal world, we'd be able to move onto this and then start greasing later after GQUIC has been deprecated.  In reality, I suspect we'll either need a mechanism not to grease certain codepoints in the short header or not to grease at all.  I tend to favor the former, since I think it's generally useful(ie: for WebRTC).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1120#discussion_r170251115

---

From: Mike Bishop <[email-masked]>
Date: Sun, 25 Feb 2018 14:09:54 +0000 (UTC)

MikeBishop commented on this pull request.

LGTM.  Leaving ample unused space in a field that's version-specific seems pointless.

> @@ -486,9 +486,22 @@ Key Phase Bit:

For clarity, we don't want them to actually eliminate the bit, just the text describing why it's there.  I'd just steal the Note from the changelog asking that "this section" be removed, and put it immediately after (rather than before) the header.

> @@ -511,9 +524,9 @@ other fields.
 
 | Type | Packet Number Size |
 |:-----|:-------------------|
-| 0x1F | 1 octet            |
-| 0x1E | 2 octets           |
-| 0x1D | 4 octets           |
+| 0x7  | 1 octet            |
+| 0x6  | 2 octets           |
+| 0x5  | 4 octets           |

Technically, the reason we were counting back instead of forward was to assist in demuxing.  If we're changing these again anyway, do we still need this unintuitive property?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1120#pullrequestreview-99144085

---

From: Marten Seemann <[email-masked]>
Date: Sun, 25 Feb 2018 15:10:52 +0000 (UTC)

I’m not sure if we still need it, i don’t think so. @csperkins?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1120#discussion_r170456070

---

From: Martin Thomson <[email-masked]>
Date: Tue, 27 Feb 2018 14:24:31 -0800

martinthomson requested changes on this pull request.

@mnot suggests that we make this a simple editors note and that it say:

```
\[\[Editor's Note: this section should be removed and the bit definitions changed before this draft goes to the IESG.]]
```

You need to mention the fourth bit also.

Let's start counting from 0.  As it is, this arrangement collides with DTLS, but that's hard to avoid.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1120#pullrequestreview-99879467

---

From: janaiyengar <[email-masked]>
Date: Tue, 27 Feb 2018 14:33:18 -0800

janaiyengar commented on this pull request.

LGTM, but a couple of comments.

+\[\[RFC editor: please remove the Google QUIC Demultipexing bit before
+publication.]]
+
+Google QUIC Demultipexing Bit:
+
+: The fifth bit (0x8) of octet 0 is set to 0. This allows implementations of
+  Google QUIC to distinguish Google QUIC packets from short header packets sent
+  by a client because Google QUIC servers expect the connection ID to always be
+  present.
+  The special interpretation of this bit SHOULD be removed from this
+  specification when Google QUIC has finished transitioning to the new header
+  format.
+

Can you add a paragraph for reserving the 4th bit as well? Maybe call it the STUN Demultiplexing Bit?

If the plan is to go back to the current types after Google has moved to iQUIC, it really doesn't matter. So I don't care, but leaving this unintuitive property in may be a good thing if that's the long term outcome.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1120#pullrequestreview-99881217

---

From: Colin Perkins <[email-masked]>
Date: Tue, 27 Feb 2018 22:52:52 +0000 (UTC)

csperkins commented on this pull request.

If we count from zero, and later set Google QUIC Demultipexing bit back to zero, then we collide with STUN for short header packets with a Connection ID present and key phase zero. Counting down avoids that collision.

If we're going to support P2P QUIC, then having a long-term stable way of easily demuxing with STUN seems important, so I'd prefer to avoid that collision.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1120#discussion_r171094295

---

From: Martin Thomson <[email-masked]>
Date: Wed, 28 Feb 2018 00:24:12 +0000 (UTC)

@csperkins, the current pattern is 0xx10xxx.  That never collides with STUN.  (The omission of bit 0x10 from the PR is a little confusing.)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1120#discussion_r171111284

---

From: Colin Perkins <[email-masked]>
Date: Tue, 27 Feb 2018 16:27:43 -0800

sure - I was responding to the suggestion that the gQUIC demux bits be removed before IETF QUIC goes final, in which case we would have a collision.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1120#discussion_r171111833