Subject: Priority signals in HTTP/2

From: "Martin Thomson" <[email-masked]>
Date: Fri, 18 Dec 2020 13:22:19 +1100

Now that we're official, I'd like to get started on some of the more difficult pieces: priority.

I wrote up a proposed plan for dealing with the priority signaling in RFC 7540 here: https://github.com/httpwg/http2-spec/issues/773#issuecomment-725285414

What do people think about this general approach (quoting):

1.    Cut the section with the detailed explanation and replace it with some explanatory text about the importance of having prioritization in a multiplexed transport (though not necessarily signaling thereof).

2.    Explain that this document used to define a priority signaling scheme, but that the one that was defined was unsuccessful.

3.    In that section recommend against using the priority signaling scheme from RFC 7540, but explain that other endpoints that you talk to might send these frames.

4.    Point to the new signaling system if that is mature enough (and probably even if it is not).

5.    Suggest, but not recommend, that servers pay attention to priority signals using these old mechanisms in the absence of other signals. This might take a little careful wording, but it's probably enough to caution that ignoring signals might degrade performance and some signals might be better than none. Point to RFC 7540 for the details of how the old scheme works.

6.    Leave the definition of the frame type intact, but cut the definitions right down to just the necessary pieces sizes, names, and any mandatory processing (error handling, sizes, ranges, the hard stuff). This should ensure that people are able to do things like generate the right error codes and skip over the HEADERS frame pieces properly.

7.    Leave text about when PRIORITY can be sent in the state machine. This is important for interoperating with endpoints that generate the frame.

---

From: Cory Benfield <[email-masked]>
Date: Fri, 18 Dec 2020 09:36:25 +0000

I think this looks like a reasonable approach to me.

---

From: Robin MARX <[email-masked]>
Date: Fri, 18 Dec 2020 11:07:44 +0100

Hello all,

I too feel this is a reasonable approach, with two remarks on two of your
points:

4. Since the new signaling system is intended to be HTTP/2 compatible and
also has quite a bit of text on this, I feel this would indeed make sense
(for reference: [1])

5. I wonder if it's useful to recommend different default priorities here.
In RFC 7540, the default is fully fair Round Robin, which has been shown to
be one of the worst case scenarios for typical web page traffic.
    A more sequential default would fit better in this case. For example,
this could become "All streams are initially assigned an exclusive
dependency on the currently active stream with the highest stream ID".
    This is identical to the default behaviour in the new signaling system
and conceptually similar to Chromium's setup.
    I'm not sure this is really necessary, but if there's one thing I'd
change about H2's setup, it's that.
    It might be good to include this guidance for implementers who will
start integrating the new signaling and want to minimally update existing
code for clients that stick to the old system for the time being.

With best regards,
Robin

[1]: https://tools.ietf.org/html/draft-ietf-httpbis-priority-02

On Fri, 18 Dec 2020 at 10:37, Cory Benfield <[email-masked]> wrote:

> > I wrote up a proposed plan for dealing with the priority signaling in
> RFC 7540 here:
> https://github.com/httpwg/http2-spec/issues/773#issuecomment-725285414
> >
> > 1.    Cut the section with the detailed explanation and replace it with
> some explanatory text about the importance of having prioritization in a
> multiplexed transport (though not necessarily signaling thereof).
> >
> > 2.    Explain that this document used to define a priority signaling
> scheme, but that the one that was defined was unsuccessful.
> >
> > 3.    In that section recommend against using the priority signaling
> scheme from RFC 7540, but explain that other endpoints that you talk to
> might send these frames.
> >
> > 5.    Suggest, but not recommend, that servers pay attention to priority
> signals using these old mechanisms in the absence of other signals. This
> might take a little careful wording, but it's probably enough to caution
> that ignoring signals might degrade performance and some signals might be
> better than none. Point to RFC 7540 for the details of how the old scheme
> works.
> >
> > 6.    Leave the definition of the frame type intact, but cut the
> definitions right down to just the necessary pieces sizes, names, and any
> mandatory processing (error handling, sizes, ranges, the hard stuff). This
> should ensure that people are able to do things like generate the right
> error codes and skip over the HEADERS frame pieces properly.
> >
> > 7.    Leave text about when PRIORITY can be sent in the state machine.
> This is important for interoperating with endpoints that generate the frame.
> >
> >
> >
>
>

-- 

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: Lucas Pardue <[email-masked]>
Date: Fri, 18 Dec 2020 20:21:22 +0000

I think this is a good start Martin, I'd like to see a PR based on this
approach and promise to review it.

To respond to Robin:

> code for clients that stick to the old system for the time being.

I appreciate the sentiment but I think this oversteps from "if you really
want to bang your head on the wall, go to the wall" to recommending a
slightly slightly less painful method of headbanging. We have a better
alternative scheme, let's incentivise that.

A server won't know if a client is omitting H2 priority because it
purposefully wants Round Robin scheduling. Its a stupid deault but its an
easy default. As I've just discovered, talking about H2 priorities wrt
streams and pushes is tricky. So I suggest we don't spend text on it in
this document.

Cheers
Lucas

>> > 5.    Suggest, but not recommend, that servers pay attention to
>> priority signals using these old mechanisms in the absence of other
>> signals. This might take a little careful wording, but it's probably enough
>> to caution that ignoring signals might degrade performance and some signals
>> might be better than none. Point to RFC 7540 for the details of how the old
>> scheme works.
>> >

---

