Re: Priority signals in HTTP/2

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