Re: Call for consensus: HTTP/2 Priorities

[Robin MARX <[e-mail]>]

At the risk of repeatedly screaming into the void:

I do not have a problem with the removal of HTTP/2-style priorities per se.
The setup is certainly quite complex and can be simplified in terms of
implementation.
However, the dependency tree is also very flexible and able to represent a
wide variety of different prioritization schemes.
That this flexibility has been severely under-utilized to this day, does
not necessarily mean it's not needed in my opinion.
And sure, we can drop it now, ship with something simple, and move to a
more complex/flexible setup again down the road once we have more insights.

However, that latter point is still not what seems to be on the table here.
I still feel like we're proposing dropping priorities completely right now
and -maybe-,
just maybe (NOT *necessarily *as Mark says*)* shipping H3 with some form of
priorities on-board (i.e., "priorities should not block H3"). The way I see
this going forward
is that many people just won't bother implementing any prioritization
concept until it's clear what will end up chosen (and it's in the spec).
Consequently, people will keep testing QUIC stack performance without
caring about multiplexing (much): downloading a single file over a single
stream,
which imo is only part of the equation. I see us ending up with shipped
implementations that don't have decent prioritization support, this time
not because they can't
be bothered to implement a dependency tree, but simply because nobody told
them they should. Thus we run the risk of H3 performing worse than H2.

As such, I am not really in favor of removing priorities from the spec
until we have a replacement. Or if we do, I feel priorities should block H3
(even if it's just for a simplified setup).


I really feel we're sticking our heads in the sand on this. We've been
ignoring HTTP priorities for too long (otherwise we wouldn't be in this
current mess). Next to that,
we've also been ignoring QUIC-level priorities (with the very vague
https://tools.ietf.org/html/draft-ietf-quic-transport-22#section-2.3 as
only indication). I've asked this
of multiple implementers on multiple occasions and no one had a concrete
idea of how they will/should be mapping application-layer priorities to
QUIC stream priorities yet.
People seem to expect this to somehow resolve itself or that it can be
bolted on as an afterthought, and maybe it will/can, but I doubt it.

The only other conclusion I can draw from all this, is that priorities
don't really matter in the big picture. I certainly see enough indicators
to that end. For example Microsoft Edge
not bothering to use them in the first place. For example browsers not
seeming to a/b test optimal approaches for over 4 years. For example, some
people advocating that "passive"
resource request order + content-type is enough of a signal in itself to
provide good page loading performance. For example, people proposing not
letting them block H3.
This viewpoint is 100% contradictory to my own prioritization research and
my understanding of current web page building techniques. Maybe I'm missing
things others take for
granted. Maybe I'm making mistakes. Maybe priorities are not the
cornerstone of a multiplexed protocol that I view them to be. In that case,
by all means go ahead and continue
down this proposed route, as it indeed seems the best way forward. If not:
please give them the attention they deserve.

With best regards,
Robin


On Sat, 17 Aug 2019 at 14:10, Mikkel Fahnøe Jørgensen <[e-mail]>
wrote:

> +1
>
>
> On 17 August 2019 at 00.08.06, Jana Iyengar ([e-mail]) wrote:
>
> +1 to removing the current priorities from HTTP/3.
>
> On Thu, Aug 15, 2019 at 8:49 PM Mark Nottingham <[e-mail]
> <mnot@mnot..net>> wrote:
>
>> In Montreal, we had a discussion about priorities, where the outcome was
>> that people in the room agreed to defer to the HTTP Working Group regarding
>> whether HTTP/3 should ship with something compatible with HTTP/2 priorities
>> in it:
>>
>> https://github.com/quicwg/wg-materials/blob/master/ietf105/minutes.md#h3-priorities
>>
>> Since then, the HTTP Working Group has come to consensus that it does not
>> believe we should do so:
>>   https://www.w3.org/mid/[e-mail]
>>
>> This consensus call is to confirm this approach in this WG. In practical
>> terms, it means we will remove the current HTTP/2-aligned priorities
>> machinery from HTTP/3. It does NOT necessarily mean that HTTP/3 will ship
>> without any form of priorities; just not this one. Doing so will resolve a
>> number of outstanding issues, and make way for a replacement scheme,
>> currently under discussion in a design team in the HTTP Working Group.
>>
>> Please respond by the middle of next week; we'd like to move forward with
>> this resolution.
>>
>> Kind regards,
>>
>> --
>> Mark Nottingham   https://www.mnot.net/
>>
>>

-- 

Robin Marx
PhD researcher - web performance
Expertise centre for Digital Media

T [phone] - GSM [phone]

www.uhasselt.be
Universiteit Hasselt - Campus Diepenbeek
Agoralaan Gebouw D - B-3590 Diepenbeek
Kantoor EDM-2.05