Priority grouping node ambiguity

[mcmanus]

in h2 'phantom' (unopened) streams can be used for grouping nodes for priority purposes. This is simultaneously very useful and very concerning from a resource commitment purpose. I'm aware of some servers looking to limit their use through implicit resource allocations, and I'm aware of some clients looking to use them more agressively (i.e. a grouping node per tab).

Perhaps we should at least make these explicitly negotiated so they can be cleaned up, limited, etc..?

[martinthomson]

This is a really useful feature in h2, it's a shame that we currently don't have any ability to support it in hq.

[mcmanus]

I think when doing 7540 the http wg decided some kind of grouping was essential for combining 2 uncoordinated groups into one connection. Proxies combining n connections into 1 is one use case, browsers combining n tabs into one connection is pretty much the same problem.

The implicit unopened stream was probably a mistake, but the 'requirement' still makes sense as something quic would need

[MikeBishop]

In Chicago, I had a side conversation with someone advocating that we rip out the priority scheme as a whole and enable different schemes to be used on an extension basis. (Which reminds me, I had promised to send this person the link to one of the alternatives that was proposed in late H2.... Doing that now.) I think a priority scheme that explicitly provided buckets of streams rather than using phantoms would be reasonable. However, that feels like it wanders into the realm of work that HTTPbis should be doing, rather than the QUIC WG; when there's not a specific "this doesn't work in QUIC because...", I'm loathe to make fundamental protocol changes without at least a commission from the owning WG.

However, I don't know that I'd say HTTP/QUIC doesn't support the phantoms -- can't you just close the streams you want to use as placeholders without making a request? Though perhaps we should have text that explicitly states that this is "normal" behavior, just for clarity's sake.

[MikeBishop]

I floated a proposal as an HTTP/2 extension, in the form of https://tools.ietf.org/html/draft-bishop-httpbis-priority-placeholder (expired draft). That didn't get much traction on the HTTP/2 side, though there was at least one comment that we should just do this in HTTP/QUIC directly.

Are we interested in adopting that approach in HTTP/QUIC separately from HTTP/2? If not, something else or just close this and live with it?

[ianswett]

I think this is worth discussion. Given this wouldn't need to be an extension for QUIC, if we did this, I'd like to see strict rules on when one can depend upon a stream. ie: streams can only depend upon placeholders or leaf node streams.

Or we should do something entirely different.

[MikeBishop]

I think I'd prefer strict rules about pruning the tree. I don't so much want to constrain the tree's structure as make sure both sides have a consistent view of it, which is one of the biggest drawbacks of the strategy in h2.

[ianswett]

I strongly support not taking the existing H2 priority scheme with no modifications.

[kazuho]

My preference goes to making minimal changes to the H2 prioritization tree.

If there is a benefit in switching to an approach other than the one we use in H2, it is likely that the HTTPx over TCP would would benefit from the switch as well. So why not do that in HTTPWG?

Going back to the topic of what the minimal change could be, I think the only thing that we need to do is find a code point for grouping node.

Fortunately, we have that space: the number space for client->server unidirectional streams. By definition, H2 priority is a scheme for controlling server's emission. Therefore, there is a guarantee that client -> server unidirectional streams will never be covered by prioritization.

I admit that this sounds like a hack. But proposing it anyways since IMO it demonstrates what a minimal change could look like.

[martinthomson]

There is also the possibility of defining explicit request identifiers rather than use stream IDs for identifying requests. That has some benefits.

[martinthomson]

We need the HTTP WG to discuss this. If they can, they can produce a new priority signaling scheme. If they do, QUIC will use that. If they don't, QUIC will have to make the h2 scheme work.

Since it seems unlikely that HTTP will produce a fast answer for us, we will probably need to do the latter.

[MikeBishop]

Discussed further at editors' meeting; we're sufficiently pessimistic that HTTP will adopt anything new in time, so we will proceed with a proposal to keep parity. The current candidate is to expand Push ID into a Request ID system, and then achieve parity by permitting the client to skip IDs.