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

On Wed., 31 Jul. 2019, 02:56 Lucas Pardue, <lucaspardue.24.7@gmail.com>
wrote:

> Hi Kari,
>
> On Tue, Jul 30, 2019 at 4:52 PM Kari Hurtta <hurtta-ietf@elmme-mailer.org>
> wrote:
>
>> Why boolean ("ENABLE") ?
>
>
>> I suggests SETTINGS Parameter
>>
>> SETTINGS_PRIORITY_SCHEME
>>
>> 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
>> with SETTINGS_PRIORITY_SCHEME once
>>
>> 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:
>>     Suggest SETTINGS_PRIORITY_SCHEME once
>>     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.
>
> Regards
> Lucas
>


At the risk of bike-shedding, I think calling it "enable" is a bit of an
issue. The setting, as an advertisement of the sender's capability, should
say something like "will ignore" (for disabling 7540 priorities) or "can
understand" (for enabling some other scheme).

Unless we also feel the need to advertise "will not send"?

Cheers
-- 
Matthew Kerwin

>