W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2019

Re: HTTP/3 Prioritization Proposal

From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Wed, 30 Jan 2019 05:32:05 +0900
Message-ID: <CALGR9oY_hWkACJDi6F+9NHomEMS4cBDBs+7n-wSZFh0MDObKVg@mail.gmail.com>
To: Patrick McManus <mcmanus@ducksong.com>
Cc: Patrick Meenan <patmeenan@gmail.com>, Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
On Wed, 30 Jan 2019, 05:09 Patrick McManus <mcmanus@ducksong.com wrote:

> On Tue, Jan 29, 2019 at 2:56 PM Patrick Meenan <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.

The way I see it, H3 placeholders obsolete idle and unused streams. They
replace that with an abstract concept of a "thing" with no meaningful
default weight or dependecy parent (actual vals are 16 and root)

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

A tree of minimal depth (1-deep) could function pretty well. I think
addressing the gap from both sides cimould help identify it's size. Is the
size large due to following points quoted text?

> 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).
> 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.
> 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.
Received on Tuesday, 29 January 2019 20:32:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 29 January 2019 20:32:38 UTC