Re: HTTP/3 Prioritization Proposal

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

probably.. I agree that a lot of the complexity comes from the infinite
generalization of the current design.. a depth of 1 and a settings-able
width with a decent default might get you a long way.

On Tue, Jan 29, 2019 at 3:32 PM Lucas Pardue <lucaspardue.24.7@gmail.com>
wrote:

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