Lessen the divergence from the HTTP/2 prioritization scheme by requiring all PRIORITY frames to be sent on the control stream

[kazuho]

The additional complexities of the HTTP/3 prioritization scheme, compared to that of HTTP/2, is that PRIORITY frames might arrive out-of-order between the control stream and the request streams, as well as the complexities that generate from the premise that out-of-order handling is necessary.

Our previous perception has been that it's worth the complexity, but I am becoming doubtful if it's necessary.

IIUC, the need for sending a PRIORITY frame on the request stream is to handle the rare-case (like 1%) where a packet carrying the control frame is being lost. But if we are to require a server to assign the most deferred priority (i.e. weight=0) to a request for which the PRIORITY frame is yet to be received, there would be a guarantee that the performance would be no worse compared to HTTP/2 over TCP even when packet loss is involved, as @pmeenan points out in #2502 (comment).

To rephrase, sending PRIORITY frames on request streams is an "optimization" for a rare case instead of it being a necessity to achieve comparable or better performance to HTTP/2.

Therefore, I am suggesting to stop sending PRIORITY frames on the request stream. The benefit of stopping that is that then we can have the guarantee that all the PRIORITY frames would be received by the server in the order they were sent by the client.

Then, thanks to the in-order delivery guarantee, I think we can revive the "exclusive" bit , revert the introduction of the "placeholders" concept in place of idle streams.

[LPardue]

I just lost a morr elegant reply so this might sound curt.

The proposal seems to make tree entry operations more deterministic. However, tree management like pruning and shuffling based on stream closure seems non-determinisitc. H2 has problems in this regard already.

Some H3 implementation experience is already bringing to light designs that have two world views of stream state: one for QUIC transport and one for H3.

[ianswett]

I'll attempt to summarize the issue: HTTP/3 priorities are different, but not better, and this creates implementation work and technical debt?

Previous issue introducing placeholders: #441

[kazuho]

@LPardue

The proposal seems to make tree entry operations more deterministic. However, tree management like pruning and shuffling based on stream closure seems non-determinisitc. H2 has problems in this regard already.

Yeah. I think we share the view that the approach proposed will have the same pros and cons that the prioritization scheme of H2 has. I think that's a good thing, because it helps people use the same approach when using the prioritization scheme.

[kazuho]

@ianswett

I'll attempt to summarize the issue: HTTP/2 priorities are different, but not better, and this creates implementation work and technical debt?

I disagree with the view. Our task is to port HTTP/2 semantics to HTTP/3. This is how you can do it, with less divergence than we have in the draft now. So it lessens the work to be done, implementation-wise.

[MikeBishop]

This is a possibility, presuming that we take #2690. We needed PRIORITY on the request stream so that streams opening before the PRIORITY frame arrives don't erroneously starve other resources until the PRIORITY frame arrives. #2690 plus reverting initial priority would allow bringing back exclusive dependencies; placeholders were separately discussed with HTTPbis as an enhancement to incorporate into HTTP/3, so I think a decision to revert that would be handled separately.

[kazuho]

@MikeBishop Yes. The simplification is based on #2690. I also agree that we can discuss about placeholders separately.

[LPardue]

Yeah. I think we share the view that the approach proposed will have the same pros and cons that the prioritization scheme of H2 has. I think that's a good thing, because it helps people use the same approach when using the prioritization scheme.

I have a nagging feeling, the QUIC streams can close in non-deterministic order from the remote peer perspective. This risks a H3 priority scheme that looks similar to H2 on paper but behaves quite differently. In the worst case this requires holding more state on the server in order to increase the chances that the client and server have similar global views.

[kazuho]

I have a nagging feeling, the QUIC streams can close in non-deterministic order from the remote peer perspective. This risks a H3 priority scheme that looks similar to H2 on paper but behaves quite differently. In the worst case this requires holding more state on the server in order to increase the chances that the client and server have similar global views.

