Re: Priority signals in HTTP/2

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:

On Fri, Dec 18, 2020 at 10:12 AM Robin MARX <robin.marx@uhasselt.be> wrote:

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

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



> 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 <cory@lukasa.co.uk> wrote:
>
>> I think this looks like a reasonable approach to me.
>>
>> On Fri, 18 Dec 2020 at 02:26, Martin Thomson <mt@lowentropy.net> wrote:
>> >
>> > 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.
>> >
>> >
>> >
>>
>>
>
> --
>
> 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
>
>
>