Re: [QUIC] h2 mapping - extensions

[Mike Bishop <[e-mail]>]

Jana, h2 extensions are very broad – you can negotiate (method unspecified, but usually a mutual SETTING) any departure from or addition to the spec.  Additionally, clients MUST ignore unknown frame types, so anything that doesn’t change the core of the protocol (e.g. ORIGIN) can be sent speculatively, without knowing whether the peer will understand.

In the current mapping, you’re effectively running a full HTTP/2 framing layer and mux on Stream 3.  It’s referred to as “the HEADERS stream,” but it actually carries SETTINGS, PUSH_PROMISE, PRIORITY, and basically anything else.  The mapping document calls out things that are delegated to the QUIC layer (PING, GOAWAY, WINDOW_UPDATE) or other QUIC streams (DATA), but otherwise you could take arbitrary h2 extensions and drop it on Stream 3 without much change.  If we keep that model, that’s probably the default answer – an extension works unless it has some hard dependency on ordering w.r.t. message body.

That said, I’d prefer to break out of the double-mux model if we can, moving things to their own streams as much as possible to take advantage of getting out of head-of-line blocking.  I’m working on a draft, albeit too late for Seoul, and at least HEADERS/PUSH_PROMISE/DATA (and everyone’s favorite, CONTINUATION) can be dropped to other streams pretty easily.  We may still need a dedicated stream for SETTINGS, though, which means putting extensions there too still isn’t as much of a stretch – at least, for things that live on stream zero.  And on-stream extensions, too, perhaps.

From: QUIC [mailto:[e-mail]] On Behalf Of Jana Iyengar
Sent: Monday, November 7, 2016 2:44 PM
To: Patrick McManus <[e-mail]>
Cc: [e-mail]
Subject: Re: [QUIC] h2 mapping - extensions



On Mon, Nov 7, 2016 at 11:34 AM, Patrick McManus <[e-mail]<mailto:[e-mail]>> wrote:


On Mon, Nov 7, 2016 at 2:26 PM, Jana Iyengar <[e-mail]<mailto:[e-mail]>> wrote:
On Thu, Nov 3, 2016 at 2:39 PM, Patrick McManus <[e-mail]<mailto:[e-mail]>> wrote:
Hi Robbie, Mike, et al. Thanks for getting the ball rolling with https://tools.ietf.org/html/draft-shade-quic-http2-mapping-00..
What is the thinking about rfc 7540 h2 extensions and the h2/quic mapping.. particularly the way it allows unspecified frame types which may or may not require negotiation.
it seems some of these extensions may have stateful issues across streams, ala hpack and some may not.
If the extension were only defined for h2-over-quic that would be for the extension to sort out.. but it doesn't seem like we are limiting things to quic vs tcp, or are we?

Not sure what you mean by not limiting things to QUIC vs. TCP -- do you have a different mapping in mind?

I meant explicitly scoping h2 extensions so that they only apply to quic and/or tcp.. and it does seem like that's what you mean :)

Gotcha. I think it makes sense to limit to QUIC and TCP at the moment since there is a proposal to run HTTP over these, until such a time as there is a need to define over another transport (let's call it Essy Transport Protocol, you know, EssyTP). I suspect at that point the httpbis wg (hey, that's you! :-)) can figure out how to define extensions over the other transport.

My sense is that we'll need to
(i) define how current extensions will work with QUIC (eg, HPACK), and

fwiw HPACK/QPACK is not an extension and you can't define it as one in quic because it would need to be negotiated and that's going to break the 0RTT goal of the protocol. I don't think that's a problem though as there is no need to make it an extension :)

Ah, sorry -- my grasp of which things are extensions and which ones not in HTTP-land is weak. I think compression is likely to be one of those things that is different in QUIC than in HTTP/2.

(ii) require that future extensions be defined explicitly  for both TCP and QUIC.

So the mapping document will need to establish a new h2 extension registry?

Do you mean an IANA registry? It's probably safest to put these extensions will be in different namespaces entirely, so yes, if I understand your question correctly.

- jana


-P