While I agree that the the streams are being closed in a different manner, it is my view that things would generally work better in HTTP/3, because closure of streams would be notified earlier to the client (due to having less HoLB). Earlier synchronization of states lead to less need for retaining information of closed streams.

[ianswett]

@kazuho sorry for the confusion, I was attempting to say that HTTP/3 priorities were different from HTTP/2 priorities, and that was a negative. I just corrected my comment to say HTTP/3.

@LPardue your concerns are well-founded, but I think that's an existing problem and not a result of a recent change? I previously mentioned(verbally) that tree maintenance should be a longer period of time(ie: 3 MSL https://en.wikipedia.org/wiki/Maximum_segment_lifetime ?), but I realize even that may not be sufficient for QUIC and instead we should use something like 3*PTO?

I also think attaching streams to streams is inherently dangerous and much more dangerous in QUIC than HTTP/2, which is why I want to change HTTP/3 priorities to never have streams depend upon streams.

[rmarx]

I also think we might be conflating some issues here... to me, streams-depending-on-streams + do we need placeholders is a separate discussion from the original statement of this issue.

I am a bit hesitant to agree with this proposal, as I am worried about potential HOL blocking on the control stream, see also #2678 (a potential solution which was discarded in London). As mentioned above, this might be rare, but -any- loss on the control stream would impact priorities. Thinking of long fat networks and the CDN/proxy use case (of which it's still a bit unclear if we want to incorporate that into the HTTP/3 prioritization design), this might have a bigger impact than anticipated (though should only be occasional).

I myself was quite happy with just changing default behaviour (with #2690) in the case of potential re-ordering and don't really see the need for this change. The argument that it allows re-introducing exclusive priorities (uttered elsewhere) is true, but as also uttered elsewhere, I don't really see the need for that feature (was only used by Chrome for H2 afaict) and is better replaced with something like "implicit fifo" e.g., #2700 or #2723.

[MikeBishop]

@rmarx, the way I'm currently viewing it is that there are two tracks:

• The QUIC WG is gamely plugging along on its charter to replicate HTTP/2 functionality in HTTP/3 modulo changes required by the nature of the QUIC transport.
• In the meantime, the HTTP WG might come up with a way to replace/improve the one in HTTP/2. When they tell us what they want to use, we'll do it.

With my editor's hat on, only the first is my business unless and until the second one concludes. As an individual, I can and will go to HTTPbis and advocate for something better. But on this side of the fence, I still have to make progress on the first in case the second one derails. #2690, reverting initial PRIORITY, and bringing back Exclusive dependencies gets us back closer to HTTP/2 equivalence and had general support at the interim. So that's our just-in-case position while we see what HTTPbis decides.

[ianswett]

@MikeBishop I think those two tracks make sense, though I do think along the way we're making some choices about the best way to change H2 priorities to be more suitable to QUIC and what compromises are and aren't acceptable, which is by its nature a series of compromises.

For example, it seems a defaulting request weight of 1 or 0 would be a more HTTP/2 like solution than adding a default placeholder? But possibly it doesn't matter that much?

Are there outstanding PRs for the rest of the migration back to more H2-like priorities?

[kazuho]

@ianswett

For example, it seems a defaulting request weight of 1 or 0 would be a more HTTP/2 like solution than adding a default placeholder? But possibly it doesn't matter that much?

I do not think it matters much.

And I think that servers might want to play some game here, for example giving higher default precedence to responses that carry CSS files until a PRIORITY frame is being received.

That said, I think I prefer the design principle to be "provide something that is guaranteed to be at worst as good as HTTP/2." Giving least precedence to requests for which the client-specified priority is yet to be known is a natural way to achieve that.

Are there outstanding PRs for the rest of the migration back to more H2-like priorities?

Just filed #2781. I think that #2761 and #2781 are the remaining changes that we need to make, in order to allow browsers use the same prioritization scheme as the ones they've used in HTTP/2 (with the exception being that idle prioritized streams are replaced by placeholders).

[ianswett]

Thanks @kazuho, reviewing now