Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Editorial follow-up from 1601 #1688

Closed
wants to merge 2 commits into from
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 9 additions & 4 deletions draft-ietf-httpbis-priority.md
Original file line number Diff line number Diff line change
Expand Up @@ -126,13 +126,12 @@ An important feature of any implementation of a protocol that provides
multiplexing is the ability to prioritize the sending of information.
Prioritization is a difficult problem, so it will always be suboptimal,
particularly if one endpoint operates in ignorance of the needs of its peer.
Priority signalling allows endpoints to communicate their own view of priority
needs, which can be combined with other factors that are considered during the
peer's prioritization decision making.
Priority signalling allows endpoints to communicate their own view of priority,
which can be combined with information the peer has to inform scheduling.

RFC 7540 stream priority (see {{Section 5.3 of ?RFC7540}}) is a complex system
where clients signal stream dependencies and weights to describe an unbalanced
tree. It suffered from poor deployment and interoperability and was deprecated
tree. It suffered from limited deployment and interoperability and was deprecated
in a revision of HTTP/2 {{HTTP2}}. However, in order to maintain wire
compatibility, HTTP/2 priority signals are still mandatory to handle (see
{{Section 5.3.2 of HTTP2}}).
Expand Down Expand Up @@ -175,6 +174,12 @@ to more complicated processing. Problems found with this approach could not be
resolved and definition of a HTTP/3 priority signalling feature was removed
before publication.

Intermediaries can convert HTTP/2 to other versions of HTTP. HTTP/2 priority
signals are specific to a connection and there is no standard definition for
converting them to a format suitable for other versions. Therefore, a
motivating factor for replacing RFC 7540 stream priority is to choose a
signalling mechanism that is more accomodating of intermediaries.

Comment on lines +177 to +182
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I understand the intent of this paragraph but I'm not sure if it's entirely accurate. As stated in the paragraph above (starting from line 154), there is a standard way of coalescing HTTP/2 priority trees into one.

Maybe something like: HTTP/2 priority signal of an HTTP request is expressed as a value relative to that of other requests sharing the same connection and therefore it is impossible to express priority signals without the knowledge of how the requests are coalesced?

Separately, as this would be a problem statement, I think it might make sense to move before the paragraph right above this one, because we continue to say "Considering the problems (snip) and the difficulties in adapting it to HTTP/3..."

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right that H2-to-H2 can work. However, Ian's previous text said versions prior to HTTP/2. I was trying to be clever and use "other versions" to mean HTTP/1.1 and HTTP/3. There is no way to map RFC 7540 style priorities to H3, we gave up on that as noted in the paragraph above. I would say the prime motivation for giving up in H3 was not intermediary complication, which your suggested reordering might imply.

Copy link
Contributor

@kazuho kazuho Sep 27, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, I see. I think my concerns are:

  • The paragraph proposed is a mixture of problem statement and solution. That does not fit well into the current structure of the section that writes down the problems and then explaining the solution in the final paragraph below. I think we'd better cut down this paragraph to a problem statement, at the same time adding text to the final paragraph of the section to explain why the particular solution was chosen (if necessary).
  • As a problem statement, I'm not sure if it suites the most to state that the problem as about intermediaries. The insight that we have is that the crux of the problem is that Semantics does not have the concept of a "connection." Not only intermediaries but also HTTP client library API suffer from the problem. I'm fine with using intermediaries as an example.

So maybe something like: HTTP/2 priority signal of an HTTP request is expressed as a value relative to that of other requests sharing the same HTTP/2 connection. Such design requires the understanding of the underlying protocol version and how the requests are coalesced in order to use priority signals. This has been a burden to HTTP endpoints that generate or forward requests at the HTTP Semantic layer.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm happy with whatever you two prefer.

Considering the problems with the deployment of RFC 7540 stream priority, and
the difficulties in adapting it to HTTP/3, continuing to base prioritization on
this mechanism risks increasing the complexity of systems. Multiple experiments
Expand Down