Re: Comments on Extensible Prioritization Scheme for HTTP

On Thu, Mar 31, 2022 at 03:20:50PM +0100, Lucas Pardue wrote:
> Instead, an HTTP/2 server that send SETTINGS_NO_RFC7540_PRIORITIES=1
> is most likely going to support Extensible Priorities because there
> is nothing else.

I think the logic of that statement is the strongest argument that
the setting name is indirect and suboptimal.

My server could send SETTINGS_NO_RFC7540_PRIORITIES to simply mean
"I ignore PRIORITY frames, so don't bother sending them".  Why should
that imply support for PRIORITY_UPDATE?

In that light, I interpret my proposed
  SETTINGS_ENABLE_PRIORITY_UPDATE
as a clearer, and possible equivalent to Lucas, to the *inversion* of
  SETTINGS_NO_RFC7540_PRIORITIES

If SETTINGS_NO_RFC7540_PRIORITIES 0 implies to Lucas to "use the only
other current alternative which is PRIORITY_UPDATE", then why not have
the setting be to communicate directly that the server supports
PRIORITY_UPDATE?

Why is the indirect SETTINGS_NO_RFC7540_PRIORITIES better?
The reason for creating PRIORITY_UPDATE is due to limitations in
practical use (and implementations).  How can we be so sure that
PRIORITY_UPDATE will be a "perfect" replacement?

>> Communicating and negotiating features is not new.  For example, the
>> *1977* RFC 731 for telnet has IAC WILL/IAC WONT and IAC DO/IAC DONT.
> 
> I don't see the relevance between telnet and HTTP/2 or HTTP/3.

Expressing "I do (do not) support"  (IAC DO/IAC DONT)
Expressing "I will (will not) use"  (IAC WILL/IAC WONT)

A server may wish to say one or more of
  I can use PRIORITY frames (or I ignore PRIORITY frames)
  I can use PRIORITY_UPDATE frames (or I ignore PRIORITY_UPDATE frames)
This directly communicates available features (e.g. IAC DO)

I think the proposed overloading of SETTINGS_NO_RFC7540_PRIORITIES is
indirect and unnecessarily confusing.

On Thu, Mar 31, 2022 at 04:04:15PM +0200, Willy Tarreau wrote:
>>    Similarly, if the client receives SETTINGS_NO_RFC7540_PRIORITIES with
>>    value of 0 or if the settings parameter was absent, it SHOULD stop
>>    sending PRIORITY_UPDATE frames (Section 7.1), since those frames are
>>    likely to be ignored.
>
>I'm personally not seeing a problem here. What it says is that if the
>peer announces that it doesn't want to abandon the default behavior,
>the one seeing this must respect this and not switch to the alternate
>one.

I got confused with the indirect logic.

As above, because of the overloading and inverted logic, there is no way
for the server to communicate exactly what it supports if the server
supports both.  A client might or might not send
SETTINGS_NO_RFC7540_PRIORITIES.

On the other hand, I think it much more direct if a client or server
sends SETTINGS_ENABLE_PRIORITY or SETTINGS_ENABLE_PRIORITY_UPDATE,
and sending one does not imply anything about the other.
End-to-end?  Hop-by-hop?  PRIORITY is independent from PRIORITY_UPDATE.

If a separate SETTINGS_ENABLE_PRIORITY is not desirable, then
SETTINGS_ENABLE_PRIORITY_UPDATE could imply that PRIORITY_UPDATE
should be used instead of PRIORITY.

Cheers, Glenn

Received on Thursday, 31 March 2022 15:15:50 UTC