Subject: [quicwg/base-drafts] Define a mechanism for negotiating extensions (#1072)

From: Victor Vasiliev <[email-masked]>
Date: Fri, 26 Jan 2018 20:51:22 +0000 (UTC)

The mechanism in this commit allows the peers to negotiate extensions
and allocate the frame numbers for any custom frames that said
extensions define.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Define a mechanism for negotiating extensions

-- File Changes --

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

-- Patch Links --

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

---

From: MikkelFJ <[email-masked]>
Date: Fri, 26 Jan 2018 14:19:20 -0800

Looks reasonable to me. But there is no text on allocation of the 16-bit identifiers. I'm not sure a Wiki is necessarily the best option - not everyone wants to document all their experiments publicly.

I was wondering if a 128-bit namespace prefix could be added to the extension map. Then a uuid-4 could be used to avoid conflicts. And, on that account, why not make the QUIC version a uuid as well, since it is only needed in the 1-RTT handshake.

There is still a problem with extensions from multiple namespaces - so perhaps a list of namespaces with extension maps.

What about the issue mentioned on the list about fingerprinting a connection based on extensions used and perhaps reduce bandwidth on that account? Namespaces would not make such identification harder ...

-- 
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/1072#issuecomment-360920206

---

From: Christian Huitema <[email-masked]>
Date: Fri, 26 Jan 2018 18:06:25 -0800

huitema commented on this pull request.

I generally like the mapping idea, but I do not like the double indirection, using extension types to define list of frames, and then reserving code points by some algorithm. I would much rather just define frame types. 

We probably need an explanation of what is required when describing a extension frame: the syntax, obviously, but also the relation to acknowledgements and retransmissions.

You should say something about error behavior. What happens if a receiver finds an extension frame that it does not support, or a supported extension frame with incorrect values?

Generally, I like the mapping procedure better than the direct reservation of value types. The risks of squatting are much less, because frame type 0x81, for example, would by default have different meaning in different contexts.

> @@ -1217,6 +1218,17 @@ ack_delay_exponent (0x0007):
   value is also used for ACK frames that are sent in Initial, Handshake, and
   Retry packets.  Values above 20 are invalid.
 
+extension_map (0x0009):
+
+: An ordered vector of distinct 16-bit integers.  When used by the client,
+  indicates the list of extensions that the client is able and willing to use.
+  When sent by the server, indicates the list of extensions that the server has
+  accepted.  The server list MUST only contain the extensions offered by the
+  client; the ordering of the frames dictates the assignment of extension frame
+  numbers, as described in {{extension-frames}}.  In case of 0-RTT, the server
+  MUST either accept all extensions which it accepted in the original session,
+  or reject 0-RTT.
+

Using short values like 16 bits will require an organized registry. I would rather go for something longer, maybe 32 bits like the identifiers used in GQUIC, so that experiments can quickly pick a number, and maybe record it in a Wiki.

> +
+During the handshake, the client may offer the server a list of extensions it
+supports as a part of transport parameters, and the server may reply with the
+list of extensions it has accepted.
+
+Every extension that defines a codepoint in the transport parameters extension
+list MUST have a well-defined and ordered list of new frames it provides (that
+list MAY be empty), as well as the rules for parsing said frames.  The extension
+frame codepoints are allocated by assigning the frame numbers in order starting
+from 0x80, where the order is defined first by the order of extensions as
+specified in the server handshake, and then by the order they are specified in
+the extension definition.  So, for instance, consider the situation where there
+are two extensions, A and B; extension A defines frames A1 and A2, in that
+order, and extension B defines only the frame B.  Then server accepting "A, B"
+results in assignment "0x80 = A1, 0x81=A2, 0x82 = B", whereas "B, A" would
+result in "0x80 = B, 0x81 = A1, 0x82= A2".

That seems complicated. You are using two levels of definitions: the frame type, and the extension number. It would be simpler to have just an unambiguous identification of the frame type in the transport parameter. Then the example would be that the client proposes to support frames A1, A2 and B. There is only one order.

-- 
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/1072#pullrequestreview-92012516

---

From: ianswett <[email-masked]>
Date: Sat, 27 Jan 2018 05:25:14 +0000 (UTC)

ianswett commented on this pull request.

+extension_map (0x0009):
+

Given the 62 bit QUIC varint format exists, I'd use that to allow plenty of space for extensions.

-- 
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/1072#discussion_r164264203

---

From: Mike Bishop <[email-masked]>
Date: Sat, 27 Jan 2018 20:29:49 -0800

Do we have any other instances in which the server has to generate transport parameters in response to the client's transport parameters?  So far, I believe each side's transport parameters are unilateral declarations, even if both sides extrapolate an end state after seeing both.  That might be a property we're willing to discard, but let's be conscious about it.

-- 
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/1072#issuecomment-361037549

---

From: Martin Thomson <[email-masked]>
Date: Sun, 28 Jan 2018 16:05:06 -0800

martinthomson requested changes on this pull request.

I assume that you intend to use the IANA considerations from the other PR?  Because this isn't complete until you have that.

As Christian says, it would make sense to have the client offer a list of the things that it supports (a list of extension points) and the server to indicate assignments (a list of frame type to extension point mappings).

That leaves Mike's concern.  We haven't committed to having a negotiation pattern where the client speaks first.  This would make that commitment.  If you want to avoid that, you could say that the mapping needs to be respected by the receiving peer.  That is, the client advertises a mapping of extension frame codepoint to frame octet and the server uses that for frames that it sends to the client.  The server might advertise a different mapping and the client would have to respect that too.  That's a tiny bit more complicated, but probably still feasible.

Finally, with either suggestion, you don't have to limit extension frames to the 0x80-0xff range.  You can use any codepoint.

+extension_map (0x0009):
+

varints create a strong incentive to pick from the first 64 values.  I don't think that we need that much space.  16 bits is plenty for two reasons: experience with TLS shows that the rate of adding new codepoints is low enough that collisions and experiments collide infrequently; I don't want to create undue incentive to pick values <64 to get the short varint encoding.

-- 
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/1072#pullrequestreview-92071619

---

From: Martin Thomson <[email-masked]>
Date: Mon, 29 Jan 2018 00:06:27 +0000 (UTC)

martinthomson commented on this pull request.

> @@ -2678,6 +2690,29 @@ advised to bundle as few streams as necessary in outgoing packets without losing
 transmission efficiency to underfilled packets.

+## Extension Frames (#extension-frames)

The build is complaining because it should be `{#extension-frames}` (or an omitted anchor).

-- 
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/1072#pullrequestreview-92071814