- From: Patrick McManus <mcmanus@ducksong.com>
- Date: Tue, 29 Jan 2019 15:51:41 -0500
- To: Lucas Pardue <lucaspardue.24.7@gmail.com>
- Cc: Patrick McManus <mcmanus@ducksong.com>, Patrick Meenan <patmeenan@gmail.com>, Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAOdDvNotoKuu5VWqTtJoCPLiq0=9QHg5gXTCPDjFGE_31uX=RA@mail.gmail.com>
> 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. >> >> >> >> >>
Received on Tuesday, 29 January 2019 20:52:18 UTC