Subject: [quicwg/base-drafts] Extension frames (#1473)

From: Martin Thomson <[email-masked]>
Date: Mon, 25 Jun 2018 00:17:46 -0700

This is the outcome we discussed in Kista.

One tweak here is to avoid allowing variant variable-length integer encodings.  The definition of variable-length integers would allow for four different encodings of the core set of frame types, which would require recipients to modify their code to look at more than one octet.  For instance, ping is 0x07, 0x4007, 0x80000007, and 0xc000000000000007.  I think that it's easier for all involved not to have to worry about long encodings until they want to experiment.

I'm flexible on that point, as I am with respect to registration policies.

Closes #58, #1072, #1068.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Extension frames

-- File Changes --

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

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/1473.patch
https://github.com/quicwg/base-drafts/pull/1473.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/1473

---

From: MikkelFJ <[email-masked]>
Date: Mon, 25 Jun 2018 02:11:25 -0700

I'd definitely prefer a few code points for var length for example 0xfd for a single octet following. 0xfe for two octest following, and 0xff for a varint following. This will use much less space in the average case.

-- 
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/1473#issuecomment-399884958

---

From: Martin Thomson <[email-masked]>
Date: Mon, 25 Jun 2018 02:26:58 -0700

@mikkelfj, I didn't want to invent another encoding here.  That's fun and all, but the encoding we have has ample space.  The cost here is that the number of one-octet encodings is limited to 64.

-- 
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/1473#issuecomment-399889457

---

From: MikkelFJ <[email-masked]>
Date: Mon, 25 Jun 2018 02:43:34 -0700

Fair point.

Each length could be explicitly placed in its own namespace by mapping all frames to 64-bit including the length encoding. This makes PING unique and other values easy to index.

Another fun encoding would be an FNV1a-64 hash of the reverse org name to use as a base for extensions where the upper two bits clamped to 1. Each such name reserving 100 sequential values.

-- 
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/1473#issuecomment-399894115

---

From: Mike Bishop <[email-masked]>
Date: Tue, 26 Jun 2018 11:21:13 -0700

MikeBishop approved this pull request.

> @@ -921,6 +924,30 @@ explained in more detail as they are referenced later in the document.
 All QUIC frames are idempotent.  That is, a valid frame does not cause
 undesirable side effects or errors when received more than once.
 
+The Frame Type field uses a variable length integer encoding (see
+{{integer-encoding}}) with one exception.  To ensure simple and efficient
+implementations of frame parsing, a frame type MUST use the shortest possible
+encoding.  Though a two-, four- or eight-octet encoding of the frame types
+defined in this document is possible, the Frame Type field for these frames are
+encoded on a single octet.  For instance, though 0x4007 is a legitimate
+two-octet encoding for a variable-length integer with a value of 7, PING frames
+are always encoded as a single octet with the value 0x07.

And what am I required to do if I encounter a 2+ byte encoding of 7?

> @@ -921,6 +924,30 @@ explained in more detail as they are referenced later in the document.
 All QUIC frames are idempotent.  That is, a valid frame does not cause
 undesirable side effects or errors when received more than once.
 
+The Frame Type field uses a variable length integer encoding (see
+{{integer-encoding}}) with one exception.  To ensure simple and efficient
+implementations of frame parsing, a frame type MUST use the shortest possible
+encoding.  Though a two-, four- or eight-octet encoding of the frame types
+defined in this document is possible, the Frame Type field for these frames are
+encoded on a single octet.  For instance, though 0x4007 is a legitimate
+two-octet encoding for a variable-length integer with a value of 7, PING frames
+are always encoded as a single octet with the value 0x07.
+
+## Extension Frames
+
+QUIC frames do not use a self-describing encoding.  An endpoint therefore needs
+to understand the syntax of all frame before it can successfully process a

all frames / each frame

> +defined in this document is possible, the Frame Type field for these frames are
+encoded on a single octet.  For instance, though 0x4007 is a legitimate
+two-octet encoding for a variable-length integer with a value of 7, PING frames
+are always encoded as a single octet with the value 0x07.
+
+## Extension Frames
+
+QUIC frames do not use a self-describing encoding.  An endpoint therefore needs
+to understand the syntax of all frame before it can successfully process a
+packet.  This allows for efficient encoding of frames, but it means that an
+endpoint cannot send a frame of a type that is unknown to its peer.
+
+An extension to QUIC that wishes to use a new type of frame MUST first ensure
+that a peer is able to understand the frame.  An endpoint can use a transport
+parameter to signal its willingness to receive a new type of frame, or even
+multiple types of frame with the one transport parameter.

...receive one or more extension frame types.

-- 
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/1473#pullrequestreview-132145266

---

From: ianswett <[email-masked]>
Date: Tue, 26 Jun 2018 11:45:07 -0700

ianswett approved this pull request.

Looking good.

Agreed, I think we either need to say you MAY close the connection or this is a SHOULD not a MUST

It would be nice to have an example here at some point, but since we don't have any extension frames, I guess that's for the future?

-- 
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/1473#pullrequestreview-132154963

---

From: Mike Bishop <[email-masked]>
Date: Tue, 26 Jun 2018 20:35:07 +0000 (UTC)

MikeBishop commented on this pull request.

There's always @larseggert's suggestion that BLOCKED et al. should be extensions.  That's been on hold while we wait for an extension mechanism to be defined, but it's a perfectly reasonable one.  Define a transport parameter `inform_if_blocked` and if that's set, the various BLOCKED frames are understood.

-- 
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/1473#discussion_r198288379

---

From: ianswett <[email-masked]>
Date: Tue, 26 Jun 2018 20:38:30 +0000 (UTC)

ianswett commented on this pull request.

That sounds like a reasonable suggestion 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/1473#discussion_r198289383

---

From: Martin Thomson <[email-masked]>
Date: Tue, 26 Jun 2018 15:42:17 -0700

@martinthomson pushed 2 commits.

81e10cc  PROTOCOL_VIOLATION for bad frame type
89c0aef  WIP

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1473/files/e4725aca6943b04e1ef7f347a0fea5ade6313741..89c0aefc2371a872e8de519346c225c1e0fc17e0

---

From: Martin Thomson <[email-masked]>
Date: Tue, 26 Jun 2018 15:50:45 -0700

@martinthomson pushed 1 commit.

6fa28c2  reflow

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1473/files/89c0aefc2371a872e8de519346c225c1e0fc17e0..6fa28c2172d549f036ca97ab6cf981c7162f2660

---

From: Martin Thomson <[email-masked]>
Date: Tue, 26 Jun 2018 15:52:05 -0700

09b7e94  Simplify

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1473/files/6fa28c2172d549f036ca97ab6cf981c7162f2660..09b7e945e7aaa909144651f9c7411a5f8dd774e7

---

From: janaiyengar <[email-masked]>
Date: Tue, 26 Jun 2018 16:06:07 -0700

janaiyengar approved this pull request.

-- 
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/1473#pullrequestreview-132236004

---

From: Martin Thomson <[email-masked]>
Date: Tue, 26 Jun 2018 16:10:49 -0700

fdcc44c  Merge branch 'master' into extend-frames

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1473/files/09b7e945e7aaa909144651f9c7411a5f8dd774e7..fdcc44c610cdd2897774718cc0af2532800157e7

---

From: Martin Thomson <[email-masked]>
Date: Tue, 26 Jun 2018 16:10:56 -0700

Merged #1473.

-- 
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/1473#event-1702667304