RE: HTTP/3 Prioritization Proposal

Cliff Notes of extensions:

  *   Optional-to-understand frames can be sent without negotiation; optionally also negotiate to discover there’s no point in sending more of them after the connection is established.
  *   Mandatory-to-understand frames need to be negotiated first

I could imagine a model in which the client sends priority in all schemes it supports in the first flight, then picks one of them to continue with once it sees which ones the server supports.  That makes the overall state on the server somewhat fluid, however.

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

I need to dig into the extensions mechanism a bit but does it require negotiation (I would imagine it does to some level)? My main concern would be to figure out how to pull off the prioritization without adding round trips. If the new prioritization byte also made sense as a "weight" for most implementations without breaking prioritization for servers that don't understand the new scheme it might be possible to send the extension frame and stuff the priorities into the weight field and still have servers that don't understand the new prioritization do the right thing with the existing trees.

On Mon, Jan 28, 2019 at 5:21 PM Lucas Pardue <lucaspardue.24.7@gmail.com<mailto:lucaspardue.24.7@gmail.com>> wrote:
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