Re: HTTP/3 Prioritization Proposal

tx credit round robin is basically the default HTTP/2 prioritization of
even weighting across streams, isn't it? If so and the content being served
is web pages to a browser it can be as much as an order of magnitude slower
than if the priorities were honored (Chrome mitigates this a bit currently
by holding back requests because...wait for it....the current state of
priority support is pretty bad).

If you have a typical page with a few blocking scripts and stylesheets in
the head, a bunch of images (some visible, some not) and more scripts at
the end of the document, delivering them in priority order lets the browser
start rendering the content by just loading the scripts/stylesheets in the
head (and then prioritizing the images).  If you round-robin all of the
streams the page will be blank until everything finishes downloading and
then it will finally display. Not only is that an order of magnitude slower
compared with HTTP/2 servers that do support priorities, it's also MUCH
slower than HTTP/1.1.

I'm sure there are cases where it doesn't matter (and maybe those are the
cases where libwebsockets is used) but it is absolutely critical for
browser <-> server connections. There's also a good chance that your users
don't realize it isn't supported or don't realize it isn't working (which
is entirely believable given the current situation
<https://github.com/andydavies/http2-prioritization-issues#cdns--cloud-hosting-services>
).

On Sat, May 4, 2019 at 1:23 AM Andy Green <andy@warmcat.com> wrote:

>
>
> On 03/05/2019 21:26, Ian Swett wrote:
> >
> > On Tue, Jan 29, 2019 at 3:12 PM Patrick McManus <mcmanus@ducksong.com
> > <mailto:mcmanus@ducksong.com>> wrote:
> >
> >
> >     On Tue, Jan 29, 2019 at 2:56 PM Patrick Meenan <patmeenan@gmail.com
> >     <mailto:patmeenan@gmail.com>> wrote:
> >
> >         As far as I can tell, the placeholder streams serve to handle
> >         the Firefox use case of using idle streams for groupings,
> >
> >
> >       yes.. and you can probably solve for that in a simpler way by
> >     having an explicit set of groups with simple ways to share between
> them.
> >
> >     But what I think you really need to do with your proposal is address
> >     what you're giving up by removing the tree structure because it was
> >     an explicit choice to include it.
> >
> >     That structure exists because Google convinced the WG that it was
> >     important to be able to combine an arbitrarily large number of sets
> >     of streams together fairly. (and the solution allowed generalized
> >     sharing, not just fairness).
> >
> >
> > This thread got far ahead of me, but I wanted to ask for more motivation
> > behind the tree structure(links welcome).  'Google' may have argued for
> > it, but that doesn't mean it was ever used as envisioned.  Is anyone
> > else taking advantage of it?
>
> libwebsockets supports h2 server, h2 client with stream bundling, and
> ws-over-h2 server... it ignores PRIORITY and I've only ever been asked
> about it one time.  It just uses a round-robin scheduler between streams
> that have tx credit + more to send to allow them to write frames on the
> network connection.
>
> >     In short, if you've got a set of streams from tabs A, B, and C you
> >     cannot really expect them to be coordinated in an absolute priority
> >     sense - but if they were all rooted at the same level in a tree they
> >     could share fairly and then the streams within the tab could locally
> >     coordinate their priority.
> >
> >
> > For a given application(browser, app, etc), I'd expect absolute priority
> > to be a fairly good indicator across connections, because that's easy
> > and the alternatives are harder.
>
> PRIORITY and the stream tx credit scheme have an almost complete
> overlap.  If the default stream tx credit is small, or it's updated to
> walk the credit back after opening the stream, the client can use
> modulation of that per-stream to enforce the detailed priority it wants
> without PRIORITY or trees of PRIORITY or whatever being an explicit
> thing on the wire told to the server at all.
>
> And since properly managing tx credit is a bug-magnet, from that
> perspective it would've been better to exercise and re-use that instead
> of PRIORITY.
>
> So IMHO, the whole of PRIORITY is a white elephant.
>
> >     This is a much more important property in an aggregator like a CDN
> >     who might be bringing different front end connections into a single
> >     backend connection.. the priority expressed by the client should
> >     exist in some ways e2e (css before imgs!), but in other ways hop to
> >     hop (you don't want every css to stall every browser's images).. the
> >     tree allows that.
> >
> >
> > This statement concerns me for a few reasons.  One is I doubt any CDNs
> > can pull this off at scale, so I don't think it's practical.  Someone
> > should correct me if I'm wrong.  Another is that to pull this off, you'd
> > need reliable ways to know that a single user was the owner of two
> > different connections, which seems potentially concerning from a privacy
> > perspective?  Lastly, I don't think it would result in optimal loading.
> > If one could do this, strict numerical priorities would likely work
> > better, because they'd preserve most of the clients original intent
> > instead of equally sharing bandwidth between blocking resources(ie:
> > HTML, CSS) and non-blocking ones(ie: images).
>
> If the CDN had the information to do that well, it can also express it
> by stream tx credit modulation.
>
> -Andy
>