[quicwg/base-drafts] Lessen the divergence from the HTTP/2 prioritization scheme by requiring all PRIORITY frames to be sent on the control stream (#2754)

[Kazuho Oku <[e-mail]>]

One of the additional complexity of the HTTP/3 prioritization scheme, compared to HTTP/2, is that PRIORITY frames might arrive out-of-order, between the control stream and the request streams.

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 not be worse compared to HTTP/2 over TCP even when packet loss is involved, as @pmeenan points out in https://github.com/quicwg/base-drafts/issues/2502#issuecomment-491108296.

To rephrase, sending PRIORITY frames on request streams is an "optimization" for a rare case instead of it being a requirement 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.

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