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

Re: HTTP/3 Prioritization Proposal

From: Patrick Meenan <patmeenan@gmail.com>
Date: Sat, 4 May 2019 09:30:08 -0400
Message-ID: <CAJV+MGxQYyQc5-bMsY2J88d3uqB0_7BxKM2nJ56TkuUz1RSxAQ@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: Ian Swett <ianswett@google.com>, Patrick McManus <mcmanus@ducksong.com>, Lucas Pardue <lucaspardue.24.7@gmail.com>, Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
I'm still wondering if maybe we can find a way to handle the multiplexing
case without necessarily needing full tree knowledge/management on both
sides.  It does mean making things more complicated than a simple
"priority" but maybe there is a middle-ground that can work.  Something
like having groups that streams can belong to and the prioritization
applies within a group but then groups get weighted against each other.  It
feels like a bit of a slippery slope though that as we try to solve each
corner case we end up with something that looks a lot like the current
HTTP/2 scheme.

On Sat, May 4, 2019 at 2:32 AM Mark Nottingham <mnot@mnot.net> wrote:

> > On 4 May 2019, at 6:26 am, Ian Swett <ianswett@google.com> wrote:
> >
> >> 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.
>
> Any particular reason why? Most CDNs have a hierarchy of some kind, to
> protect the origin from having to serve too many CDN nodes directly.
>
> This came up at the latest HTTP Workshop; no one with an intermediary was
> using priorities in this way -- but that's because most intermediaries
> aren't using H2 on the back-end connection. Once they do, the next hurdle
> they'll hit is that H2's use of TCP means that using a single connection to
> origin is unattractive, so they'll use a number in parallel. In theory, H3
> should address that; in practice, we'll see.
>
> Regardless, it's not unreasonable to think that an intermediary will
> multiplex more than one client's traffic onto a connection (either to a
> parent node, or to the origin).
>
>
> > 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?
>
> Why would that be?
>
>
> >  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).
>
> I'm not sure what you mean here. With strict numerical priorities, an
> intermediary would either have to pass through the priorities unchanged (in
> which case a misbehaving client could claim everything is e.g., priority
> 255 and hog resources), or it'd have to normalise the priorities in some
> fashion, which practically (if not completely) precludes preserving the
> relative priority of a given client's requests.
>
> Cheers,
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>
Received on Saturday, 4 May 2019 13:30:47 UTC

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