Re: HTTP/3 Prioritization Proposal

Patrick, I should have read your reply first, but this is what I was trying
to describe in my reply a few minutes ago.

I made the additional observation that browsers don't really need
weighting, so I'd expect most servers to set the max number of groups to
1.  This lowers the bar for simple servers and clients A LOT while giving
some flexibility to those who want to experiment with something fancier.

But I'd rather make some type of numerical priorities the default in the
spec and add one or more extensions to experiment with more complex
options, given I don't expect we'll get evidence that the extra complexity
has any benefits prior to standardizing HTTP/3.

On Sat, May 4, 2019 at 9:30 AM Patrick Meenan <patmeenan@gmail.com> wrote:

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