Unidirectional stream (some or) all the control things in HTTP/3

[MikeBishop]

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.

[LPardue]

Lest we forget #2418 which discusses the MAX_PUSH_ID stream idea.

[LPardue]

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?

One mitigation is to get more explicit with how these "very important" streams are made. I.e. for the standard profile of QUIC we state that there is an absolute minimum number of streams and, more importantly, the peers create them in a standard and deterministic way.

This backtracks a little, to how things were before unidirectional stream type, but it still allows extension streams to be deployed in a less coordinated way.

[kazuho]

I think I am opposed to having a dedicated stream for PRIORITY frames.

If I understand correctly, the suggestion is based on either of the following two conceptions:

• sending priority information only on a dedicated stream is better than allowing the initial priority to be specified on the request stream
• it is a good idea to block processing of PRIORITY frames if there is a unresolved inter-stream dependency

I am not sure if either of the two is true. For the first point, the increased chance of not having prioritization information when receiving a request is a concern (see #2502 (comment)). For the second point, my understanding is that the ideal behavior is different. It is my understanding that the server should solely refer to the weight of the request stream when the stream's location within the tree cannot be resolved (see #2502 (comment)).

Considering these points, I am not sure if we want to incentivize servers processing PRIORITY frames in order. I might also point out that the servers willing to process them in order can buffer the PRIORITY frames after reading them out from the receive buffer of the control stream, and that the clients willing to send all the prioritization information in order can do that by sending the PRIORITY frames only on the control stream.

[dtikhonov]

Stopping processing PRIORITY frames has the effect of -- well, stopping processing PRIORITY frames. In other words, in addition to the presumed packet loss (discussed in #2502 as part of @rmarx original scenario), this approach effectively simulates even more packet loss.

Consider what happens when there are many existing streams that need to be reprioritized. A loss of a possibly unrelated (different subtree) STREAM packet would now cause delay in applying priorities of one or more RTTs.

Then there are the corner cases. For example, what happens when the client decides to cancel the stream whose lost STREAM packet caused the priority stream blockage? Do we need a special CANCELLED_STREAM instruction on the control stream that would allow the server to resume processing the priority stream? If so, this would introduce even more dependencies between streams.

Similar to QPACK design, stream prioritization mechanism should minimize the number of stream interdependencies and potential for priority inversion. The current (http-20) spec is not perfect, but it has the profitable feature of stream independence. Combined with the guarantee of eventual consistency, it strikes a good balance between complexity and performance.

[ianswett]

@dtikhonov Q on "Then there are the corner cases. For example, what happens when the client decides to cancel the stream whose lost STREAM packet caused the priority stream blockage?"

In this case, the server would either have to block until the stream was reset or buffer priority operations for later use. I agree both of these options are fairly unappealing, but is there a reason it's worse than that?

[dtikhonov]

I state that buffering priority frames because of a lost packet on an unrelated stream is not just unappealing, it's bad design. This is because the client wants those priorities changed 1/2 RTT ago. Expedient reprioritization of streams is a design goal.

[ianswett]

I agree it's a bad design.

[MikeBishop]

Discussed in London; no.