Re: Comments on Extensible Prioritization Scheme for HTTP

On Thu, Mar 31, 2022 at 05:41:09PM +0200, Willy Tarreau wrote:
> On Thu, Mar 31, 2022 at 11:15:29AM -0400, Glenn Strauss wrote:
> > 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.

I continue to strongly disagree with using the flag as an implication.

Rather than SETTINGS_NO_RFC7540_PRIORITIES=1, I think a more logical
approach is to use affirmative signals, as suggested in
https://datatracker.ietf.org/doc/html/draft-lassey-priority-setting-00
which proposed SETTINGS_ENABLE_HTTP2_PRIORITIES.

I think the above should apply to SETTINGS_ENABLE_PRIORITY_UPDATE.

Should PRIORITY_UPDATE prove to be more widely implemented than
PRIORITY, then use of PRIORITY by clients will phase itself out without
further action, and even without the need for something like
SETTINGS_ENABLE_HTTP2_PRIORITIES.

Prioritization is flexible, and the server may ignore the priority
signals provided by the client.

I am an implementer.  My server (lighttpd) parses PRIORITY frames
to comply with RFC7540 (HTTP/2), but otherwise ignores them.
lighttpd plans to continue to ignore PRIORITY frames.

For widest client compatibility, lighttpd also plan to omit sending
SETTINGS_NO_RFC7540_PRIORITIES=1

https://mikebishop.github.io/http-misc-extensions/draft-bishop-httpbis-grease.html
"HTTP/2 [HTTP2] frame types and settings employ a similar mechanism of
 ignoring unknown values. This makes HTTP/2 a good candidate to employ
 grease on connections. The need for such a technique was demonstrated
 recently by an HTTP/2 implementation which closed the connection upon
 receipt of an unknown setting."

*If* the proposal for PRIORITY_UPDATE included an affirmative signal,
such as the client sending SETTINGS_ENABLE_PRIORITY_UPDATE=1, then the
server could be more confident that the client would likely understand
the same setting SETTINGS_ENABLE_PRIORITY_UPDATE (0/1) sent by the
server back to the client.

Currently, SETTINGS_NO_RFC7540_PRIORITIES=1 is proposed for client to
tell the server that the server need not keep RFC7540 PRIORITY state,
but existing clients do not send that, and many also do not utilize
PRIORITY.  If PRIORITY gets deprecated, then over time, the sending of
SETTINGS_NO_RFC7540_PRIORITIES=1 will end up being wasted bytes.
However, the proposed use of SETTINGS_NO_RFC7540_PRIORITIES=1 overloads
the setting with an *indirect* meaning to use PRIORITY_UPDATE, and I
disagree with this overloading.

> > then why not have the setting be to communicate directly that the
> > server supports PRIORITY_UPDATE?
> 
> Probably because it was considered that the vast majority of
> implementations would advertise the two at once anyway, and that the
> extra cost for those willing to implement nothing is close to zero.

One data point: as justified above, lighttpd plans to omit advertising
what I do not think needs to be advertised.

> > 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.
> 
> Maybe the essential point you forgot is that once the server sends its
> settings, it's too late for the client to make a different choice because
> usually the client will send preface + settings + one or a few requests,
> then all the server can do is confirm the client's choices. As such the
> client will not wait for the server's response before starting to send.
> I guess that if the client sends the setting to 1 and the server doesn't
> send anything or sends it to zero, most likely the client will just
> refrain from sending PRIORITY frames (since it promised not to via the
> initial setting) and it will not send PRIORITY_UPDATE frames either since
> the server didn't mention accepting them.

BTW, during an initial connection open, a client can send PRIORITY
information as part of HEADERS by setting the PRIORITY flag.  There is
little need to send PRIORITY frames that early in the connection.
Also, during an initial connection, the client can open request streams
in (basic) order of priority, should the client have more than one
stream to open that early in the connection.

A client which is optimizing for bandwidth might omit sending
PRIORITY_UPDATE frames with the initial connection until after
receiving server connection preface, unless the client has previously
connected to the server and the server previously indicated
affirmative support for PRIORITY_UPDATE (indirect and not required
with the current proposal from Pardue).

(SETTINGS_NO_RFC7540_PRIORITIES=1 is not required, since clients and
 servers should ignore unknown settings)

> > A client might or might not send SETTINGS_NO_RFC7540_PRIORITIES.
> 
> Then in this case the client wants to stay on the RFC7540 behavior.

That is not optimal for the server (if the server implements PRIORITY),
since the server might not want to unnecessarily keep the priority
state if the client does not plan to use it.

PRIORITY is not widely implemented according to Pardue's proposal.
A client could simply *not send* SETTINGS_NO_RFC7540_PRIORITIES
and *not send* PRIORITY frames.  The server is then left keeping
unnecessary state.  Then again, if PRIORITY is deprecated, the
server might choose to ignore PRIORITY.

tl;dr: if PRIORITY is not widely implemented, then
SETTINGS_NO_RFC7540_PRIORITIES=1 would be better named
SETTINGS_ENABLE_PRIORITY_UPDATE=1 for an affirmative signal
that the client intends to use PRIORITY_UPDATE.  The server
might (optionally) confirm with SETTINGS_ENABLE_PRIORITY_UPDATE=1.

? Do other implementers think that PRIORITY_UPDATE frames will be sent
frequently enough to warrant SETTINGS_ENABLE_PRIORITY_UPDATE=1?
Might these settings simply be omitted, and PRIORITY deprecated?
(and SETTINGS_NO_RFC7540_PRIORITIES=1 omitted, too?) Since PRIORITY is
not widely implemented, does there need to be a mechanism to disable it?
Perhaps a future revision to HTTP/2 can simply deprecate PRIORITY.

Cheers, Glenn

Received on Saturday, 9 April 2022 11:26:19 UTC