Re: HTTP/3 Prioritization Proposal

The biggest issue (at least currently) that I know of with the need to
synchronize the current priority trees is when adding new streams as a
child of a stream somewhere in the existing tree. The client has to hope
that the server still knows about the parent stream that the new stream is
being attached to, otherwise it gets dumped to the root with a weight of
16. This is a very real edge-case that, while known, impacted at least the
h2o and Google HTTP/2 server implementations serving traffic to Chrome. My
initial test for HTTP/2 prioritization triggered the edge case quite
reliably (unintentionally). h2o has since worked around it by "remembering"
some completed streams but I believe the Google edges are still impacted
(and I'm not sure about other implementations).

The existing scheme itself may be simple but implementing it is not. At
least on the client side, the browser needs to maintain a tree of all of
the in-flight requests to determine where the next stream should be
attached which is why the implementations are pretty simplistic. Firefox
just attaches new streams to the parent groups. Chrome keeps the "tree" but
it is effectively a linear list sorted by priority and new streams are
inserted as needed. Building a tree that supported ordering the critical
resources and splitting concurrency for visible images, hidden images, etc
is probably possible with some combination of Firefox's phantom streams for
grouping (to do group sequencing) but it would be a MUCH more complicated
tree. Trying to debug the trees and serving order from a dev perspective
then requires devs to draw out the full tree and understand what is going
on (website devs, not the protocol implementors).

I'm sure it's possible to do everything I'm proposing with the existing
tree scheme, I just think the complexity is too high for it to actually
happen. I'm hopeful that the proposal still achieves everything that
browsers actually need from scheduling resources while making it much
easier to understand, implement and debug.

On Mon, Jan 28, 2019 at 9:19 PM Amos Jeffries <squid3@treenet.co.nz> wrote:

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