From: Greg Wilkins <[email-masked]>
Date: Sat, 19 Dec 2020 16:00:59 +0100

On Fri, 18 Dec 2020 at 03:26, Martin Thomson <[email-masked]> wrote:

> I wrote up a proposed plan for dealing with the priority signaling in RFC
> 7540 here:
> some explanatory text

OK

> about the importance of having prioritization in a multiplexed transport
> (though not necessarily signaling thereof).
>

Lost me here!    I'm just not sure that it is universally true that
priorities are needed in a multiplexed transport.   I'm sure there are some
circumstances that need them, but I am far from convinced that they are
generally required nor that the complexity of implementation is justified
in many of the cases that they might be conceptually useful.

> scheme from RFC 7540, but explain that other endpoints that you talk to

OK - I'm back onboard with 2. and 3.

4.    Point to the new signaling system if that is mature enough (and
> probably even if it is not).
>

I don't think that any new priority signalling system should be linked or
recommended unless it has been proven to be of general benefit.
However, I'd not be opposed to defining a general signalling system that
would allow consenting endpoints to exchange arbitrary signals. Such a
system could be used as the basis for a priority conversation if/when
something is agreed, but would be ignorable by non consenting/participating
endpoints.  It would also better allow for experimenting with alternate
solutions and optimizations (eg perhaps some extension to flow control
would be better than priorities).

> better than none. Point to RFC 7540 for the details of how the old scheme

As a server implementor (jetty), we have thought long and hard about any
way we can realistically implement priorities in a way that would not hurt
our general overall performance for non prioritized handling.  It may be
true that ignoring priorities MIGHT degrade performance, but I think it is
equally true that implementing priorities MAY itself degrade performance.
We've deployed HTTP/2 in some very large scale high performance
situations and our lack of priorities has not been an issue.

So the careful wording should say that the RFC7540 priorities may help
performance in some circumstances, but that it may also be valid to ignore
them. Ie it should say "your mileage may vary"!

> This is important for interoperating with endpoints that generate the frame.

Definitely need to keep this for interoperability.  Some endpoints will
send PRIORITY frames for the foreseeable future, so we can't pretend they
don't exist, even if we ultimately ignore them.

-- 
Greg Wilkins <[email-masked]> CTO http://webtide.com

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 19 Dec 2020 18:04:53 +0100

Hi Martin,

> What do people think about this general approach (quoting):
(...)

I think I'm OK with this plan. I'm just thinking, do we have an exhaustive
list of the most annoying problems caused by the current scheme and do we
think that we could bring back some value if they were at least partially
addressed ? If so, maybe we could have the following recommendations by
order of preference:
  - new priority scheme (yet to be defined)
  - "fixed" version of the previous one to be used as a second option,
    expected to work better than nothing with existing implementations;
  - no priority handling at all (i.e. round robin or random)

Just my two cents,
Willy

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 21 Dec 2020 10:04:20 +1100

Thanks for the input Greg.

On Sun, Dec 20, 2020, at 02:00, Greg Wilkins wrote:
> > about the importance of having prioritization in a multiplexed transport (though not necessarily signaling thereof).
> 
> priorities are needed in a multiplexed transport.   I'm sure there are 
> some circumstances that need them, but I am far from convinced that 
> they are generally required nor that the complexity of implementation 
> is justified in many of the cases that they might be conceptually 
> useful.

I'm not talking about sending signals to the other side, I'm talking about an endpoint allocating its resources in a fashion appropriate to their needs.  When we say PRIORITY, we refer to one endpoint telling the other what it wants.  We don't need that necessarily if you know enough from context.

I think that we have enough information now to know that - in general - it is good to know what is most important to send and prioritizing sending that.

> I don't think that any new priority signalling system should be linked 
> or recommended unless it has been proven to be of general benefit.
> However, I'd not be opposed to defining a general signalling system 
> that would allow consenting endpoints to exchange arbitrary signals. 
> Such a system could be used as the basis for a priority conversation 
> if/when something is agreed, but would be ignorable by non 
> consenting/participating endpoints.  It would also better allow for 
> experimenting with alternate solutions and optimizations (eg perhaps 
> some extension to flow control would be better than priorities).

This is the part that is hard.  I don't think that we can safely point to a general benefit from any scheme yet.  Nor do I think that this reference would need to be as firm as "please use this instead".  I was thinking that it would be of the form "other methods of signaling priority might be developed, see [x]".  Sticking a recommendation on it would be premature, I agree.

It's quite possible that FIFO handling of queries will serve you fine.  Robin Marx showed that that is far better than round robin for a few use cases.

> performance in some circumstances, but that it may also be valid to 
> ignore them. Ie it should say "your mileage may vary"!

Yes.  You correctly identified one of the challenges with the 7540 scheme: in addition to the non-trivial engineering cost of doing something complicated, you have the uncertainty associated with knowing that the extra cycles you spend were worth it.  I know that we saw some evidence that it was worth it under controlled circumstances, but it's hard to know if that research scales to large-scale deployments.

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 21 Dec 2020 10:09:22 +1100

Hi Willy,

>   - no priority handling at all (i.e. round robin or random)

I don't want to get too much into the shortcomings of the existing scheme, except for those things we know to be firmly true.  The only thing that I think can be said definitively is that attempting to send responses one at a time is better than trying to evenly share available capacity between multiple responses.

I expect that the new thing we ship will be much better than that, but it's probably best to let that specification speak for itself.