Re: HTTP/3 Prioritization Proposal

The tabs case always kind of fell apart when we tried to actually implement
anything because there isn't always a 1:1 relationship between requests and
tabs (multiple tabs may be waiting for the same request) so every request
needed to be managed directly anyway.

The aggregation/tunneling case does lend itself much better to the trees
though fundamentally it is a case of having a separate placeholder for each
aggregated connection so you can balance between the overall connections
and doesn't actually require a full tree (though as you start stacking
tunnels on top of each other you essentially end up with that anyway). We
could probably solve it by building trees of placeholders only and each
placeholder used something like the scheme I proposed but at that point
you're building trees anyway and maybe the added simplicity isn't there.

Thanks for the use case, that helps clear up the need for something more
complex. I'll redirect my efforts to see how complicated it would be to
build something that functions better than we're using today with the
current tree mechanism. It doesn't necessarily make it any easier for
Safari to plumb through into their current priority scheme but I don't know
what challenges they are having with plumbing it between WebKit and the OS
networking stack.

On Tue, Jan 29, 2019 at 3:51 PM Patrick McManus <mcmanus@ducksong.com>
wrote:

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