Subject: [quicwg/base-drafts] Add EXTENSION frame (#1068)

From: Martin Thomson <[email-masked]>
Date: Wed, 24 Jan 2018 17:03:47 -0800

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

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

-- Commit Summary --

  * Add EXTENSION frame

-- File Changes --

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

-- Patch Links --

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 24 Jan 2018 17:07:02 -0800

@martinthomson pushed 1 commit.

6fa50b4  Permanent, not non-provisional

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1068/files/1a93eedb041e77d281a8f391959e72c6f3e64086..6fa50b4d53a663f4d893ae22506789306b300a8a

---

From: janaiyengar <[email-masked]>
Date: Wed, 24 Jan 2018 17:36:29 -0800

janaiyengar approved this pull request.

Looks great -- let's discuss this in the room in Melbourne, but the PR LGTM.

-- 
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/1068#pullrequestreview-91390099

---

From: Christian Huitema <[email-masked]>
Date: Wed, 24 Jan 2018 19:33:05 -0800

huitema requested changes on this pull request.

I like the proposal. We need something like that for enabling experiments. But I would like to see a range of type values "reserved for experimentation", to avoid "reserve by squatting". 

Also, we are missing a way for implementations to signal their willingness to support a particular extension. Should we rely on using the version number for that? Should this PR say something about it?

> @@ -3832,6 +3874,41 @@ the range from 0xFE00 to 0xFFFF.
 {: #iana-error-table title="Initial QUIC Transport Error Codes Entries"}

+## EXTENSION Frame Types {#iana-extension-types}
+
+IANA \[SHALL add/has added] a registry for "QUIC EXTENSION Frame Types" under a
+"QUIC Protocol" heading.
+
+The "QUIC EXTENSION Frame Types" registry governs a 16-bit space.  Values are
+assigned using the Expert Review policy {{!RFC8126}}.  Registrations can be
+provisional or permanent.  Permanent registrations can only be made with the
+inclusion of a specification, as defined by the Specification Required policy
+{{!RFC8126}}.  Provisional registrations can be removed at the discretion of the
+assigned expert after 1 year unless they are renewed.  Provisional registrations
+do not require that a specification be referenced.
+

The spec was cool until that point. But there is a need to allow for experiments "between consenting implementations". What are they going to do? Squat on unallocated values? Or do we want to have an explicit range of extension types reserved for experiments, say FF00 to FFFE?

-- 
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/1068#pullrequestreview-91404546

---

From: martinduke <[email-masked]>
Date: Wed, 24 Jan 2018 19:50:19 -0800

This all LGTM, though I'm mildly tempted to make the type field a varint. 64K is enough, but why not let it be shorter until we get 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/1068#issuecomment-360353058

---

From: Christian Huitema <[email-masked]>
Date: Wed, 24 Jan 2018 20:06:58 -0800

Thinking of this a bit further, I have a concern about error signaling. How does a receiver signal that extension X was not encoded properly?

-- 
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/1068#issuecomment-360355159

---

From: janaiyengar <[email-masked]>
Date: Thu, 25 Jan 2018 04:34:13 +0000 (UTC)

@huitema : That should fall in the bucket of "unsupported" extension types, I imagine. Of course the text doesn't say that right now, but ignoring would be a fine way to handle this.

-- 
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/1068#issuecomment-360358331

---

From: Christian Huitema <[email-masked]>
Date: Thu, 25 Jan 2018 04:44:50 +0000 (UTC)

I am tempted to propose a completely different design. Reserve a small number of extension frame types in the "frame type" space. Create a transport parameter option in which the client says "I want to use reserved frame type X to do XYZT". Server acknowledges with corresponding option, "Let's use frame type X to do XYZT". XYZT is a four letter acronym reserved in a Wiki. 

-- 
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/1068#issuecomment-360359504

---

From: mirjak <[email-masked]>
Date: Thu, 25 Jan 2018 13:39:16 +0000 (UTC)

So why don't we just say that all frames types that are not used in this spec for this version are experimental (and all have to have a length field when used) and one can directly register a new frame type for a certain version of QUIC. I mean there is nothing else we can do with the remaining frame types as soon as the version spec is completed.

-- 
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/1068#issuecomment-360468844

---

From: MikkelFJ <[email-masked]>
Date: Thu, 25 Jan 2018 14:29:18 +0000 (UTC)

> So why don't we just say that all frames types that are not used in this spec for this version are experimental

It's easier to upgrade to a new version if the mess can be kept in one corner. Otherwise, despite suddenly v2 cannot have feature x because major player y has made this frame into a de-facto standard.

-- 
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/1068#issuecomment-360482351