Re: HTTP/3 Prioritization Proposal

On 29/01/19 1:33 pm, Mike Bishop wrote:
> 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.


IMO, if there are multiple priority schemes competing then there has to
be some SETTINGS (or equivalent) negotiation between the endpoints about
which one they are going to use.

This new proposal uses the same number of bits as the existing HTTP/2
scheme, so could easily re-use the same bits - the endpoints just need
to negotiate which interpretation those bits are given.


That said, looking through the proposal the very first thing that stands
out to me is that all the problems cited are somewhat artificial, or at
least indirect. They are a natural result of the particular Browsers
choice of implementation rather than problems with the priority design
itself:

 * Chrome - does not implement concurrency in its tree -> problems with
items that benefit from concurrency .

 * Firefox - aggregate only by type, forced concurrency -> problems with
items that should be high priority but have type with low-priority
classification, and with items that need sequential delivery.

 * Safari - does not implement -> latency problems with objects that
could benefit from priority markings.

The rational conclusion then is that better Browser implementations
would solve these particular annoyances. So what problems exactly are
preventing that better implementation happening?

Any replacement prioritization would likely have to face and resolve the
same issues. Along with the issues which caused the HTTP/2 priority
complexity -  that was a very simple design to begin with too.




As a side note this statement worries me:

"
The dependency tree management requires the tree state to be
synchronized on both ends of the connection.
"

IIRC one of the main benefits of the priority scheme we have is
precisely the opposite to that. Priority itself being a guideline more
than a hard requirement and sync between the endpoints after the initial
request weight assignment by HEADERS is an optional bonus for better UI
performance.

The Browse endpoint and the Origin endpoint(s) *will* have different
trees. If only because the response content comes from multiple
locations (middleware cache vs origin cache vs origin as-needed
generator) with vastly different frame delivery speeds.


Amos

Received on Tuesday, 29 January 2019 02:16:39 UTC