Re: Call for consensus: HTTP/2 Priorities

[Ryan Hamilton <[e-mail]>]

I agree with the proposal of removing HTTP/2 priorities from HTTP/3. HTTP/2
Priorities are overly complicated for the task at hand (as the
implementation experience with HTTP/2 suggests). I look forward to the
priority design team's output.

On Sat, Aug 17, 2019 at 6:54 AM Robin MARX <[e-mail]> wrote:

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