draft-ietf-httpbis-priority-05.txt   draft-ietf-httpbis-priority-06.txt 
HTTP K. Oku HTTP K. Oku
Internet-Draft Fastly Internet-Draft Fastly
Intended status: Standards Track L. Pardue Intended status: Standards Track L. Pardue
Expires: 28 March 2022 Cloudflare Expires: 4 April 2022 Cloudflare
24 September 2021 1 October 2021
Extensible Prioritization Scheme for HTTP Extensible Prioritization Scheme for HTTP
draft-ietf-httpbis-priority-05 draft-ietf-httpbis-priority-06
Abstract Abstract
This document describes a scheme for prioritizing HTTP responses. This document describes a scheme for prioritizing HTTP responses.
This scheme expresses the priority of each HTTP response using This scheme expresses the priority of each HTTP response using
absolute values, rather than as a relative relationship between a absolute values, rather than as a relative relationship between a
group of HTTP responses. group of HTTP responses.
This document defines the Priority header field for communicating the This document defines the Priority header field for communicating the
initial priority in an HTTP version-independent manner, as well as initial priority in an HTTP version-independent manner, as well as
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 28 March 2022. This Internet-Draft will expire on 4 April 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 32 skipping to change at page 2, line 32
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4
2. Motivation for Replacing RFC 7540 Priorities . . . . . . . . 4 2. Motivation for Replacing RFC 7540 Priorities . . . . . . . . 4
2.1. Disabling RFC 7540 Priorities . . . . . . . . . . . . . . 6 2.1. Disabling RFC 7540 Priorities . . . . . . . . . . . . . . 6
2.1.1. Advice when Using Extensible Priorities as the
Alternative . . . . . . . . . . . . . . . . . . . . . 7
3. Applicability of the Extensible Priority Scheme . . . . . . . 7 3. Applicability of the Extensible Priority Scheme . . . . . . . 7
4. Priority Parameters . . . . . . . . . . . . . . . . . . . . . 7 4. Priority Parameters . . . . . . . . . . . . . . . . . . . . . 7
4.1. Urgency . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Urgency . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Incremental . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Incremental . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. Defining New Parameters . . . . . . . . . . . . . . . . . 9 4.3. Defining New Parameters . . . . . . . . . . . . . . . . . 9
4.3.1. Registration . . . . . . . . . . . . . . . . . . . . 9 4.3.1. Registration . . . . . . . . . . . . . . . . . . . . 9
5. The Priority HTTP Header Field . . . . . . . . . . . . . . . 10 5. The Priority HTTP Header Field . . . . . . . . . . . . . . . 10
6. Reprioritization . . . . . . . . . . . . . . . . . . . . . . 11 6. Reprioritization . . . . . . . . . . . . . . . . . . . . . . 11
7. The PRIORITY_UPDATE Frame . . . . . . . . . . . . . . . . . . 11 7. The PRIORITY_UPDATE Frame . . . . . . . . . . . . . . . . . . 11
7.1. HTTP/2 PRIORITY_UPDATE Frame . . . . . . . . . . . . . . 12 7.1. HTTP/2 PRIORITY_UPDATE Frame . . . . . . . . . . . . . . 12
skipping to change at page 3, line 4 skipping to change at page 3, line 6
8. Merging Client- and Server-Driven Parameters . . . . . . . . 14 8. Merging Client- and Server-Driven Parameters . . . . . . . . 14
9. Client Scheduling . . . . . . . . . . . . . . . . . . . . . . 15 9. Client Scheduling . . . . . . . . . . . . . . . . . . . . . . 15
10. Server Scheduling . . . . . . . . . . . . . . . . . . . . . . 15 10. Server Scheduling . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Intermediaries with Multiple Backend Connections . . . . 17 10.1. Intermediaries with Multiple Backend Connections . . . . 17
11. Scheduling and the CONNECT Method . . . . . . . . . . . . . . 17 11. Scheduling and the CONNECT Method . . . . . . . . . . . . . . 17
12. Retransmission Scheduling . . . . . . . . . . . . . . . . . . 18 12. Retransmission Scheduling . . . . . . . . . . . . . . . . . . 18
13. Fairness . . . . . . . . . . . . . . . . . . . . . . . . . . 18 13. Fairness . . . . . . . . . . . . . . . . . . . . . . . . . . 18
13.1. Coalescing Intermediaries . . . . . . . . . . . . . . . 18 13.1. Coalescing Intermediaries . . . . . . . . . . . . . . . 18
13.2. HTTP/1.x Back Ends . . . . . . . . . . . . . . . . . . . 19 13.2. HTTP/1.x Back Ends . . . . . . . . . . . . . . . . . . . 19
13.3. Intentional Introduction of Unfairness . . . . . . . . . 19 13.3. Intentional Introduction of Unfairness . . . . . . . . . 19
14. Why use an End-to-End Header Field? . . . . . . . . . . . . . 20 14. Why use an End-to-End Header Field? . . . . . . . . . . . . . 20
15. Security Considerations . . . . . . . . . . . . . . . . . . . 20 15. Security Considerations . . . . . . . . . . . . . . . . . . . 20
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
17.1. Normative References . . . . . . . . . . . . . . . . . . 22 17.1. Normative References . . . . . . . . . . . . . . . . . . 22
17.2. Informative References . . . . . . . . . . . . . . . . . 23 17.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 24 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 24
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 24 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 24
B.1. Since draft-ietf-httpbis-priority-03 . . . . . . . . . . 24 B.1. Since draft-ietf-httpbis-priority-05 . . . . . . . . . . 24
B.2. Since draft-ietf-httpbis-priority-02 . . . . . . . . . . 25 B.2. Since draft-ietf-httpbis-priority-04 . . . . . . . . . . 25
B.3. Since draft-ietf-httpbis-priority-01 . . . . . . . . . . 25 B.3. Since draft-ietf-httpbis-priority-03 . . . . . . . . . . 25
B.4. Since draft-ietf-httpbis-priority-00 . . . . . . . . . . 25 B.4. Since draft-ietf-httpbis-priority-02 . . . . . . . . . . 25
B.5. Since draft-kazuho-httpbis-priority-04 . . . . . . . . . 25 B.5. Since draft-ietf-httpbis-priority-01 . . . . . . . . . . 25
B.6. Since draft-kazuho-httpbis-priority-03 . . . . . . . . . 26 B.6. Since draft-ietf-httpbis-priority-00 . . . . . . . . . . 25
B.7. Since draft-kazuho-httpbis-priority-02 . . . . . . . . . 26 B.7. Since draft-kazuho-httpbis-priority-04 . . . . . . . . . 26
B.8. Since draft-kazuho-httpbis-priority-01 . . . . . . . . . 26 B.8. Since draft-kazuho-httpbis-priority-03 . . . . . . . . . 26
B.9. Since draft-kazuho-httpbis-priority-00 . . . . . . . . . 26 B.9. Since draft-kazuho-httpbis-priority-02 . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 B.10. Since draft-kazuho-httpbis-priority-01 . . . . . . . . . 26
B.11. Since draft-kazuho-httpbis-priority-00 . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
It is common for an HTTP [HTTP] resource representation to have It is common for an HTTP [HTTP] resource representation to have
relationships to one or more other resources. Clients will often relationships to one or more other resources. Clients will often
discover these relationships while processing a retrieved discover these relationships while processing a retrieved
representation, leading to further retrieval requests. Meanwhile, representation, leading to further retrieval requests. Meanwhile,
the nature of the relationship determines whether the client is the nature of the relationship determines whether the client is
blocked from continuing to process locally available resources. For blocked from continuing to process locally available resources. For
example, visual rendering of an HTML document could be blocked by the example, visual rendering of an HTML document could be blocked by the
skipping to change at page 4, line 45 skipping to change at page 4, line 50
information sent from clients to servers in HTTP/2 frames; see information sent from clients to servers in HTTP/2 frames; see
Section 5.3.2 of [HTTP2]. Section 5.3.2 of [HTTP2].
2. Motivation for Replacing RFC 7540 Priorities 2. Motivation for Replacing RFC 7540 Priorities
An important feature of any implementation of a protocol that An important feature of any implementation of a protocol that
provides multiplexing is the ability to prioritize the sending of provides multiplexing is the ability to prioritize the sending of
information. Prioritization is a difficult problem, so it will information. Prioritization is a difficult problem, so it will
always be suboptimal, particularly if one endpoint operates in always be suboptimal, particularly if one endpoint operates in
ignorance of the needs of its peer. Priority signalling allows ignorance of the needs of its peer. Priority signalling allows
endpoints to communicate their own view of priority needs, which can endpoints to communicate their own view of priority, which can be
be combined with other factors that are considered during the peer's combined with information the peer has to inform scheduling.
prioritization decision making.
RFC 7540 stream priority (see Section 5.3 of [RFC7540]) is a complex RFC 7540 stream priority (see Section 5.3 of [RFC7540]) is a complex
system where clients signal stream dependencies and weights to system where clients signal stream dependencies and weights to
describe an unbalanced tree. It suffered from poor deployment and describe an unbalanced tree. It suffered from limited deployment and
interoperability and was deprecated in a revision of HTTP/2 [HTTP2]. interoperability and was deprecated in a revision of HTTP/2 [HTTP2].
However, in order to maintain wire compatibility, HTTP/2 priority However, in order to maintain wire compatibility, HTTP/2 priority
signals are still mandatory to handle (see Section 5.3.2 of [HTTP2]). signals are still mandatory to handle (see Section 5.3.2 of [HTTP2]).
Clients can build RFC 7540 trees with rich flexibility but experience Clients can build RFC 7540 trees with rich flexibility but experience
has shown this is rarely exercised. Instead they tend to choose a has shown this is rarely exercised. Instead they tend to choose a
single model optimized for a single use case and experiment within single model optimized for a single use case and experiment within
the model constraints, or do nothing at all. Furthermore, many the model constraints, or do nothing at all. Furthermore, many
clients build their prioritization tree in a unique way, which makes clients build their prioritization tree in a unique way, which makes
it difficult for servers to understand their intent and act or it difficult for servers to understand their intent and act or
skipping to change at page 6, line 5 skipping to change at page 5, line 44
the priority of a response. Without such a method, intermediaries the priority of a response. Without such a method, intermediaries
cannot coordinate client-driven and server-driven priorities. cannot coordinate client-driven and server-driven priorities.
RFC 7540 describes denial-of-service considerations for RFC 7540 describes denial-of-service considerations for
implementations. On 2019-08-13 Netflix issued an advisory notice implementations. On 2019-08-13 Netflix issued an advisory notice
about the discovery of several resource exhaustion vectors affecting about the discovery of several resource exhaustion vectors affecting
multiple RFC 7540 implementations. One attack, [CVE-2019-9513] aka multiple RFC 7540 implementations. One attack, [CVE-2019-9513] aka
"Resource Loop", is based on using priority signals to manipulate the "Resource Loop", is based on using priority signals to manipulate the
server's stored prioritization state. server's stored prioritization state.
HTTP/2 priority associated with an HTTP request is signalled as a
value relative to those of other requests sharing the same HTTP/2
connection. Therefore, in order to prioritize requests, endpoints
are compelled to have the knowledge of the underlying HTTP version
and how the requests are coalesced. This has been a burden to HTTP
endpoints that generate or forward requests in a version-agnostic
manner.
HTTP/2 priority signals are required to be delivered and processed in HTTP/2 priority signals are required to be delivered and processed in
the order they are sent so that the receiver handling is the order they are sent so that the receiver handling is
deterministic. Porting HTTP/2 priority signals to protocols that do deterministic. Porting HTTP/2 priority signals to protocols that do
not provide ordering guarantees presents challenges. For example, not provide ordering guarantees presents challenges. For example,
HTTP/3 [HTTP3] lacks global ordering across streams that would carry HTTP/3 [HTTP3] lacks global ordering across streams that would carry
priority signals. Early attempts to port HTTP/2 priority signals to priority signals. Early attempts to port HTTP/2 priority signals to
HTTP/3 required adding additional information to the signals, leading HTTP/3 required adding additional information to the signals, leading
to more complicated processing. Problems found with this approach to more complicated processing. Problems found with this approach
could not be resolved and definition of a HTTP/3 priority signalling could not be resolved and definition of a HTTP/3 priority signalling
feature was removed before publication. feature was removed before publication.
Considering the problems with the deployment of RFC 7540 stream Considering the deployment problems and the design restrictions of
priority, and the difficulties in adapting it to HTTP/3, continuing RFC 7540 stream priority, as well as the difficulties in adapting it
to base prioritization on this mechanism risks increasing the to HTTP/3, continuing to base prioritization on this mechanism risks
complexity of systems. Multiple experiments from independent increasing the complexity of systems. Multiple experiments from
research have shown that simpler schemes can reach at least independent research have shown that simpler schemes can reach at
equivalent performance characteristics compared to the more complex least equivalent performance characteristics compared to the more
RFC 7540 setups seen in practice, at least for the web use case. complex RFC 7540 setups seen in practice, at least for the web use
case.
2.1. Disabling RFC 7540 Priorities 2.1. Disabling RFC 7540 Priorities
The problems and insights set out above provided the motivation for The problems and insights set out above provided the motivation for
deprecating RFC 7540 stream priority (see Section 5.3 of [RFC7540]). deprecating RFC 7540 stream priority (see Section 5.3 of [RFC7540]).
The SETTINGS_DEPRECATE_RFC7540_PRIORITIES setting is defined by this The SETTINGS_NO_RFC7540_PRIORITIES setting is defined by this
document in order to allow endpoints to explicitly opt out of using document in order to allow endpoints to explicitly opt out of using
HTTP/2 priority signals (see Section 5.3.2 of [HTTP2]). Endpoints HTTP/2 priority signals (see Section 5.3.2 of [HTTP2]). Endpoints
are expected to use an alternative, such as the scheme defined in are encouraged to use alternative priority signals (for example,
this specification. Section 5 or Section 7.1) but there is no requirement to use a
specific signal type.
The value of SETTINGS_DEPRECATE_RFC7540_PRIORITIES MUST be 0 or 1. The value of SETTINGS_NO_RFC7540_PRIORITIES MUST be 0 or 1. Any
Any value other than 0 or 1 MUST be treated as a connection error value other than 0 or 1 MUST be treated as a connection error (see
(see Section 5.4.1 of [HTTP2]) of type PROTOCOL_ERROR. Section 5.4.1 of [HTTP2]) of type PROTOCOL_ERROR.
Endpoints MUST send this SETTINGS parameter as part of the first Endpoints MUST send this SETTINGS parameter as part of the first
SETTINGS frame. A sender MUST NOT change the SETTINGS frame. A sender MUST NOT change the
SETTINGS_DEPRECATE_RFC7540_PRIORITIES parameter value after the first SETTINGS_NO_RFC7540_PRIORITIES parameter value after the first
SETTINGS frame. Detection of a change by a receiver MUST be treated SETTINGS frame. Detection of a change by a receiver MUST be treated
as a connection error of type PROTOCOL_ERROR. as a connection error of type PROTOCOL_ERROR.
The SETTINGS frame precedes any HTTP/2 priority signal sent from a
client, so a server can determine if it needs to allocate any
resource to signal handling before they arrive. A server that
receives SETTINGS_NO_RFC7540_PRIORITIES with value of 1 MUST ignore
HTTP/2 priority signals.
2.1.1. Advice when Using Extensible Priorities as the Alternative
Until the client receives the SETTINGS frame from the server, the Until the client receives the SETTINGS frame from the server, the
client SHOULD send both the HTTP/2 priority signals and the signals client SHOULD send both the HTTP/2 priority signals and the signals
of this prioritization scheme (see Section 5 and Section 7.1). When of this prioritization scheme (see Section 5 and Section 7.1). When
the client receives the first SETTINGS frame that contains the the client receives the first SETTINGS frame that contains the
SETTINGS_DEPRECATE_RFC7540_PRIORITIES parameter with value of 1, it SETTINGS_NO_RFC7540_PRIORITIES parameter with value of 1, it SHOULD
SHOULD stop sending the HTTP/2 priority signals. If the value was 0 stop sending the HTTP/2 priority signals. If the value was 0 or if
or if the settings parameter was absent, it SHOULD stop sending the settings parameter was absent, it SHOULD stop sending
PRIORITY_UPDATE frames (Section 7.1), but MAY continue sending the PRIORITY_UPDATE frames (Section 7.1), but MAY continue sending the
Priority header field (Section 5), as it is an end-to-end signal that Priority header field (Section 5), as it is an end-to-end signal that
might be useful to nodes behind the server that the client is might be useful to nodes behind the server that the client is
directly connected to. directly connected to.
The SETTINGS frame precedes any HTTP/2 priority signal sent from a
client, so a server can determine if it needs to allocate any
resource to signal handling before they arrive. A server that
receives SETTINGS_DEPRECATE_RFC7540_PRIORITIES with value of 1 MUST
ignore HTTP/2 priority signals.
Where both endpoints disable RFC 7540 stream priority, the client is
expected to send this scheme's priority signal. Handling of omitted
signals is described in Section 4.
3. Applicability of the Extensible Priority Scheme 3. Applicability of the Extensible Priority Scheme
The priority scheme defined by this document considers only the The priority scheme defined by this document considers only the
prioritization of HTTP messages and tunnels, see Section 9, prioritization of HTTP messages and tunnels, see Section 9,
Section 10, and Section 11. Section 10, and Section 11.
Where HTTP extensions change stream behavior or define new data Where HTTP extensions change stream behavior or define new data
carriage mechanisms, they can also define how this priority scheme carriage mechanisms, they can also define how this priority scheme
can be applied. can be applied.
skipping to change at page 21, line 40 skipping to change at page 21, line 40
Author/change controller: IETF Author/change controller: IETF
Specification document(s): This document Specification document(s): This document
Related information: n/a Related information: n/a
This specification registers the following entry in the HTTP/2 This specification registers the following entry in the HTTP/2
Settings registry established by [HTTP2]: Settings registry established by [HTTP2]:
Name: SETTINGS_DEPRECATE_RFC7540_PRIORITIES Name: SETTINGS_NO_RFC7540_PRIORITIES
Code: 0x9 Code: 0x9
Initial value: 0 Initial value: 0
Specification: This document Specification: This document
This specification registers the following entry in the HTTP/2 Frame This specification registers the following entry in the HTTP/2 Frame
Type registry established by [HTTP2]: Type registry established by [HTTP2]:
skipping to change at page 22, line 35 skipping to change at page 22, line 35
17.1. Normative References 17.1. Normative References
[HTTP] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP [HTTP] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP
Semantics", Work in Progress, Internet-Draft, draft-ietf- Semantics", Work in Progress, Internet-Draft, draft-ietf-
httpbis-semantics-19, 12 September 2021, httpbis-semantics-19, 12 September 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis- <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
semantics-19>. semantics-19>.
[HTTP2] Thomson, M. and C. Benfield, "Hypertext Transfer Protocol [HTTP2] Thomson, M. and C. Benfield, "Hypertext Transfer Protocol
Version 2 (HTTP/2)", Work in Progress, Internet-Draft, Version 2 (HTTP/2)", Work in Progress, Internet-Draft,
draft-ietf-httpbis-http2bis-04, 23 September 2021, draft-ietf-httpbis-http2bis-05, 26 September 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis- <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
http2bis-04>. http2bis-05>.
[HTTP3] Bishop, M., "Hypertext Transfer Protocol Version 3 [HTTP3] Bishop, M., "Hypertext Transfer Protocol Version 3
(HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf-
quic-http-34, 2 February 2021, quic-http-34, 2 February 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-quic- <https://datatracker.ietf.org/doc/html/draft-ietf-quic-
http-34>. http-34>.
[QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based [QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000, Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021, DOI 10.17487/RFC9000, May 2021,
skipping to change at page 24, line 28 skipping to change at page 24, line 28
Appendix A. Acknowledgements Appendix A. Acknowledgements
Roy Fielding presented the idea of using a header field for Roy Fielding presented the idea of using a header field for
representing priorities in http://tools.ietf.org/agenda/83/slides/ representing priorities in http://tools.ietf.org/agenda/83/slides/
slides-83-httpbis-5.pdf (http://tools.ietf.org/agenda/83/slides/ slides-83-httpbis-5.pdf (http://tools.ietf.org/agenda/83/slides/
slides-83-httpbis-5.pdf). In https://github.com/pmeenan/http3- slides-83-httpbis-5.pdf). In https://github.com/pmeenan/http3-
prioritization-proposal (https://github.com/pmeenan/http3- prioritization-proposal (https://github.com/pmeenan/http3-
prioritization-proposal), Patrick Meenan advocates for representing prioritization-proposal), Patrick Meenan advocates for representing
the priorities using a tuple of urgency and concurrency. The ability the priorities using a tuple of urgency and concurrency. The ability
to deprecate HTTP/2 prioritization is based on to disable HTTP/2 prioritization is inspired by
[I-D.lassey-priority-setting], authored by Brad Lassey and Lucas [I-D.lassey-priority-setting], authored by Brad Lassey and Lucas
Pardue, with modifications based on feedback that was not Pardue, with modifications based on feedback that was not
incorporated into an update to that document. incorporated into an update to that document.
The motivation for defining an alternative to HTTP/2 priorities is The motivation for defining an alternative to HTTP/2 priorities is
drawn from discussion within the broad HTTP community. Special drawn from discussion within the broad HTTP community. Special
thanks to Roberto Peon, Martin Thomson and Netflix for text that was thanks to Roberto Peon, Martin Thomson and Netflix for text that was
incorporated explicitly in this document. incorporated explicitly in this document.
In addition to the people above, this document owes a lot to the In addition to the people above, this document owes a lot to the
extensive discussion in the HTTP priority design team, consisting of extensive discussion in the HTTP priority design team, consisting of
Alan Frindell, Andrew Galloni, Craig Taylor, Ian Swett, Kazuho Oku, Alan Frindell, Andrew Galloni, Craig Taylor, Ian Swett, Kazuho Oku,
Lucas Pardue, Matthew Cox, Mike Bishop, Roberto Peon, Robin Marx, Roy Lucas Pardue, Matthew Cox, Mike Bishop, Roberto Peon, Robin Marx, Roy
Fielding. Fielding.
Appendix B. Change Log Appendix B. Change Log
B.1. Since draft-ietf-httpbis-priority-03 B.1. Since draft-ietf-httpbis-priority-05
* Renamed SETTINGS_DEPRECATE_RFC7540_PRIORITIES to
SETTINGS_NO_RFC7540_PRIORITIES
* Clarify that senders of the HTTP/2 setting can use any alternative
(#1679, #1705)
B.2. Since draft-ietf-httpbis-priority-04
* Renamed SETTINGS_DEPRECATE_HTTP2_PRIORITIES to
SETTINGS_DEPRECATE_RFC7540_PRIORITIES (#1601)
* Reoriented text towards RFC7540bis (#1561, #1601)
* Clarify intermediary behavior (#1562)
B.3. Since draft-ietf-httpbis-priority-03
* Add statement about what this scheme applies to. Clarify * Add statement about what this scheme applies to. Clarify
extensions can use it but must define how themselves (#1550, extensions can use it but must define how themselves (#1550,
#1559) #1559)
* Describe scheduling considerations for the CONNECT method (#1495, * Describe scheduling considerations for the CONNECT method (#1495,
#1544) #1544)
* Describe scheduling considerations for retransmitted data (#1429, * Describe scheduling considerations for retransmitted data (#1429,
#1504) #1504)
* Suggest intermediaries might avoid strict prioritization (#1562) * Suggest intermediaries might avoid strict prioritization (#1562)
B.2. Since draft-ietf-httpbis-priority-02 B.4. Since draft-ietf-httpbis-priority-02
* Describe considerations for server push prioritization (#1056, * Describe considerations for server push prioritization (#1056,
#1345) #1345)
* Define HTTP/2 PRIORITY_UPDATE ID limits in HTTP/2 terms (#1261, * Define HTTP/2 PRIORITY_UPDATE ID limits in HTTP/2 terms (#1261,
#1344) #1344)
* Add a Parameters registry (#1371) * Add a Parameters registry (#1371)
B.3. Since draft-ietf-httpbis-priority-01 B.5. Since draft-ietf-httpbis-priority-01
* PRIORITY_UPDATE frame changes (#1096, #1079, #1167, #1262, #1267, * PRIORITY_UPDATE frame changes (#1096, #1079, #1167, #1262, #1267,
#1271) #1271)
* Add section to describe server scheduling considerations (#1215, * Add section to describe server scheduling considerations (#1215,
#1232, #1266) #1232, #1266)
* Remove specific instructions related to intermediary fairness * Remove specific instructions related to intermediary fairness
(#1022, #1264) (#1022, #1264)
B.4. Since draft-ietf-httpbis-priority-00 B.6. Since draft-ietf-httpbis-priority-00
* Move text around (#1217, #1218) * Move text around (#1217, #1218)
* Editorial change to the default urgency. The value is 3, which * Editorial change to the default urgency. The value is 3, which
was always the intent of previous changes. was always the intent of previous changes.
B.5. Since draft-kazuho-httpbis-priority-04 B.7. Since draft-kazuho-httpbis-priority-04
* Minimize semantics of Urgency levels (#1023, #1026) * Minimize semantics of Urgency levels (#1023, #1026)
* Reduce guidance about how intermediary implements merging priority * Reduce guidance about how intermediary implements merging priority
signals (#1026) signals (#1026)
* Remove mention of CDN-Loop (#1062) * Remove mention of CDN-Loop (#1062)
* Editorial changes * Editorial changes
skipping to change at page 26, line 4 skipping to change at page 26, line 19
* Minimize semantics of Urgency levels (#1023, #1026) * Minimize semantics of Urgency levels (#1023, #1026)
* Reduce guidance about how intermediary implements merging priority * Reduce guidance about how intermediary implements merging priority
signals (#1026) signals (#1026)
* Remove mention of CDN-Loop (#1062) * Remove mention of CDN-Loop (#1062)
* Editorial changes * Editorial changes
* Make changes due to WG adoption * Make changes due to WG adoption
* Removed outdated Consideration (#118) * Removed outdated Consideration (#118)
B.6. Since draft-kazuho-httpbis-priority-03 B.8. Since draft-kazuho-httpbis-priority-03
* Changed numbering from [-1,6] to [0,7] (#78) * Changed numbering from [-1,6] to [0,7] (#78)
* Replaced priority scheme negotiation with HTTP/2 priority * Replaced priority scheme negotiation with HTTP/2 priority
deprecation (#100) deprecation (#100)
* Shorten parameter names (#108) * Shorten parameter names (#108)
* Expand on considerations (#105, #107, #109, #110, #111, #113) * Expand on considerations (#105, #107, #109, #110, #111, #113)
B.7. Since draft-kazuho-httpbis-priority-02 B.9. Since draft-kazuho-httpbis-priority-02
* Consolidation of the problem statement (#61, #73) * Consolidation of the problem statement (#61, #73)
* Define SETTINGS_PRIORITIES for negotiation (#58, #69) * Define SETTINGS_PRIORITIES for negotiation (#58, #69)
* Define PRIORITY_UPDATE frame for HTTP/2 and HTTP/3 (#51) * Define PRIORITY_UPDATE frame for HTTP/2 and HTTP/3 (#51)
* Explain fairness issue and mitigations (#56) * Explain fairness issue and mitigations (#56)
B.8. Since draft-kazuho-httpbis-priority-01 B.10. Since draft-kazuho-httpbis-priority-01
* Explain how reprioritization might be supported. * Explain how reprioritization might be supported.
B.9. Since draft-kazuho-httpbis-priority-00 B.11. Since draft-kazuho-httpbis-priority-00
* Expand urgency levels from 3 to 8. * Expand urgency levels from 3 to 8.
Authors' Addresses Authors' Addresses
Kazuho Oku Kazuho Oku
Fastly Fastly
Email: kazuhooku@gmail.com Email: kazuhooku@gmail.com
 End of changes. 32 change blocks. 
60 lines changed or deleted 87 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/