W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2019

Re: SETTINGS_PRIORITY_SCHEME | Re: Setting to disable HTTP/2 Priorities

From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Tue, 30 Jul 2019 17:51:36 +0100
Message-ID: <CALGR9oZnKo1JXnxLiKp+04kJeT5Uek3BiCPq=XSq4dG4B3AUBA@mail.gmail.com>
To: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
Cc: HTTP Working Group <ietf-http-wg@w3.org>, Dmitri Tikhonov <dtikhonov@litespeedtech.com>, Brad Lassey <lassey@chromium.org>
Hi Kari,

On Tue, Jul 30, 2019 at 4:52 PM Kari Hurtta <hurtta-ietf@elmme-mailer.org>

> Why boolean ("ENABLE") ?

> I suggests SETTINGS Parameter
> with values
>  • 0             Sender of SETTINGS frame indicates that
>                  it does not process or send priority
>                  values
>  • 1             Sender of SETTINGS frame indicates that
>                  it process or send RFC7540 priorities
>  • unknown value (for recipient of SETTINGS frame)
>                  Sender of SETTINGS frame indicates that
>                  it is willing process some priority information
>                  or that it sends some priority information
>                  (but recipient of SETTINGS frame does
>                   not recognize these priorities)
> Default value for SETTINGS_PRIORITY_SCHEME is 1
> ( RFC7540 priorities aka current HTTP/2 tree priorities).
> Peer of HTTP/2 connection should send SETTINGS frame
> Peer of HTTP/2 connection may send second SETTINGS frame
> with SETTINGS_PRIORITY_SCHEME if it's value is same
> than which it is received for peer on SETTINGS frame.
> That is:
>     and send SETTINGS_PRIORITY_SCHEME second time
>     after that when you agreed with peer.
> That makes SETTINGS_PRIORITY_SCHEME switch to
> new priority scheme (when that is defined).

Boolean gives us the MVP for moving away from RFC7540 priorities. The
suggestion to allow also signalling "something else" is valid and has been
mentioned by some others, thanks for sharing your thoughts.
My personal concern is that making this too complicated may result in it
not getting exercised in practice. This, to my mind, includes picking
something that is a fit for HTTP/3 too.

How would you feel about an an alternative design that uses two settings?
I.e. one for RFC750 enablement, and another to enable a specific
prioritisation scheme.

HTTP/3 allows only one SETTINGS frame in each direction, so using that as a
negotiation mechanism has problems. Boolean unilateral adverts work better
in that case. We might want to say that HTTP/3 has RFC7540 priorities
always default to disabled and not specify a setting in the core draft to
enable them. Then, using additional boolean settings per scheme would allow
a more common approach to priority scheme selection across H2 and H3.


> / Kari Hurtta
Received on Tuesday, 30 July 2019 16:52:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:15:39 UTC