Subject: [quicwg/base-drafts] Transport parameter registry is too constraining for innovation (#3020)

From: David Schinazi <[email-masked]>
Date: Wed, 11 Sep 2019 13:55:20 -0700

As of [draft-22](https://tools.ietf.org/html/draft-ietf-quic-transport-22#section-22.1), transport parameter identifiers are 16bit integers, with a registry where
- `[0x0000 - 0xfeff]` uses the [RFC8128 Specification Required policy](https://tools.ietf.org/html/rfc8126#section-4.6)
- `[0xff00 - 0xffff]` is reserved for experimentation

While keeping Specification Required makes sense for a good chunk of the registry space, I think there will be many experiments that are conducted before a full specification is written (some already exist today and I expect there to be many many more once the protocol is standardized).

However, those experiments only have 256 values to play with, and that is bound to cause collisions and headaches down the road.

I think the simplest solution to this problem is to use variable length integers for transport parameter identifiers. The TLS presentation language doesn't support them but since we already use VLIs for the values of several transport parameters we're no longer bound by the TLS presentation language. I think there was also support for doing this when it was discussed on #1608, but that issue was closed when the *values* were changed to VLI with #1947, without changing the identifiers.

I'm happy to write the PR if this issue gathers support.

-- 
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/issues/3020

---

From: Martin Thomson <[email-masked]>
Date: Wed, 11 Sep 2019 18:05:10 -0700

You aren't the first to suggest this one.  Let's make sure we at least discuss this directly.  We did discuss this in the context of the issues that you cite and decided not to, but that was never the central question.

>From our perspective, this isn't a significant change to code.

-- 
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/issues/3020#issuecomment-530622380

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 11 Sep 2019 18:42:01 -0700

> From our perspective, this isn't a significant change to code.

The same for us, too.

Am I understanding correctly that the concern here is that extensions of TLS structures tend to use uint16_t as their type identifiers, and that the reusable parser might be constrained to that design pattern?

-- 
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/issues/3020#issuecomment-530629679

---

From: Martin Thomson <[email-masked]>
Date: Wed, 11 Sep 2019 18:47:41 -0700

I thought that this might be the case originally, but it turns out that the blob for transport parameters is generated by QUIC code in mostly all of the cases I have seen.  If there is someone out there who is relying on passing a TLS stack a structured grammar and letting the TLS stack perform serialization, then we might want to just leave this alone.

-- 
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/issues/3020#issuecomment-530630727

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 11 Sep 2019 18:54:39 -0700

Thank you for the clarification.

We _do_ use the TLS stack to encode / decode the transport parameters, therefore we do want see the TLS grammar-based design being preserved. The reason we do not mind the extension type being a varint is because our codec is flexible enough to handle that.
https://github.com/h2o/quicly/blob/master/lib/quicly.c#L1353-L1437

-- 
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/issues/3020#issuecomment-530631920

---

From: ianswett <[email-masked]>
Date: Fri, 13 Sep 2019 18:25:19 +0000 (UTC)

We should definitely do something to increase the number of experimentation codepoints from 256.  Changing to a varint sounds good.  If not, then we should allocate more of the space(ie: [0xf000 - 0xffff]) to experiments.

-- 
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/issues/3020#issuecomment-531342518

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 16 Sep 2019 17:07:45 -0700

I agree with @ianswett, and I don't think we need to go varint here, that seems like a bit of an overkill. How about reserving 4096 codepoints for spec required, and leaving the rest (2^16 - 2^12 = 61440) for experimentation:
[0x0000 - 0x0fff] uses the RFC8128 Specification Required policy
[0x1000 - 0xffff] is reserved for experimentation

-- 
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/issues/3020#issuecomment-532004505

---

From: David Schinazi <[email-masked]>
Date: Mon, 16 Sep 2019 17:15:42 -0700

Apart from the fact that we want to limit changes at this stage, are there arguments against going varint here? It feels pretty odd that many transport parameters are TLVs where T and L are 16bit and V is varint.

-- 
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/issues/3020#issuecomment-532006119

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 16 Sep 2019 18:14:11 -0700

I don't have much of an argument here besides the general principle that we shouldn't provide more flexibility than is necessary. I don't think it's odd that T is fixed-length while the V is varint, FWIW.

If no implementations are bothered by the change to varint, then it's a bit of a bikeshed. Let's see if other implementers are bothered.

-- 
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/issues/3020#issuecomment-532016998

---

From: Alexis La Goutte <[email-masked]>
Date: Wed, 18 Sep 2019 03:04:37 -0700

> [0x1000 - 0xffff] is reserved for experimentation

Split in two ? what the same size ?

Don't forget there is also GREASE TP now

-- 
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/issues/3020#issuecomment-532616269

---

From: David Schinazi <[email-masked]>
Date: Tue, 24 Sep 2019 10:23:25 -0700

>From looking at all the integer fields in QUICv1, it looks like at this point everything is a varint except the versions, packet numbers, connection ID lengths (which all have valid reasons for their lengths), and the transport parameter identifier and transport parameter lengths. Switching transport parameters to QUIC format (as opposed to TLS presentation language) feels fitting to me, saves bytes on the wire, and will facilitate innovation down the road.

-- 
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/issues/3020#issuecomment-534661132

---

From: ianswett <[email-masked]>
Date: Tue, 24 Sep 2019 10:29:43 -0700

I'm happy to make transport parameter identifier a varint.

@DavidSchinazi Are you(implicitly) suggesting that transport parameter lengths should be varint as well?

-- 
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/issues/3020#issuecomment-534663820

---

From: David Schinazi <[email-masked]>
Date: Tue, 24 Sep 2019 10:40:29 -0700

I think so, yes. If we're changing implementations might as well make both changes at once (assuming no one wants one of them to be varint but not the other).

-- 
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/issues/3020#issuecomment-534668230

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 24 Sep 2019 14:05:15 -0700

I'd be opposed to changing the transport parameter lengths to varints, as that means departure from the TLS notation that we use for defining TPs. It's very different from changing the IDs to varints, which is just changing the type of a particular variable.

IIRC, we discussed if we should switch to a different notation, and decided to go with the TLS-based design. At least I have built (or maintained) code based on that.

-- 
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/issues/3020#issuecomment-534747795