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

Re: HTTP/3 Prioritization Proposal

From: Ian Swett <ianswett@google.com>
Date: Fri, 3 May 2019 16:26:07 -0400
Message-ID: <CAKcm_gP4D4m6JPrpktk5PmcDyvcJoZMTDDpY8G49mfQxawZ8bg@mail.gmail.com>
To: Patrick McManus <mcmanus@ducksong.com>
Cc: Patrick Meenan <patmeenan@gmail.com>, Lucas Pardue <lucaspardue.24.7@gmail.com>, Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
On Tue, Jan 29, 2019 at 3:12 PM 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.
>
> 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.
>
> 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).
>

This thread got far ahead of me, but I wanted to ask for more motivation
behind the tree structure(links welcome).  'Google' may have argued for it,
but that doesn't mean it was ever used as envisioned.  Is anyone else
taking advantage of it?


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

For a given application(browser, app, etc), I'd expect absolute priority to
be a fairly good indicator across connections, because that's easy and the
alternatives are harder.

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

This statement concerns me for a few reasons.  One is I doubt any CDNs can
pull this off at scale, so I don't think it's practical.  Someone should
correct me if I'm wrong.  Another is that to pull this off, you'd need
reliable ways to know that a single user was the owner of two different
connections, which seems potentially concerning from a privacy
perspective?  Lastly, I don't think it would result in optimal loading.  If
one could do this, strict numerical priorities would likely work better,
because they'd preserve most of the clients original intent instead of
equally sharing bandwidth between blocking resources(ie: HTML, CSS) and
non-blocking ones(ie: images).
Received on Friday, 3 May 2019 20:26:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:15:34 UTC