idnits 2.17.1 draft-ietf-httpbis-priority-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([2], [3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 01, 2020) is 1303 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 900 -- Looks like a reference, but probably isn't: '2' on line 902 -- Looks like a reference, but probably isn't: '3' on line 904 -- Looks like a reference, but probably isn't: '4' on line 914 -- Looks like a reference, but probably isn't: '5' on line 915 == Outdated reference: A later version (-34) exists of draft-ietf-quic-http-31 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-31 ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) -- Obsolete informational reference (is this intentional?): RFC 7234 (Obsoleted by RFC 9111) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTP K. Oku 3 Internet-Draft Fastly 4 Intended status: Standards Track L. Pardue 5 Expires: April 4, 2021 Cloudflare 6 October 01, 2020 8 Extensible Prioritization Scheme for HTTP 9 draft-ietf-httpbis-priority-02 11 Abstract 13 This document describes a scheme for prioritizing HTTP responses. 14 This scheme expresses the priority of each HTTP response using 15 absolute values, rather than as a relative relationship between a 16 group of HTTP responses. 18 This document defines the Priority header field for communicating the 19 initial priority in an HTTP version-independent manner, as well as 20 HTTP/2 and HTTP/3 frames for reprioritizing the responses. These 21 share a common format structure that is designed to provide future 22 extensibility. 24 Note to Readers 26 _RFC EDITOR: please remove this section before publication_ 28 Discussion of this draft takes place on the HTTP working group 29 mailing list (ietf-http-wg@w3.org), which is archived at 30 https://lists.w3.org/Archives/Public/ietf-http-wg/ [1]. 32 Working Group information can be found at https://httpwg.org/ [2]; 33 source code and issues list for this draft can be found at 34 https://github.com/httpwg/http-extensions/labels/priorities [3]. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on April 4, 2021. 53 Copyright Notice 55 Copyright (c) 2020 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (https://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 72 2. Motivation for Replacing HTTP/2 Priorities . . . . . . . . . 4 73 2.1. Disabling HTTP/2 Priorities . . . . . . . . . . . . . . . 5 74 3. Priority Parameters . . . . . . . . . . . . . . . . . . . . . 6 75 3.1. Urgency . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 3.2. Incremental . . . . . . . . . . . . . . . . . . . . . . . 7 77 3.3. Defining New Parameters . . . . . . . . . . . . . . . . . 8 78 4. The Priority HTTP Header Field . . . . . . . . . . . . . . . 8 79 5. Reprioritization . . . . . . . . . . . . . . . . . . . . . . 9 80 6. The PRIORITY_UPDATE Frame . . . . . . . . . . . . . . . . . . 9 81 6.1. HTTP/2 PRIORITY_UPDATE Frame . . . . . . . . . . . . . . 10 82 6.2. HTTP/3 PRIORITY_UPDATE Frame . . . . . . . . . . . . . . 11 83 7. Merging Client- and Server-Driven Parameters . . . . . . . . 12 84 8. Client Scheduling . . . . . . . . . . . . . . . . . . . . . . 13 85 9. Server Scheduling . . . . . . . . . . . . . . . . . . . . . . 13 86 10. Fairness . . . . . . . . . . . . . . . . . . . . . . . . . . 14 87 10.1. Coalescing Intermediaries . . . . . . . . . . . . . . . 15 88 10.2. HTTP/1.x Back Ends . . . . . . . . . . . . . . . . . . . 15 89 10.3. Intentional Introduction of Unfairness . . . . . . . . . 16 90 11. Why use an End-to-End Header Field? . . . . . . . . . . . . . 16 91 12. Security Considerations . . . . . . . . . . . . . . . . . . . 16 92 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 93 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 94 14.1. Normative References . . . . . . . . . . . . . . . . . . 18 95 14.2. Informative References . . . . . . . . . . . . . . . . . 19 96 14.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 19 97 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 20 98 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 20 99 B.1. Since draft-ietf-httpbis-priority-01 . . . . . . . . . . 20 100 B.2. Since draft-ietf-httpbis-priority-00 . . . . . . . . . . 20 101 B.3. Since draft-kazuho-httpbis-priority-04 . . . . . . . . . 21 102 B.4. Since draft-kazuho-httpbis-priority-03 . . . . . . . . . 21 103 B.5. Since draft-kazuho-httpbis-priority-02 . . . . . . . . . 21 104 B.6. Since draft-kazuho-httpbis-priority-01 . . . . . . . . . 21 105 B.7. Since draft-kazuho-httpbis-priority-00 . . . . . . . . . 21 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 108 1. Introduction 110 It is common for an HTTP ([RFC7230]) resource representation to have 111 relationships to one or more other resources. Clients will often 112 discover these relationships while processing a retrieved 113 representation, leading to further retrieval requests. Meanwhile, 114 the nature of the relationship determines whether the client is 115 blocked from continuing to process locally available resources. For 116 example, visual rendering of an HTML document could be blocked by the 117 retrieval of a CSS file that the document refers to. In contrast, 118 inline images do not block rendering and get drawn incrementally as 119 the chunks of the images arrive. 121 To provide meaningful presentation of a document at the earliest 122 moment, it is important for an HTTP server to prioritize the HTTP 123 responses, or the chunks of those HTTP responses, that it sends. 125 HTTP/2 ([RFC7540]) provides such a prioritization scheme. A client 126 sends a series of PRIORITY frames to communicate to the server a 127 "priority tree"; this represents the client's preferred ordering and 128 weighted distribution of the bandwidth among the HTTP responses. 129 However, the design and implementation of this scheme has been 130 observed to have shortcomings, explained in Section 2. 132 This document defines the Priority HTTP header field that can be used 133 by both client and server to specify the precedence of HTTP responses 134 in a standardized, extensible, protocol-version-independent, end-to- 135 end format. Along with the protocol-version-specific frame for 136 reprioritization, this prioritization scheme acts as a substitute for 137 the original prioritization scheme of HTTP/2. 139 1.1. Notational Conventions 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in [RFC2119]. 145 The terms sf-token and sf-boolean are imported from 146 [STRUCTURED-FIELDS]. 148 Example HTTP requests and responses use the HTTP/2-style formatting 149 from [RFC7540]. 151 This document uses the variable-length integer encoding from 152 [I-D.ietf-quic-transport]. 154 The term control stream is used to describe the HTTP/2 stream with 155 identifier 0x0, and HTTP/3 control stream; see [I-D.ietf-quic-http], 156 Section 6.2.1. 158 2. Motivation for Replacing HTTP/2 Priorities 160 An important feature of any implementation of a protocol that 161 provides multiplexing is the ability to prioritize the sending of 162 information. This was an important realization in the design of 163 HTTP/2. Prioritization is a difficult problem, so it will always be 164 suboptimal, particularly if one endpoint operates in ignorance of the 165 needs of its peer. 167 HTTP/2 introduced a complex prioritization signaling scheme that used 168 a combination of dependencies and weights, formed into an unbalanced 169 tree. This scheme has suffered from poor deployment and 170 interoperability. 172 The rich flexibility of client-driven HTTP/2 prioritization tree 173 building is rarely exercised. Experience has shown that clients tend 174 to choose a single model optimized for a web use case and experiment 175 within the model constraints, or do nothing at all. Furthermore, 176 many clients build their prioritization tree in a unique way, which 177 makes it difficult for servers to understand their intent and act or 178 intervene accordingly. 180 Many HTTP/2 server implementations do not include support for the 181 priority scheme. Some instead favor custom server-driven schemes 182 based on heuristics or other hints, such as resource content type or 183 request generation order. For example, a server, with knowledge of 184 the document structure, might want to prioritize the delivery of 185 images that are critical to user experience above other images, but 186 below the CSS files. Since client trees vary, it is impossible for 187 the server to determine how such images should be prioritized against 188 other responses. 190 The HTTP/2 scheme allows intermediaries to coalesce multiple client 191 trees into a single tree that is used for a single upstream HTTP/2 192 connection. However, most intermediaries do not support this. The 193 scheme does not define a method that can be used by a server to 194 express the priority of a response. Without such a method, 195 intermediaries cannot coordinate client-driven and server-driven 196 priorities. 198 HTTP/2 describes denial-of-service considerations for 199 implementations. On 2019-08-13 Netflix issued an advisory notice 200 about the discovery of several resource exhaustion vectors affecting 201 multiple HTTP/2 implementations. One attack, [CVE-2019-9513] aka 202 "Resource Loop", is based on manipulation of the priority tree. 204 The HTTP/2 scheme depends on in-order delivery of signals, leading to 205 challenges in porting the scheme to protocols that do not provide 206 global ordering. For example, the scheme cannot be used in HTTP/3 207 [I-D.ietf-quic-http] without changing the signal and its processing. 209 Considering the problems with deployment and adaptability to HTTP/3, 210 retaining the HTTP/2 priority scheme increases the complexity of the 211 entire system without any evidence that the value it provides offsets 212 that complexity. In fact, multiple experiments from independent 213 research have shown that simpler schemes can reach at least 214 equivalent performance characteristics compared to the more complex 215 HTTP/2 setups seen in practice, at least for the web use case. 217 2.1. Disabling HTTP/2 Priorities 219 The problems and insights set out above are motivation for allowing 220 endpoints to opt out of using the HTTP/2 priority scheme, in favor of 221 using an alternative such as the scheme defined in this 222 specification. The SETTINGS_DEPRECATE_HTTP2_PRIORITIES setting 223 described below enables endpoints to understand their peer's 224 intention. The value of the parameter MUST be 0 or 1. Any value 225 other than 0 or 1 MUST be treated as a connection error (see 226 [RFC7540], Section 5.4.1) of type PROTOCOL_ERROR. 228 Endpoints MUST send this SETTINGS parameter as part of the first 229 SETTINGS frame. When the peer receives the first SETTINGS frame, it 230 learns the sender has deprecated the HTTP/2 priority scheme if it 231 receives the SETTINGS_DEPRECATE_HTTP2_PRIORITIES parameter with the 232 value of 1. 234 A sender MUST NOT change the SETTINGS_DEPRECATE_HTTP2_PRIORITIES 235 parameter value after the first SETTINGS frame. Detection of a 236 change by a receiver MUST be treated as a connection error of type 237 PROTOCOL_ERROR. 239 Until the client receives the SETTINGS frame from the server, the 240 client SHOULD send both the priority signal defined in the HTTP/2 241 priority scheme and also that of this prioritization scheme. Once 242 the client learns that the HTTP/2 priority scheme is deprecated, it 243 SHOULD stop sending the HTTP/2 priority signals. If the client 244 learns that the HTTP/2 priority scheme is not deprecated, it SHOULD 245 stop sending PRIORITY_UPDATE frames (Section 6.1), but MAY continue 246 sending the Priority header field (Section 4), as it is an end-to-end 247 signal that might be useful to nodes behind the server that the 248 client is directly connected to. 250 The SETTINGS frame precedes any priority signal sent from a client in 251 HTTP/2, so a server can determine if it should respect the HTTP/2 252 scheme before building state. A server that receives 253 SETTINGS_DEPRECATE_HTTP2_PRIORITIES MUST ignore HTTP/2 priority 254 signals. 256 Where both endpoints disable HTTP/2 priorities, the client is 257 expected to send this scheme's priority signal. Handling of omitted 258 signals is described in Section 3. 260 3. Priority Parameters 262 The priority information is a sequence of key-value pairs, providing 263 room for future extensions. Each key-value pair represents a 264 priority parameter. 266 The Priority HTTP header field (Section 4) is an end-to-end way to 267 transmit this set of parameters when a request or a response is 268 issued. In order to reprioritize a request, HTTP-version-specific 269 frames (Section 6.1 and Section 6.2) are used by clients to transmit 270 the same information on a single hop. If intermediaries want to 271 specify prioritization on a multiplexed HTTP connection, they SHOULD 272 use a PRIORITY_UPDATE frame and SHOULD NOT change the Priority header 273 field. 275 In both cases, the set of priority parameters is encoded as a 276 Structured Fields Dictionary ([STRUCTURED-FIELDS]). 278 This document defines the urgency("u") and incremental("i") 279 parameters. When receiving an HTTP request that does not carry these 280 priority parameters, a server SHOULD act as if their default values 281 were specified. Note that handling of omitted parameters is 282 different when processing an HTTP response; see Section 7. 284 Unknown parameters, parameters with out-of-range values or values of 285 unexpected types MUST be ignored. 287 3.1. Urgency 289 The urgency parameter ("u") takes an integer between 0 and 7, in 290 descending order of priority. This range provides sufficient 291 granularity for prioritizing responses for ordinary web browsing, at 292 minimal complexity. 294 The value is encoded as an sf-integer. The default value is 3. 296 This parameter indicates the sender's recommendation, based on the 297 expectation that the server would transmit HTTP responses in the 298 order of their urgency values if possible. The smaller the value, 299 the higher the precedence. 301 The following example shows a request for a CSS file with the urgency 302 set to "0": 304 :method = GET 305 :scheme = https 306 :authority = example.net 307 :path = /style.css 308 priority = u=0 310 A client that fetches a document that likely consists of multiple 311 HTTP resources (e.g., HTML) SHOULD assign the default urgency level 312 to the main resource. This convention allows servers to refine the 313 urgency using knowledge specific to the web-site (see Section 7). 315 The lowest urgency level (7) is reserved for background tasks such as 316 delivery of software updates. This urgency level SHOULD NOT be used 317 for fetching responses that have impact on user interaction. 319 3.2. Incremental 321 The incremental parameter ("i") takes an sf-boolean as the value that 322 indicates if an HTTP response can be processed incrementally, i.e. 323 provide some meaningful output as chunks of the response arrive. 325 The default value of the incremental parameter is false ("0"). 327 A server might distribute the bandwidth of a connection between 328 incremental responses that share the same urgency, hoping that 329 providing those responses in parallel would be more helpful to the 330 client than delivering the responses one by one. 332 If a client makes concurrent requests with the incremental parameter 333 set to false, there is no benefit serving responses in parallel 334 because the client is not going to process those responses 335 incrementally. Serving non-incremental responses one by one, in the 336 order in which those requests were generated is considered to be the 337 best strategy. 339 The following example shows a request for a JPEG file with the 340 urgency parameter set to "5" and the incremental parameter set to 341 "true". 343 :method = GET 344 :scheme = https 345 :authority = example.net 346 :path = /image.jpg 347 priority = u=5, i 349 3.3. Defining New Parameters 351 When attempting to extend priorities, care must be taken to ensure 352 any use of existing parameters leaves them either unchanged or 353 modified in a way that is backwards compatible for peers that are 354 unaware of the extended meaning. 356 For example, if there is a need to provide more granularity than 357 eight urgency levels, it would be possible to subdivide the range 358 using an additional parameter. Implementations that do not recognize 359 the parameter can safely continue to use the less granular eight 360 levels. 362 Alternatively, the urgency can be augmented. For example, a 363 graphical user agent could send a "visible" parameter to indicate if 364 the resource being requested is within the viewport. 366 4. The Priority HTTP Header Field 368 The Priority HTTP header field can appear in requests and responses. 369 A client uses it to specify the priority of the response. A server 370 uses it to inform the client that the priority was overwritten. An 371 intermediary can use the Priority information from client requests 372 and server responses to correct or amend the precedence to suit it 373 (see Section 7). 375 The Priority header field is an end-to-end signal of the request 376 priority from the client or the response priority from the server. 378 As is the ordinary case for HTTP caching ([RFC7234]), a response with 379 a Priority header field might be cached and re-used for subsequent 380 requests. When an origin server generates the Priority response 381 header field based on properties of an HTTP request it receives, the 382 server is expected to control the cacheability or the applicability 383 of the cached response, by using header fields that control the 384 caching behavior (e.g., Cache-Control, Vary). 386 An endpoint that fails to parse the Priority header field SHOULD use 387 default parameter values. 389 5. Reprioritization 391 After a client sends a request, it may be beneficial to change the 392 priority of the response. As an example, a web browser might issue a 393 prefetch request for a JavaScript file with the urgency parameter of 394 the Priority request header field set to "u=7" (background). Then, 395 when the user navigates to a page which references the new JavaScript 396 file, while the prefetch is in progress, the browser would send a 397 reprioritization signal with the priority field value set to "u=0". 398 The PRIORITY_UPDATE frame (Section 6) can be used for such 399 reprioritization. 401 6. The PRIORITY_UPDATE Frame 403 This document specifies a new PRIORITY_UPDATE frame for HTTP/2 404 ([RFC7540]) and HTTP/3 ([I-D.ietf-quic-http]). It carries priority 405 parameters and references the target of the prioritization based on a 406 version-specific identifier. In HTTP/2, this identifier is the 407 Stream ID; in HTTP/3, the identifier is either the Stream ID or Push 408 ID. Unlike the Priority header field, the PRIORITY_UPDATE frame is a 409 hop-by-hop signal. 411 PRIORITY_UPDATE frames are sent by clients on the control stream, 412 allowing them to be sent independent from the stream that carries the 413 response. This means they can be used to reprioritize a response or 414 a push stream; or signal the initial priority of a response instead 415 of the Priority header field. 417 A PRIORITY_UPDATE frame communicates a complete set of all parameters 418 in the Priority Field Value field. Omitting a parameter is a signal 419 to use the parameter's default value. Failure to parse the Priority 420 Field Value MUST be treated as a connection error. In HTTP/2 the 421 error is of type PROTOCOL_ERROR; in HTTP/3 the error is of type 422 H3_FRAME_ERROR. 424 A client MAY send a PRIORITY_UPDATE frame before the stream that it 425 references is open. Furthermore, HTTP/3 offers no guaranteed 426 ordering across streams, which could cause the frame to be received 427 earlier than intended. Either case leads to a race condition where a 428 server receives a PRIORITY_UPDATE frame that references a request 429 stream that is yet to be opened. To solve this condition, for the 430 purposes of scheduling, the most recently received PRIORITY_UPDATE 431 frame can be considered as the most up-to-date information that 432 overrides any other signal. Servers SHOULD buffer the most recently 433 received PRIORITY_UPDATE frame and apply it once the referenced 434 stream is opened. Holding PRIORITY_UPDATE frames for each stream 435 requires server resources, which can can be bound by local 436 implementation policy. (TODO: consider resolving #1261, and adding 437 more text about bounds). Although there is no limit to the number 438 PRIORITY_UPDATES that can be sent, storing only the most recently 439 received frame limits resource commitment. 441 6.1. HTTP/2 PRIORITY_UPDATE Frame 443 The HTTP/2 PRIORITY_UPDATE frame (type=0x10) is used by clients to 444 signal the initial priority of a response, or to reprioritize a 445 response or push stream. It carries the stream ID of the response 446 and the priority in ASCII text, using the same representation as the 447 Priority header field value. 449 The Stream Identifier field ([RFC7540], Section 4.1) in the 450 PRIORITY_UPDATE frame header MUST be zero (0x0). Receiving a 451 PRIORITY_UPDATE frame with a field of any other value MUST be treated 452 as a connection error of type PROTOCOL_ERROR. 454 0 1 2 3 455 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 456 +---------------------------------------------------------------+ 457 |R| Prioritized Stream ID (31) | 458 +---------------------------------------------------------------+ 459 | Priority Field Value (*) ... 460 +---------------------------------------------------------------+ 462 Figure 1: HTTP/2 PRIORITY_UPDATE Frame Payload 464 The PRIORITY_UPDATE frame payload has the following fields: 466 R: A reserved 1-bit field. The semantics of this bit are undefined, 467 and the bit MUST remain unset (0x0) when sending and MUST be 468 ignored when receiving. 470 Prioritized Stream ID: A 31-bit stream identifier for the stream 471 that is the target of the priority update. 473 Priority Field Value: The priority update value in ASCII text, 474 encoded using Structured Fields. 476 The Prioritized Stream ID MUST be within the stream limit. If a 477 server receives a PRIORITY_UPDATE with a Prioritized Stream ID that 478 is beyond the stream limits, this SHOULD be treated as a connection 479 error of type PROTOCOL_ERROR. 481 If a PRIORITY_UPDATE frame is received with a Prioritized Stream ID 482 of 0x0, the recipient MUST respond with a connection error of type 483 PROTOCOL_ERROR. 485 If a client receives a PRIORITY_UPDATE frame, it MUST respond with a 486 connection error of type PROTOCOL_ERROR. 488 6.2. HTTP/3 PRIORITY_UPDATE Frame 490 The HTTP/3 PRIORITY_UPDATE frame (type=0xF0700 or 0xF0701) is used by 491 clients to signal the initial priority of a response, or to 492 reprioritize a response or push stream. It carries the identifier of 493 the element that is being prioritized, and the updated priority in 494 ASCII text, using the same representation as that of the Priority 495 header field value. PRIORITY_UPDATE with a frame type of 0xF0700 is 496 used for request streams, while PRIORITY_UPDATE with a frame type of 497 0xF0701 is used for push streams. 499 The PRIORITY_UPDATE frame MUST be sent on the client control stream 500 ([I-D.ietf-quic-http], Section 6.2.1). Receiving a PRIORITY_UPDATE 501 frame on a stream other than the client control stream MUST be 502 treated as a connection error of type H3_FRAME_UNEXPECTED. 504 HTTP/3 PRIORITY_UPDATE Frame { 505 Type (i) = 0xF0700..0xF0701, 506 Length (i), 507 Prioritized Element ID (i), 508 Priority Field Value (..), 509 } 511 Figure 2: HTTP/3 PRIORITY_UPDATE Frame 513 The PRIORITY_UPDATE frame payload has the following fields: 515 Prioritized Element ID: The stream ID or push ID that is the target 516 of the priority update. 518 Priority Field Value: The priority update value in ASCII text, 519 encoded using Structured Fields. 521 The request-stream variant of PRIORITY_UPDATE (type=0xF0700) MUST 522 reference a request stream. If a server receives a PRIORITY_UPDATE 523 (type=0xF0700) for a Stream ID that is not a request stream, this 524 MUST be treated as a connection error of type H3_ID_ERROR. The 525 Stream ID MUST be within the client-initiated bidirectional stream 526 limit. If a server receives a PRIORITY_UPDATE (type=0xF0700) with a 527 Stream ID that is beyond the stream limits, this SHOULD be treated as 528 a connection error of type H3_ID_ERROR. 530 The push-stream variant PRIORITY_UPDATE (type=0xF0701) MUST reference 531 a promised push stream. If a server receives a PRIORITY_UPDATE 532 (type=0xF0701) with a Push ID that is greater than the maximum Push 533 ID or which has not yet been promised, this MUST be treated as a 534 connection error of type H3_ID_ERROR. 536 PRIORITY_UPDATE frames of either type are only sent by clients. If a 537 client receives a PRIORITY_UPDATE frame, this MUST be treated as a 538 connection error of type H3_FRAME_UNEXPECTED. 540 7. Merging Client- and Server-Driven Parameters 542 It is not always the case that the client has the best understanding 543 of how the HTTP responses deserve to be prioritized. The server 544 might have additional information that can be combined with the 545 client's indicated priority in order to improve the prioritization of 546 the response. For example, use of an HTML document might depend 547 heavily on one of the inline images; existence of such dependencies 548 is typically best known to the server. Or, a server that receives 549 requests for a font [RFC8081] and images with the same urgency might 550 give higher precedence to the font, so that a visual client can 551 render textual information at an early moment. 553 An origin can use the Priority response header field to indicate its 554 view on how an HTTP response should be prioritized. An intermediary 555 that forwards an HTTP response can use the parameters found in the 556 Priority response header field, in combination with the client 557 Priority request header field, as input to its prioritization 558 process. No guidance is provided for merging priorities, this is 559 left as an implementation decision. 561 Absence of a priority parameter in an HTTP response indicates the 562 server's disinterest in changing the client-provided value. This is 563 different from the logic being defined for the request header field, 564 in which omission of a priority parameter implies the use of their 565 default values (see Section 3). 567 As a non-normative example, when the client sends an HTTP request 568 with the urgency parameter set to "5" and the incremental parameter 569 set to "true" 570 :method = GET 571 :scheme = https 572 :authority = example.net 573 :path = /menu.png 574 priority = u=5, i 576 and the origin responds with 578 :status = 200 579 content-type = image/png 580 priority = u=1 582 the intermediary might alter its understanding of the urgency from 583 "5" to "1", because it prefers the server-provided value over the 584 client's. The incremental value continues to be "true", the value 585 specified by the client, as the server did not specify the 586 incremental("i") parameter. 588 8. Client Scheduling 590 A client MAY use priority values to make local processing or 591 scheduling choices about the requests it initiates. 593 9. Server Scheduling 595 Priority signals are input to a prioritization process. They do not 596 guarantee any particular processing or transmission order for one 597 response relative to any other response. An endpoint cannot force a 598 peer to process concurrent request in a particular order using 599 priority. Expressing priority is therefore only a suggestion. 601 A server can use priority signals along with other inputs to make 602 scheduling decisions. No guidance is provided about how this can or 603 should be done. Factors such as implementation choices or deployment 604 environment also play a role. Any given connection is likely to have 605 many dynamic permutations. For these reasons, there is no unilateral 606 perfect scheduler and this document only provides some basic 607 recommendations for implementations. 609 Clients cannot depend on particular treatment based on priority 610 signals. Servers can use other information to prioritize responses. 612 It is RECOMMENDED that, when possible, servers respect the urgency 613 parameter (Section 3.1), sending higher urgency responses before 614 lower urgency responses. 616 It is RECOMMENDED that, when possible, servers respect the 617 incremental parameter (Section 3.2). Non-incremental responses of 618 the same urgency SHOULD be served one-by-one based on the Stream ID, 619 which corresponds to the order in which clients make requests. Doing 620 so ensures that clients can use request ordering to influence 621 response order. Incremental responses of the same urgency SHOULD be 622 served in round-robin manner. 624 The incremental parameter indicates how a client processes response 625 bytes as they arrive. Non-incremental resources are only used when 626 all of the response payload has been received. Incremental resources 627 are used as parts, or chunks, of the response payload are received. 628 Therefore, the timing of response data reception at the client, such 629 as the time to early bytes or the time to receive the entire payload, 630 plays an important role in perceived performance. Timings depend on 631 resource size but this scheme provides no explicit guidance about how 632 a server should use size as an input to prioritization. Instead, the 633 following examples demonstrate how a server that strictly abides the 634 scheduling guidance based on urgency and request generation order 635 could find that early requests prevent serving of later requests. 637 1. At the same urgency level, a non-incremental request for a large 638 resource followed by an incremental request for a small resource. 640 2. At the same urgency level, an incremental request of 641 indeterminate length followed by a non-incremental large 642 resource. 644 It is RECOMMENDED that servers avoid such starvation where possible. 645 The method to do so is an implementation decision. For example, a 646 server might pre-emptively send responses of a particular incremental 647 type based on other information such as content size. 649 10. Fairness 651 As a general guideline, a server SHOULD NOT use priority information 652 for making schedule decisions across multiple connections, unless it 653 knows that those connections originate from the same client. Due to 654 this, priority information conveyed over a non-coalesced HTTP 655 connection (e.g., HTTP/1.1) might go unused. 657 The remainder of this section discusses scenarios where unfairness is 658 problematic and presents possible mitigations, or where unfairness is 659 desirable. 661 TODO: Discuss if we should add a signal that mitigates this issue. 662 For example, we might add a SETTINGS parameter that indicates the 663 next hop that the connection is NOT coalesced (see 664 https://github.com/kazuho/draft-kazuho-httpbis-priority/issues/99). 666 10.1. Coalescing Intermediaries 668 When an intermediary coalesces HTTP requests coming from multiple 669 clients into one HTTP/2 or HTTP/3 connection going to the backend 670 server, requests that originate from one client might have higher 671 precedence than those coming from others. 673 It is sometimes beneficial for the server running behind an 674 intermediary to obey to the value of the Priority header field. As 675 an example, a resource-constrained server might defer the 676 transmission of software update files that would have the background 677 urgency being associated. However, in the worst case, the asymmetry 678 between the precedence declared by multiple clients might cause 679 responses going to one user agent to be delayed totally after those 680 going to another. 682 In order to mitigate this fairness problem, a server could use 683 knowledge about the intermediary as another signal in its 684 prioritization decisions. For instance, if a server knows the 685 intermediary is coalescing requests, then it could serve the 686 responses in round-robin manner. This can work if the constrained 687 resource is network capacity between the intermediary and the user 688 agent, as the intermediary buffers responses and forwards the chunks 689 based on the prioritization scheme it implements. 691 A server can determine if a request came from an intermediary through 692 configuration, or by consulting if that request contains one of the 693 following header fields: 695 o Forwarded, X-Forwarded-For ([RFC7239]) 697 o Via ([RFC7230], Section 5.7.1) 699 10.2. HTTP/1.x Back Ends 701 It is common for CDN infrastructure to support different HTTP 702 versions on the front end and back end. For instance, the client- 703 facing edge might support HTTP/2 and HTTP/3 while communication to 704 back end servers is done using HTTP/1.1. Unlike with connection 705 coalescing, the CDN will "de-mux" requests into discrete connections 706 to the back end. As HTTP/1.1 and older do not provide a way to 707 concurrently transmit multiple responses, there is no immediate 708 fairness issue in protocol. However, back end servers MAY still use 709 client headers for request scheduling. Back end servers SHOULD only 710 schedule based on client priority information where that information 711 can be scoped to individual end clients. Authentication and other 712 session information might provide this linkability. 714 10.3. Intentional Introduction of Unfairness 716 It is sometimes beneficial to deprioritize the transmission of one 717 connection over others, knowing that doing so introduces a certain 718 amount of unfairness between the connections and therefore between 719 the requests served on those connections. 721 For example, a server might use a scavenging congestion controller on 722 connections that only convey background priority responses such as 723 software update images. Doing so improves responsiveness of other 724 connections at the cost of delaying the delivery of updates. 726 11. Why use an End-to-End Header Field? 728 Contrary to the prioritization scheme of HTTP/2 that uses a hop-by- 729 hop frame, the Priority header field is defined as end-to-end. 731 The rationale is that the Priority header field transmits how each 732 response affects the client's processing of those responses, rather 733 than how relatively urgent each response is to others. The way a 734 client processes a response is a property associated to that client 735 generating that request. Not that of an intermediary. Therefore, it 736 is an end-to-end property. How these end-to-end properties carried 737 by the Priority header field affect the prioritization between the 738 responses that share a connection is a hop-by-hop issue. 740 Having the Priority header field defined as end-to-end is important 741 for caching intermediaries. Such intermediaries can cache the value 742 of the Priority header field along with the response, and utilize the 743 value of the cached header field when serving the cached response, 744 only because the header field is defined as end-to-end rather than 745 hop-by-hop. 747 It should also be noted that the use of a header field carrying a 748 textual value makes the prioritization scheme extensible; see the 749 discussion below. 751 12. Security Considerations 753 [CVE-2019-9513] aka "Resource Loop", is a DoS attack based on 754 manipulation of the HTTP/2 priority tree. Extensible priorities does 755 not use stream dependencies, which mitigates this vulnerability. 757 TBD: depending on the outcome of reprioritization discussions, 758 following paragraphs may change or be removed. 760 [RFC7540], Section 5.3.4 describes a scenario where closure of 761 streams in the priority tree could cause suboptimal prioritization. 763 To avoid this, [RFC7540] states that "an endpoint SHOULD retain 764 stream prioritization state for a period after streams become 765 closed". Retaining state for streams no longer counted towards 766 stream concurrency consumes server resources. Furthermore, [RFC7540] 767 identifies that reprioritization of a closed stream could affect 768 dependents; it recommends updating the priority tree if sufficient 769 state is stored, which will also consume server resources. To limit 770 this commitment, it is stated that "The amount of prioritization 771 state that is retained MAY be limited" and "If a limit is applied, 772 endpoints SHOULD maintain state for at least as many streams as 773 allowed by their setting for SETTINGS_MAX_CONCURRENT_STREAMS.". 774 Extensible priorities does not use stream dependencies, which 775 minimizes most of the resource concerns related to this scenario. 777 [RFC7540], Section 5.3.4 also presents considerations about the state 778 required to store priority information about streams in an "idle" 779 state. This state can be limited by adopting the guidance about 780 concurrency limits described above. Extensible priorities is subject 781 to a similar consideration because PRIORITY_UPDATE frames may arrive 782 before the request that they reference. A server is required to 783 store the information in order to apply the most up-to-date signal to 784 the request. However, HTTP/3 implementations might have practical 785 barriers to determining reasonable stream concurrency limits 786 depending on the information that is available to them from the QUIC 787 transport layer. TODO: so what can we suggest? 789 13. IANA Considerations 791 This specification registers the following entry in the Permanent 792 Message Header Field Names registry established by [RFC3864]: 794 Header field name: Priority 796 Applicable protocol: http 798 Status: standard 800 Author/change controller: IETF 802 Specification document(s): This document 804 Related information: n/a 806 This specification registers the following entry in the HTTP/2 807 Settings registry established by [RFC7540]: 809 Name: SETTINGS_DEPRECATE_HTTP2_PRIORITIES 810 Code: 0x9 812 Initial value: 0 814 Specification: This document 816 This specification registers the following entry in the HTTP/2 Frame 817 Type registry established by [RFC7540]: 819 Frame Type: PRIORITY_UPDATE 821 Code: 0x10 823 Specification: This document 825 This specification registers the following entries in the HTTP/3 826 Frame Type registry established by [I-D.ietf-quic-http]: 828 Frame Type: PRIORITY_UPDATE 830 Code: 0xF0700 and 0xF0701 832 Specification: This document 834 14. References 836 14.1. Normative References 838 [I-D.ietf-quic-http] 839 Bishop, M., "Hypertext Transfer Protocol Version 3 840 (HTTP/3)", draft-ietf-quic-http-31 (work in progress), 841 September 2020. 843 [I-D.ietf-quic-transport] 844 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 845 and Secure Transport", draft-ietf-quic-transport-31 (work 846 in progress), September 2020. 848 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 849 Requirement Levels", BCP 14, RFC 2119, 850 DOI 10.17487/RFC2119, March 1997, 851 . 853 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 854 Protocol (HTTP/1.1): Message Syntax and Routing", 855 RFC 7230, DOI 10.17487/RFC7230, June 2014, 856 . 858 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 859 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 860 DOI 10.17487/RFC7540, May 2015, 861 . 863 [STRUCTURED-FIELDS] 864 Nottingham, M. and P. Kamp, "Structured Field Values for 865 HTTP", draft-ietf-httpbis-header-structure-19 (work in 866 progress), June 2020. 868 14.2. Informative References 870 [CVE-2019-9513] 871 Common Vulnerabilities and Exposures, "CVE-2019-9513", 872 March 2019, . 875 [I-D.lassey-priority-setting] 876 Lassey, B. and L. Pardue, "Declaring Support for HTTP/2 877 Priorities", draft-lassey-priority-setting-00 (work in 878 progress), July 2019. 880 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 881 Procedures for Message Header Fields", BCP 90, RFC 3864, 882 DOI 10.17487/RFC3864, September 2004, 883 . 885 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 886 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 887 RFC 7234, DOI 10.17487/RFC7234, June 2014, 888 . 890 [RFC7239] Petersson, A. and M. Nilsson, "Forwarded HTTP Extension", 891 RFC 7239, DOI 10.17487/RFC7239, June 2014, 892 . 894 [RFC8081] Lilley, C., "The "font" Top-Level Media Type", RFC 8081, 895 DOI 10.17487/RFC8081, February 2017, 896 . 898 14.3. URIs 900 [1] https://lists.w3.org/Archives/Public/ietf-http-wg/ 902 [2] https://httpwg.org/ 904 [3] https://github.com/httpwg/http-extensions/labels/priorities 906 [4] http://tools.ietf.org/agenda/83/slides/slides-83-httpbis-5.pdf 908 [5] https://github.com/pmeenan/http3-prioritization-proposal 910 Appendix A. Acknowledgements 912 Roy Fielding presented the idea of using a header field for 913 representing priorities in http://tools.ietf.org/agenda/83/slides/ 914 slides-83-httpbis-5.pdf [4]. In https://github.com/pmeenan/http3- 915 prioritization-proposal [5], Patrick Meenan advocates for 916 representing the priorities using a tuple of urgency and concurrency. 917 The ability to deprecate HTTP/2 prioritization is based on 918 [I-D.lassey-priority-setting], authored by Brad Lassey and Lucas 919 Pardue, with modifications based on feedback that was not 920 incorporated into an update to that document. 922 The motivation for defining an alternative to HTTP/2 priorities is 923 drawn from discussion within the broad HTTP community. Special 924 thanks to Roberto Peon, Martin Thomson and Netflix for text that was 925 incorporated explicitly in this document. 927 In addition to the people above, this document owes a lot to the 928 extensive discussion in the HTTP priority design team, consisting of 929 Alan Frindell, Andrew Galloni, Craig Taylor, Ian Swett, Kazuho Oku, 930 Lucas Pardue, Matthew Cox, Mike Bishop, Roberto Peon, Robin Marx, Roy 931 Fielding. 933 Appendix B. Change Log 935 B.1. Since draft-ietf-httpbis-priority-01 937 o PRIORITY_UPDATE frame changes (#1096, #1079, #1167, #1262, #1267, 938 #1271) 940 o Add section to describe server scheduling considerations (#1215, 941 #1232, #1266) 943 o Remove specific instructions related to intermediary fairness 944 (#1022, #1264) 946 B.2. Since draft-ietf-httpbis-priority-00 948 o Move text around (#1217, #1218) 950 o Editorial change to the default urgency. The value is 3, which 951 was always the intent of previous changes. 953 B.3. Since draft-kazuho-httpbis-priority-04 955 o Minimize semantics of Urgency levels (#1023, #1026) 957 o Reduce guidance about how intermediary implements merging priority 958 signals (#1026) 960 o Remove mention of CDN-Loop (#1062) 962 o Editorial changes 964 o Make changes due to WG adoption 966 o Removed outdated Consideration (#118) 968 B.4. Since draft-kazuho-httpbis-priority-03 970 o Changed numbering from "[-1,6]" to "[0,7]" (#78) 972 o Replaced priority scheme negotiation with HTTP/2 priority 973 deprecation (#100) 975 o Shorten parameter names (#108) 977 o Expand on considerations (#105, #107, #109, #110, #111, #113) 979 B.5. Since draft-kazuho-httpbis-priority-02 981 o Consolidation of the problem statement (#61, #73) 983 o Define SETTINGS_PRIORITIES for negotiation (#58, #69) 985 o Define PRIORITY_UPDATE frame for HTTP/2 and HTTP/3 (#51) 987 o Explain fairness issue and mitigations (#56) 989 B.6. Since draft-kazuho-httpbis-priority-01 991 o Explain how reprioritization might be supported. 993 B.7. Since draft-kazuho-httpbis-priority-00 995 o Expand urgency levels from 3 to 8. 997 Authors' Addresses 999 Kazuho Oku 1000 Fastly 1002 Email: kazuhooku@gmail.com 1004 Lucas Pardue 1005 Cloudflare 1007 Email: lucaspardue.24.7@gmail.com