Re: Call for consensus: HTTP/2 Priorities

[Tommy Pauly <[e-mail]>]

> On 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 think that many people, if not most, agree that we would like some form of priority hinting in H3. The best-case scenario is that we have a new priority mechanism for H3 (that's potentially minimal); followed by no priority mechanism (but letting one be specified soon); and the least-preferred option is to just maintain H2 priorities.

We do have a design team that's tasked with coming up with a solution for H3, that Ian Swett is leading. I would encourage you to provide input or suggestions to that process.

Best,
Tommy

> 
> 
> 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 <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] <mailto:[e-mail]>> wrote:
> +1
> 
> 
> On 17 August 2019 at 00.08.06, Jana Iyengar ([e-mail] <mailto:[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] <mailto: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 <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] <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/ <https://www.mnot.net/>
>> 
> 
> 
> -- 
> 
> Robin Marx
> PhD researcher - web performance
> Expertise centre for Digital Media
>  
> T [phone] - GSM [phone]
>  
> www.uhasselt.be <http://www.uhasselt.be/>
> Universiteit Hasselt - Campus Diepenbeek
> Agoralaan Gebouw D - B-3590 Diepenbeek
> Kantoor EDM-2.05
>  
>