RE: HTTP/3 Prioritization Proposal

I think you’re both right, actually.  We’ve had discussions in H3 about whether the built-in PRIORITY scheme should be pulled out to an extension, and one of the reasons not to was that we didn’t have a competing priority scheme specified.  If the proposal is an extension, whether to H2 or H3, the HTTPbis WG owns those per our recharter, no?  So it belongs here, but it’s relevant to the H3 discussion and H3 is a reasonable target.

As to the actual proposal, I think it goes a long way toward giving us much of the needed functionality with a minimum of complexity.  I like it.  One minor suggestion:  I would swap the polarity of the low bits so that it flows the same direction as the priority field – greater numbers are more important.  (That is, make `11` Exclusive Sequential and `01` Shared.)  This enables a naïve implementation to just sort by the entire byte and come out not far wrong, plus makes a more correct implementation more intuitive.

From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Sent: Tuesday, January 29, 2019 7:22 AM
To: Mark Nottingham <mnot@mnot.net>
Cc: Patrick Meenan <patmeenan@gmail.com>; HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: HTTP/3 Prioritization Proposal

Hey Mark,

On Tue, 29 Jan 2019, 06:58 Mark Nottingham <mnot@mnot.net<mailto:mnot@mnot.net> wrote:
My sense is that people know that we need to do something about prioritisation, but we're not yet confident about any particular solution. Experimentation with new schemes as HTTP/2 extensions would be very helpful, as it would give us some data to work with. If you'd like to propose such an extension, this is the right place to do it.

The small amount of thinking I did on this lead me to a different conclusion. That it would be easier to experiment with new prioritization schemes in HTTP/3, due mainly to the removal of priority information from the H3 HEADERS frame. This makes it quite feasible to write an extension along the lines of "the extension replaces/supersedes the base standard PRIORITY frame when negotiated". In contrast, a H2 extension either needs to define a new HEADERS format or provide supplemental information in the form of a new frame, which is possible but a bit redundant.

There didn't seem to be much appetite for adopting H3 priority placeholder design in H2 (I cant remember when this was presented, sorry). I'd be curious to know if there is more interest in other alternate priority schemes in H2.

Lucas