Re: HTTP/3 Prioritization Proposal

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

I may have misunderstood what Patrick was trying to say.  I thought he was
imagining a case where multiple connections from the SAME client hit a
single CDN node.  After re-reading his text and reading your comments, it
appears you have a case where there are many different clients going to a
single origin server and you're trying to use priorities to provide equal
weighting instead of using multiple connections.

In that case, strict priorities within groups and round robin within
groups(aka placeholders) seems like a better design that's simpler than the
existing proposal.  And client-facing servers could indicate a max number
of placeholders of 0.


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

I think you're supporting my point that we have essentially no deployment
experience with these being utilized as originally envisioned?

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

It was the single user aspect I was confused by.  I'll assume that was a
misunderstanding.

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

That makes sense now that I understand what Patrick had in mind.  Though
hopefully the cache hit ratio of your CDN is high enough that most
resources don't go back to the origin.

>
> Cheers,
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>