[quicwg/base-drafts] Unidirectional stream all the control things in HTTP/3 (#2678)

[Mike Bishop <[e-mail]>]

Separating out discussion from #2502:

@martinthomson:
> That suggests the creation of a "priority" stream...

@LPardue:
> A priority stream, in our current scheme, has some desireable properties because it aligns with the asymmetry, i.e. only client can create a priority stream. If anyone cared you could borrow QPACK encoder/decoder model so that the client has clear indication when priorities were processed. One could go as far as adopting that model further,
> 
> 1. priority stream(s) contains unframed instructions
> 2. PRIORITY frame on request is just a shell that contains references to priority state.
> 
> This opens a possibility to have alternative priority schemes based on opening different types of priority streams.
> 
> It all sounds terribly complicated though :D

@martinthomson:
> Not really complicated. Possibly less complicated, especially if you consider that dropping the priority stream could be permitted if it were separated from SETTINGS. And SETTINGS could get its own stream too :)
> 
> I wouldn't go so far as to say unframed priority signals, but the possibility to dispense with framing is appealing to some extent. Complicated comes when you have a marked in a stream saying what priority state you are depending on. That wouldn't necessarily be a blocking signal in the same way that QPACK is, but it certainly drives complexity upward slightly.

More generally, the control stream provides stronger ordering guarantees than are needed, and produces head-of-line blocking if a frame can't be immediately consumed for some reason (a possibility being discussed in #2502).

We have a small set of frames which are sent on the control stream:
- SETTINGS (sent only once)
- PRIORITY (ordering requirements only with respect to each other)
- CANCEL_PUSH (no ordering requirements)
- GOAWAY (currently ordering requirements only with respect to each other; could be unordered without loss of information)
- MAX_PUSH_ID (currently ordering requirements only with respect to each other; could be unordered without loss of information)

Some of these might be reasonable candidates for unidirectional streams of possibly-unframed instructions, similar to QPACK. If enough things fall into this category, we could potentially eliminate the control stream.  While this has implications for extensions being ported to HTTP/3, saying that what was a new frame type on the control stream becomes a new unidirectional stream type with length-prefixed payloads of known type isn't as big a leap as it might initially seem.

Note that this would make #2559 even more of a problem.  What do you do without enough unidirectional stream ID space to send your GOAWAY, for example?

I don't necessarily advocate this change, given how late we are in the process, but I'd rather have it as a separate issue for discussion than get it intertwined with the discussion on #2502.

-- 
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/2678