Subject: Call for consensus: HTTP/2 Priorities

From: Mark Nottingham <[email-masked]>
Date: Fri, 16 Aug 2019 13:49:22 +1000

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/[email-masked]

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/

---

From: Jana Iyengar <[email-masked]>
Date: Fri, 16 Aug 2019 15:07:37 -0700

+1 to removing the current priorities from HTTP/3.

On Thu, Aug 15, 2019 at 8:49 PM Mark Nottingham <[email-masked]> 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:
>
> 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.
>

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Sat, 17 Aug 2019 08:09:26 -0400

+1

On 17 August 2019 at 00.08.06, Jana Iyengar ([email-masked]) wrote:

---

From: Robin MARX <[email-masked]>
Date: Sat, 17 Aug 2019 15:54:03 +0200

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

-- 

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

T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94

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

---

From: Ryan Hamilton <[email-masked]>
Date: Sat, 17 Aug 2019 07:10:23 -0700

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 <[email-masked]> wrote:

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

---

From: Tommy Pauly <[email-masked]>
Date: Sat, 17 Aug 2019 10:30:26 -0700

> On Aug 17, 2019, at 6:54 AM, Robin MARX <[email-masked]> wrote:
> 
> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> +1
> 
> 
> On 17 August 2019 at 00.08.06, Jana Iyengar ([email-masked] <mailto:[email-masked]>) wrote:
> 
>> On Thu, Aug 15, 2019 at 8:49 PM Mark Nottingham <[email-masked] <mailto:mnot@mnot..net>> wrote:
>>   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>
>> 
>>   https://www.w3.org/mid/[email-masked] <https://www.w3.org/mid/[email-masked]>
>> 
>> Mark Nottingham   https://www.mnot.net/ <https://www.mnot.net/>
>> 
> 
> 
> -- 
> 
> Robin Marx
> www.uhasselt.be <http://www.uhasselt.be/>

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 26 Aug 2019 17:01:26 +1000

Hi Robin,

Thanks for taking the time to respond.

I think these points are well taken; by far most people want to get a priority hinting mechanism into H3. Personally I view this as clearing the decks to let that happen; if we aren't distracted by the myriad issues with H2 priorities, it looks like we can get something simple in pretty quickly.

Additionally, this is definitely NOT a consensus call to ship H3 without priority hints at all; if we do that, we'd need to come to a separate consensus for that first, and my current reading is that there's not a will to do so yet.

Cheers,

> On 17 Aug 2019, at 11:54 pm, Robin MARX <[email-masked]> wrote:
> 
> 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
> On Sat, 17 Aug 2019 at 14:10, Mikkel Fahnøe Jørgensen <[email-masked]> wrote:
> +1
> 
>

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 27 Aug 2019 08:49:01 +1000

After the discussion in the room and on the list, it appears we have consensus.

Cheers,

> On 16 Aug 2019, at 1:49 pm, Mark Nottingham <[email-masked]> wrote:
>