Extensible Prioritization Scheme for HTTP
draft-ietf-httpbis-priority-12

Kudos on another well done document.

While it's certainly not necessary, I suggest that Section 16 be broken up into one subsection for each IANA action being requested.

Thank you to Robert Sparks for the SECDIR review.

Section 16.  Typo. s/the the/the/

Thanks for working on the HTTP priority. I hope to see this specification gets deployed and we learn how to efficiently use priorities more.

I have two comments that might have been already thought about -

  - Section 12: I was wondering how much it would be different to have same considerations for TCP as we have for QUIC - specially for "Endpoints SHOULD prioritize retransmission of data over sending new data, unless priorities specified by the application indicate otherwise". Could this be a very transport agnostic behavior this specification can define?

  - Section 13.1 : it says  -

      "if a server knows the intermediary is coalescing requests, then it could avoid serving the responses in their entirety and instead distribute bandwidth (for example, in a round-robin manner)"

    It would be great if we can mention any known or standard way for the servers to know about the intermediary. If there is non or if the is not deterministic way for the server to learn about how the intermediary works then I would argue that Section 13.1 is an unnecessary details.

Thank you for the work put into this document. It is really easy to read and it should bring real values.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Tommy Pauly for the shepherd's write-up including the section about the WG consensus.

I hope that this helps to improve the document,

Regards,

-éric

I like the way that urgency and incremental are defined and used.

-- Section 4.1 --
Please bear with my lack of knowledge here, but I wonder what is the expected client behaviour in the absence of SETTINGS_NO_RFC7540_PRIORITIES ? Should it keep using the 2 priority signals ?

I also wonder about the asymmetry between the 2nd and 3rd paragraph, i.e., may the client continue to send both priority signales in the 2nd paragraph ?
 
-- Section 4.3 --
Should the 'community' be defined in "cannot be agreed upon in the community" ?

-- Section 6 --
Does the describe used of u=7 contradict the one described earlier as "delivery of software updates" in section 4.1 ? Perhaps add the pre-fetch use case in section 4.1 ?

-- Section 7.1 --
Should this be "Type (i) = 0x10" in the figure 1 to match the text "(type=0x10)" in the first paragraph ?

Thanks for another well-written and easy-to-read document from the
HTTPBIS WG!

Many thanks to Bob Briscoe for the detailed tsv-art review, and to the
authors for the updates and responses to him.
Thanks as well to Robert Sparks for the secdir review.

I put my editorial suggestions in
https://github.com/httpwg/http-extensions/pull/1861 (to the extent that
I have concrete suggestions).

Section 4

   Intermediaries can consume and produce priority signals in a
   PRIORITY_UPDATE frame or Priority header field.  Sending a
   PRIORITY_UPDATE frame preserves the signal from the client, but
   provides a signal that overrides that for the next hop; see
   Section 14.  [...]

I'm having a bit of trouble following "provides a signal that overrides
that for the next hop"; is the "that" in "overrides that" referring to
"the signal from the client"?  Is the "signal that overrides" referring
to the PRIORITY_UPDATE frame emitted by the intermediary in question?
That seems to set us up for a scenario where the same frame is both
preserving and overriding the signal from the client, which doesn't make
much sense.  Is it perhaps that "when used by downstream intermediaries,
this mechanism would override the signal from the client, even though
the current intermediary under discussion has preserved the signal from
the client"?

Section 4.3.1

   When reviewing registration requests, the designated expert(s) can
   consider the additional guidance provided in Section 4.3 but cannot
   use it as a basis for rejection.

That seems to invite the question of what *can* be used as a basis for
rejection?  Or is the presence of any written specification sufficient
to trigger a "shall-issue" registration?

Section 7

   Servers SHOULD buffer the most recently received PRIORITY_UPDATE
   frame and apply it once the referenced stream is opened.  Holding
   PRIORITY_UPDATE frames for each stream requires server resources,
   which can can be bounded by local implementation policy.  [...]

Just to confirm my understanding: this local policy being described
would be distinct from the limit on the number of streams that the
client is allowed to open (which would also serve as a limit on the
amount of resources committed to storing priority information), right?

Section 9

   A client MAY use priority values to make local processing or
   scheduling choices about the requests it initiates.

Are the values in question here the server-generated response priority
values (used to affect future requests) or the client's own generated
priority values (used to affect those same requests)?

Thanks to Maria Ines Robles for their General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/k0c2L3WOP5A_dxSAHzy6PkmoHvw).

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 1. , paragraph 3, nit:
> have their own needs that are independent from client needs, so they often co
>                               ^^^^^^^^^^^^^^^^
The usual collocation for "independent" is "of", not "from". Did you mean
"independent of"?

Section 1. , paragraph 4, nit:
> s as input into prioritization decision making. The design and implementatio
>                                ^^^^^^^^^^^^^^^
The noun "decision-making" (= the process of deciding something) is spelled
with a hyphen.

Section 5. , paragraph 4, nit:
> ream, allowing them to be sent independent from the stream that carries the r
>                                ^^^^^^^^^^^^^^^^
The usual collocation for "independent" is "of", not "from". Did you mean
"independent of"?

Section 7.2. , paragraph 9, nit:
> ded value. This is different from the the request header field, in which omi
>                                   ^^^^^^^
Two determiners in a row. Choose either "the" or "the".

Section 8. , paragraph 9, nit:
>  SHOULD be served by sharing bandwidth amongst them. Incremental resources a
>                                    ^^^^^^^
Do not mix variants of the same word ("amongst" and "among") within a single
text.

Section 10. , paragraph 3, nit:
> t generation order might lead to sub-optimal results at the client, as early
>                                  ^^^^^^^^^^^
This word is normally spelled as one.

Section 13.2. , paragraph 2, nit:
> n registers the following entry in the the Hypertext Transfer Protocol (HTTP)
>                                    ^^^^^^^
Two determiners in a row. Choose either "the" or "the".

These URLs point to tools.ietf.org, which is being deprecated:
 * http://tools.ietf.org/agenda/83/slides/slides-83-httpbis-5.pdf

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.

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.

Thanks for a well written document.