- From: Patrick Meenan <patmeenan@gmail.com>
- Date: Sat, 4 May 2019 09:30:08 -0400
- 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>
- Message-ID: <CAJV+MGxQYyQc5-bMsY2J88d3uqB0_7BxKM2nJ56TkuUz1RSxAQ@mail.gmail.com>
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