Re: Comments on Extensible Prioritization Scheme for HTTP

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

See it differently. PRIORITY_UPDATE is more flexible (contains text)
and the server is free to ignore them. So you could see this as a way
to say "I will not read your PRIORITY frames, but I may possibly read
your PRIORITY_UPDATE frames". I seem to remember that it was considered
that explicitly disengaging from both had little benefit considering
that as soon as the client was aware that it doesn't have to maintain
its priority tree, most of the effort is done.

> 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

No an inversion, you mean equivalent instead ?

> If SETTINGS_NO_RFC7540_PRIORITIES 0 implies to Lucas to "use the only
> other current alternative which is PRIORITY_UPDATE",

No, that's value 1.

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

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

Noone claims that, however using the same settings mechanism, a future
option could easily ask to replace this choice.

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

> A client might or might not send SETTINGS_NO_RFC7540_PRIORITIES.

Then in this case the client wants to stay on the RFC7540 behavior.

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

Not completely, you don't want to have both at once. It's not just the
way to convey the message that changes but also the way to calculate
priorities.

Willy

Received on Thursday, 31 March 2022 15:41:29 UTC