Re: HTTP/3 Prioritization Proposal

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