HTTP/3 is lacking priorities

[RyanTheOptimist]

Since HTTP/3 is a multiplexed protocol (just as HTTP/2 was) a sender which is servicing multiple requests needs some way to decide which request to send data on. HTTP/2 used a ... baroque ... prioritization scheme that this working groups has decided (rightly, IMO) is a poor fit for HTTP/3. Before shipping HTTP/3 we should settle on some prioritization mechanism for HTTP/3. (Possible a very simple scheme with the opportunity for extensions to provide more sophisticated schemes.)

[martinthomson]

Correction: HTTP/3 lacks a means of signaling priority. That distinction gets lost too often here.

[RyanTheOptimist]

Well, HTTP/3 the specification lack priorities in any form whatsoever :)

But yes, you're totally right that an HTTP/3 endpoint implementation can do prioritization based on locally available information. What is lacking is a way for and endpoint to provide information to the peer to facilitate the prioritization.

I'll be interested to see what sort of normative language we end up with for how an endpoint is required (or not) to act on this information.

[LPardue]

Request order is an implicit signal. In the absence of anything else I would borrow the text from RFC 7540

... input to a prioritization process.  It does not guarantee any particular processing or transmission order for the stream relative to any other stream.  An endpoint cannot force a peer to process concurrent streams in a particular order...

As discussed elsewhere, a sane default recommendation for servers based on request order might be useful.

But I hope we as a group can come up with a slightly better more complete answer.

[larseggert]

I'd like to see if we can "unpark" this issue and move it forward in some way. Any suggestions?

[MikeBishop]

The draft exists and is being worked on in the HTTP WG. If that is close to completion, a reference from HTTP/3 seems like it would fix this. However, I think the intent of parking is to signal that we don't plan to wait for that draft if it's not done.

[larseggert]

I guess that draft is draft-ietf-httpbis-priority? It seems to lack a milestone.

[larseggert]

I'm going to mark this as v2 for now. We can unmark it if the HTTP work progresses faster than we do, and we decide to incorporate it in some way.

[LPardue]

Since this is a design issue, we'll run this through the Late-stage process and include it in the next consensus call.

The proposal is to:

mark this as v2 for now. We can unmark it if the HTTP work progresses faster than we do, and we decide to incorporate it in some way.

[MikeBishop]

Marking as v2 and closing, per consensus call.