Subject: Extension frame design question

From: Martin Thomson <[email-masked]>
Date: Fri, 13 Apr 2018 12:42:09 +1000

We agreed to add the ability to extend QUIC in Melbourne (I know, it's
so long ago, but it seems like just yesterday).  But we never never
sealed the deal.

While we agree in principle, and have agreed that the use of
extensions will be signaled during the handshake using transport
parameters (as opposed to the h2 model where they can just appear),
we're locked in disagreement about the precise colour to use.  Right
now there are three options:

1. As Victor originally proposed, provide a map from a large
identifier space to the smaller space of extension frame types.  PR
#1068 does that, mapping a 16-bit identifier into the 128-255 range of
frame types.  Cost: indirection, complexity.  Advantage: It has a PR
(i.e., nothing significant).

2. Use a varint for frame types. Cost: non-trivial change to the wire
format for frames; large(r) overhead for sending a frame unless you
get one of the privileged frame types that encode to a single octet
(and we have used 3/8 of those already, so we'd probably want to be
strict about registration policies in that space).  Advantage: simple.

3. A modification to PR #1068 proposed by Kazuho which would have
every transport parameter carry a list of frame types with it.  Cost:
similar indirection to PR #1068, and every transport parameter would
carry this list.  The advantage being that an extension that defines a
transport parameter would only touch a single transport parameter and
not have to register an extension frame type as well.

Now I prefer the first, but could live with either alternative if only
we could decide.  So I'm asking for help.

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 13 Apr 2018 12:20:53 +0900

Hi Martin,

Thank you for brining the issue to the list.

My view is that there are two orthogonal issues here:

a) whether if we should have two ways to extend the protocol; one by
declaring the use of a extension frame type and one by sending a
transport parameter (note: you cannot declare a feature that does not
add a new frame type by declaring the use of a frame type)

b) whether if the extended frame type is negotiated to fit into 1
octet or not (i.e. use varint)

For point a, my preference is to have only one way of extending the
protocol (by sending a transport parameter), having one IANA registry
instead of two.

I do not have a strong opinion on point b, though I described one
possible approach that could be used under the assumption that we
prefer to negotiate a frame type that fits into 1 octet.

-- 
Kazuho Oku

---

From: Mirja Kühlewind <[email-masked]>
Date: Fri, 13 Apr 2018 13:56:14 +0200

I guess another approach would be to have one extension frame type with a length field and an extension number (that is registered with IANA on a FCFS basis).

> Am 13.04.2018 um 04:42 schrieb Martin Thomson <[email-masked]>:
>

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 13 Apr 2018 09:36:57 -0700

> now there are three options:

As I said in my email, I do think that this is more than just a purely
aesthetic
issue. The fundamental question is whether one wants to be able to negotiate
(or signal or whatever) extensions which involve both a new frame type
and some parameter negotiation. For instance "I support message frames,
but don't make them longer than 200 bytes". In that case, with the design
in PR#1068 that just contains a map table, you either have to have a second
transport parameter to negotiate the per-extension parameter (with the
risk of mismatch) or you need two ways to establish the mapping table.

It might be useful to talk a bit about principles and constraints. My basic
assumption is that it's not important for non-standardized extensions to
have *very* short frames. I.e., it would be fine if their frame type
identifiers
were 4 bytes. If that's so, then we have a lot of room and we don't need
to worry about mapping. This would be compatible with either a varint
or a "extension" frame as Mirja suggests. And then when you wanted to
standardize you would get a short type (varint is slightly better here).

On the other hand, if you think it's important to have very short frames
for non-standardized extensions then you need some sort of mapping
thing.

-Ekr

---

From: "Swindells, Thomas (Nokia - GB/Cambridge)" <[email-masked]>
Date: Fri, 13 Apr 2018 16:53:51 +0000

One of the lessons learnt from HTTP is that you don’t get the option to standardize once an ‘experimental’ feature is widely deployed. That is why X- prefixes on http headers was deprecated: it was realised clients had already ossified on using the experimental value and you were stuck with it for a very long time, even if you introduced a standardized version of the feature the non-standard usage still lives on and has to be supported.

