Re: Martin Duke's No Objection on draft-ietf-httpbis-priority-11: (with COMMENT)

Hi Martin,

Thanks for the review. Responses in-line:

On Tue, Dec 14, 2021 at 12:36 AM Martin Duke via Datatracker <
noreply@ietf.org> wrote:

> Martin Duke has entered the following ballot position for
> draft-ietf-httpbis-priority-11: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-httpbis-priority/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thanks to Bob Briscoe for the (extensive) TSVART review. From the thread,
> it
> looks like you have mostly addressed his concerns.
>
> Bob's question about the definition of fairness probably relates to the
> rich
> literature on this topic -- it's a bit more complicated than every
> connection
> getting the same bandwidth: https://en.wikipedia.org/wiki/Fairness_measure.
> It
> might be good to say exactly what you mean instead of falling back on the
> term
> of art, which carries a bit more complexity than I think you're asking
> for. But
> I think the considerations you have in Sec 13 are solid.
>

Could you elaborate a bit more? Bob's comment on fairness was in relation
to Section 13. We added some text in response to try and clarify what we
mean.  It's possible that ,by whatever precise means fairness is measured,
the actions of the intermediary could lead to unfairness. Therefore I'm not
sure about the value in quantifying fairness any further.


> It's interesting that PRIORITY_UPDATE cannot be sent by the server. Is it
> conceivable that processing of the request could lead to late change in the
> priority of different objects.
>

To paraphrase this scheme, it is primarily oriented around a client (and an
intermediary, if there is one) hinting to the HTTP server responsible for
prioritization about the initial conditions on which the response is to be
prioritized.

We acknowledge those conditions might change at the client; typically
because a client might load new things that invalidate the initial
conditions, or they switch focus and the objects could be backgrounded,
etc. The PRIORITY_UPDATE frame is a signal that can articulate this.

The important thing to realise though is that the signals are hints related
to a very small aspect of the prioritisation. There is no need for client
and server to keep well-coupled state about priority. The data flow we care
about is response data, the proof is in the pudding of how those response
bytes get delivered. If a server decides to throttle one response in favor
of another, it doesn't need to signal that.

It is conceivable that perhaps an origin server behind an intermediary
would like to send something like a PRIORITY_UPDATE to an intermediary. The
problem is that it would need to be kept up-to-date with what the client
has been saying said. And all this gets complicated when we throw in
intermediaries that need to convert to a version of HTTP that does not
support frames at all.

Nobody in the HTTP WG seemed to want us to design support for
server-to-client PRIORITY_UPDATE and I'm happy with that outcome. The good
news is that if someone really wanted to build that and document it, this
draft would be compatible with such a design extension. Either by relaxing
the rules for PRIORITY_UPDATE or defining a brand new frame type with very
similar contents.

Cheers,
Lucas