Re: Comments on Extensible Prioritization Scheme for HTTP

On Sat, Apr 09, 2022 at 07:25:57AM -0400, Glenn Strauss wrote:
> Prioritization is flexible, and the server may ignore the priority
> signals provided by the client.

Absolutely, which is why for us as servers, this doesn't change much.
What really matters is how to provide the information the client needs
to act optimally.

> 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

HAProxy doesn't implement priority either and currently sends nothing.
However once this draft becomes standard, I plan to send this setting
to inform compatible clients that they do not have to expect any
particular behavior from it on this point. It's not a matter of client
compatibility, H2 agents are required to ignore unkonwn settings, so
those unaware of this setting will not change anything, while those
aware of it will benefit from it.

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

But for what purpose ? Why would the server which does not implement
priority care about what the client thinks ? *If* there would be any
benefit for a client in knowing that a server doesn't implement either
scheme, I would agree with you and would rather ask for two settings
or for a versioned one (e.g. advertise what scheme is supported). But
it doesn't seem like client implementers have requested that level of
distinction and many of them are represented in this working group.
Thus as a server implementer I'm just trusting them, if they think a
single setting is fine I'm not going to impose them a second one.

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

The most important is that many clients *do* support priority, that
these ones are already deployed and working fine, and that you cannot
suddenly break them by telling them "ah, you didn't read the news, the
default value recently changed and while you used to comply with the
standard now you violate it".

> If PRIORITY gets deprecated, then over time, the sending of
> SETTINGS_NO_RFC7540_PRIORITIES=1 will end up being wasted bytes.

Yes that's true. And probably that advertising the desired priority
scheme number instead would be better, with 0=not supported,
1=default=RFC7540, 2=priority_update, and so on. At least these bytes
would be re-usable for future schemes. But you cannot change the default
that works fine between a non-negligible set of clients and servers.

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

It could indeed be split or turned into an enum for more long-term
viability, but I can definitely understand why implementers do not feel
the need for two settings for the same switch in their code.

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

But this is where you're getting it wrong in my opinion. Just like me with
haproxy, you're having an INCOMPLETE IMPLEMENTATION. We both have some work
left to be done. This extension offers us an easy path to advertise that
we did not implement that part, instead of having to implement it, and
you're declining the offer. That's not consistent, I'm afraid. Yes I would
like to see a slightly different approach (e.g. implementation type as I
suggested above) but quite frankly, if I can already avoid to implement
all that non-optimal scheme at the expense of sending one byte, I will
do it, regardless of the setting's name! And for the long term I would
like to implement the new scheme (or at least parts of it) because it
looks much better to me.

For me what matters is what client implementers think. If a client tells
us that they would benefit from knowing the total lack of support versus
support for the new scheme, then a distinction would be better. That's up
to them.

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

It's not "should ignore" but "MUST ignore", and that's exactly what
encourages to advertise what you want to do, so that the peer that
know the setting are totally informed. That setting alone conveys two
information, one being "I will not send you PRIORITY frames nor require
that you build the dependency tree" and the other one being "I may
however send you some PRIORITY_UPDATES". It doesn't mean that it will
send them, just that it may.

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

That's precisely the reason for sending this setting.

> PRIORITY is not widely implemented according to Pardue's proposal.

"not widely implemented" is a proof of being suboptimal and the reason
for proposing a different approach, in hope that it will be much more
widely implemented. It doesn't mean we should punish all those who did
their job well (i.e. major browsers and servers) by suddenly declaring
them non-compliant or at least making them misbehave when facing an
updated peer!

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

The way you present it makes me feel like you imagine that all clients
and servers are replaced atomically in the whole world. That doesn't
work like this and is the reason why the working group focuses so much
on interoperability. The proposal here makes sure that a compliant
client talking to a compliant server can be upgraded in any order
without causing trouble to each other. Your proposal would for example
cause trouble to some applications if servers are upgraded before
clients, thus would force servers to update very late, and would
needlessly waste resources in non-upgraded servers for all upgraded
clients.

With the current proposal, instead, servers can be upgraded very
quickly, not changing the behavior with existing clients, then each
upgraded client benefits from this knowledge and at the same time can
save some server resources.

That's why one must never change default values once adopted, and why
the default set must be well thought before a standard is released!

Regards,
Willy

Received on Saturday, 9 April 2022 12:38:22 UTC