Re: HTTP/3 Prioritization Proposal

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

Received on Saturday, 4 May 2019 05:23:41 UTC