Based on this, I don’t think we can distinguish sufficiently between ‘non-standardized’ and ‘standardized’ extensions, and if we think it is important to have very short frames at all (I’m not making a call on that) then the mapping thing is required.

Thomas

From: QUIC [mailto:[email-masked]] On Behalf Of Eric Rescorla
Sent: Friday, April 13, 2018 5:37 PM
To: Martin Thomson <[email-masked]>
Cc: QUIC WG <[email-masked]>
Subject: Re: Extension frame design question

On Thu, Apr 12, 2018 at 7:42 PM, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:
We agreed to add the ability to extend QUIC in Melbourne (I know, it's
so long ago, but it seems like just yesterday).  But we never never
sealed the deal.

As I said in my email, I do think that this is more than just a purely aesthetic

have *very* short frames. I.e., it would be fine if their frame type identifiers

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 13 Apr 2018 09:57:09 -0700

I can understand how someone might draw that conclusion, but i don't think
it's really applicable here because these values are negotiated, not just
announced. Thus, it's not problematic to use one code point in initial
deployment and then define a new, short code point upon standardization.
It's true you probably have to support both code points in perpetuity, but
that's mostly just a matter of a small number of bytes in the parameter
negotiation

-Ekr

On Fri, Apr 13, 2018 at 9:53 AM, Swindells, Thomas (Nokia - GB/Cambridge) <
[email-masked]> wrote:

> One of the lessons learnt from HTTP is that you don’t get the option to
> standardize once an ‘experimental’ feature is widely deployed. That is why
> X- prefixes on http headers was deprecated: it was realised clients had
> already ossified on using the experimental value and you were stuck with it
> for a very long time, even if you introduced a standardized version of the
> feature the non-standard usage still lives on and has to be supported.
>
>
>
> Based on this, I don’t think we can distinguish sufficiently between
> ‘non-standardized’ and ‘standardized’ extensions, and if we think it is
> important to have very short frames at all (I’m not making a call on that)
> then the mapping thing is required.
>
>
>
> Thomas
>
>
>
> *From:* QUIC [mailto:[email-masked]] *On Behalf Of *Eric Rescorla
> *Sent:* Friday, April 13, 2018 5:37 PM
> *To:* Martin Thomson <[email-masked]>
> *Cc:* QUIC WG <[email-masked]>
> *Subject:* Re: Extension frame design question
>
>
>
>
>
>
>

---

From: Mirja Kühlewind <[email-masked]>
Date: Fri, 13 Apr 2018 20:47:48 +0200

I guess the standardized version means part of the new quic protocol version. Given the intent is to change versions for quic more often than for HTTP, I don’t think we will have the same problem.

> Am 13.04.2018 um 18:57 schrieb Eric Rescorla <[email-masked]>:
> 
> I can understand how someone might draw that conclusion, but i don't think it's really applicable here because these values are negotiated, not just announced. Thus, it's not problematic to use one code point in initial deployment and then define a new, short code point upon standardization. It's true you probably have to support both code points in perpetuity, but that's mostly just a matter of a small number of bytes in the parameter negotiation
> 
> -Ekr
> 
> 
> On Fri, Apr 13, 2018 at 9:53 AM, Swindells, Thomas (Nokia - GB/Cambridge) <[email-masked]> wrote:
> On Thu, Apr 12, 2018 at 7:42 PM, Martin Thomson <[email-masked]> wrote:
>

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 13 Apr 2018 12:29:56 -0700

On Fri, Apr 13, 2018 at 11:47 AM, Mirja Kühlewind <
[email-masked]> wrote:

> I guess the standardized version means part of the new quic protocol
> version. Given the intent is to change versions for quic more often than
> for HTTP, I don’t think we will have the same problem.
>

That would work, but if you're negotiating them, we could also just publish
an RFC wit the extension definition and assign a short code point.

-Ekr

> > I can understand how someone might draw that conclusion, but i don't
> think it's really applicable here because these values are negotiated, not
> just announced. Thus, it's not problematic to use one code point in initial
> > On Fri, Apr 13, 2018 at 9:53 AM, Swindells, Thomas (Nokia -
> GB/Cambridge) <[email-masked]> wrote: