idnits 2.17.1 draft-bishop-httpbis-priority-placeholder-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 6, 2018) is 2269 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-quic-http' is defined on line 327, but no explicit reference was found in the text == Outdated reference: A later version (-34) exists of draft-ietf-quic-http-07 ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) == Outdated reference: A later version (-34) exists of draft-ietf-quic-http-07 -- Duplicate reference: draft-ietf-quic-http, mentioned in 'I-D.ietf-quic-http', was also mentioned in 'HQ'. Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTPbis M. Bishop 3 Internet-Draft Akamai 4 Intended status: Standards Track February 6, 2018 5 Expires: August 10, 2018 7 Priority Placeholders in HTTP/2 8 draft-bishop-httpbis-priority-placeholder-01 10 Abstract 12 RFC7540 defines HTTP/2, including a method for communicating 13 priorities. Some implementations have begun using closed streams as 14 placeholders when constructing their priority tree, but this has 15 unbounded state commitments and interacts poorly with HTTP/QUIC. 16 This document proposes an extension to the HTTP/2 priority scheme for 17 both protocols. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on August 10, 2018. 36 Copyright Notice 38 Copyright (c) 2018 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 55 2. The Priority Placeholder Extension to HTTP/2 . . . . . . . . 3 56 2.1. Priority Placeholder Setting . . . . . . . . . . . . . . 3 57 2.1.1. Mid-session updates . . . . . . . . . . . . . . . . . 3 58 2.2. Frame Modifications . . . . . . . . . . . . . . . . . . . 4 59 2.2.1. Existing Frame Types . . . . . . . . . . . . . . . . 4 60 2.2.2. PLACEHOLDER_PRIORITY Frame . . . . . . . . . . . . . 4 61 2.3. Priority Management Logic . . . . . . . . . . . . . . . . 5 62 3. Incorporating Placeholders in HTTP/QUIC . . . . . . . . . . . 6 63 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 65 5.1. SETTINGS_PLACEHOLDERS Setting . . . . . . . . . . . . . . 7 66 5.2. PLACEHOLDER_PRIORITY Frame . . . . . . . . . . . . . . . 7 67 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 6.1. Normative References . . . . . . . . . . . . . . . . . . 7 69 6.2. Informative References . . . . . . . . . . . . . . . . . 8 70 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 8 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Introduction 75 Stream Priority is described in [RFC7540], Section 5.3. Priority is 76 communicated using PRIORITY frames and with reference to other 77 streams, with stream 0 being the root of the tree. Each stream 78 depends on one other stream with a particular weight; these weights 79 represent relative priorities among the multiple children of a 80 stream. 82 Unfortunately, the scheme as specified encourages servers to actively 83 maintain closed streams in the priority tree, since other streams 84 might reference them later. This produces an unbounded state 85 commitment on the part of the server if it is to correctly reflect 86 any possible reference the client might make. While priorities are 87 only advisory and the server is free to discard as much state as it 88 needs to, references to streams which are no longer in the server's 89 state are treated as references to the root of the tree. This can 90 result in wildly different conceptions of the priority tree between 91 client and server, a situation which all parties would prefer to 92 avoid. 94 1.1. Notational Conventions 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 98 "OPTIONAL" in this document are to be interpreted as described in BCP 99 14 [RFC2119] [RFC8174] when, and only when, they appear in all 100 capitals, as shown here. 102 2. The Priority Placeholder Extension to HTTP/2 104 This extension consists of an additional setting Section 2.1, changes 105 to the set of HTTP/2 frames Section 2.2, and modified state 106 management logic on the server Section 2.3. 108 2.1. Priority Placeholder Setting 110 An HTTP/2 peer that supports Priority Placeholders indicates this 111 using the HTTP/2 "SETTINGS_PLACEHOLDERS" (0xSETTING-TBD) setting. 113 When a value for the "SETTINGS_PLACEHOLDERS" setting is not set, this 114 indicates that the peer does not support the extension, and other 115 protocol elements in this document MUST NOT be used. A client that 116 supports this extension SHOULD set this value to 0 (0x00). 118 A server which supports this extension MUST set this value to a non- 119 zero number indicating the number of placeholders it is willing to 120 make available to the client, which MUST be at most 2^31-1. Clients 121 MUST NOT use the protocol elements in this document unless the server 122 has indicated support by setting a non-zero value. 124 2.1.1. Mid-session updates 126 HTTP/2 permits settings to change during the course of a connection. 127 This setting can be freely increased at any time without consequence, 128 and servers SHOULD NOT reduce the value during the lifetime of a 129 connection. 131 If a client receives a reduction in the number of permitted 132 placeholders, it MUST assume that all placeholders over the new limit 133 have been pruned from the tree and SHOULD immediately issue PRIORITY 134 and PLACEHOLDER_PRIORITY frames as necessary to rebuild the priority 135 tree as desired. Once the SETTINGS frame has been acknowledged, 136 servers should treat the excess placeholders as inactive and prune 137 them following the same logic in Section 2.3. 139 2.2. Frame Modifications 141 2.2.1. Existing Frame Types 143 When client and server have opted in to this extension, the HTTP/2 144 PRIORITY frame and HEADERS frame contain one additional flag: 146 DEPENDENT_ON_PLACEHOLDER (0x2): When set, bit 1 indicates that the 147 value in the Stream Dependency field is a Placeholder ID rather 148 than a Stream ID. 150 In HEADERS, this flag MUST NOT be set if the PRIORITY flag is not 151 set. 153 2.2.2. PLACEHOLDER_PRIORITY Frame 155 The PLACEHOLDER_PRIORITY (type=0xFRAME-TBD) frame specifies the 156 sender-advised priority of a placeholder. It MUST be sent only on 157 Stream 0. The semantics of the Stream Dependency, Weight, and E flag 158 are the same as in the HTTP/2 PRIORITY frame. 160 The flags defined are: 162 E (0x01): Indicates that the stream dependency is exclusive (see 163 [RFC7540], Section 5.3). 165 DEPENDENT_ON_PLACEHOLDER (0x2): When set, bit 1 indicates that the 166 value in the Stream Dependency field is a Placeholder ID rather 167 than a Stream ID. 169 0 1 2 3 170 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 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 |0| Placeholder ID (31) | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 |0| Stream Dependency (31) | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | Weight (8) | 177 +-+-+-+-+-+-+-+-+ 179 Figure 1: PRIORITY frame payload 181 The PLACEHOLDER_PRIORITY frame payload has the following fields: 183 Prioritized Stream: A 31-bit stream identifier for the request 184 stream whose priority is being updated. 186 Stream Dependency: A 31-bit stream or placeholder identifier for the 187 request stream that this stream depends on (see [RFC7540], 188 Section 5.3). 190 Weight: An unsigned 8-bit integer representing a priority weight for 191 the stream (see [RFC7540], Section 5.3). Add one to the value to 192 obtain a weight between 1 and 256. 194 A PLACEHOLDER_PRIORITY frame MUST have a payload length of nine 195 octets. A PLACEHOLDER_PRIORITY frame of any other length MUST be 196 treated as a connection error of type PROTOCOL_ERROR if the sender 197 has advertised support for this extension, and ignored otherwise. 199 2.3. Priority Management Logic 201 This extension provides a mechanism for servers to limit how many 202 additional IDs which do not refer to an active request will be used 203 to maintain priority state. Because the server commits to maintain 204 these inactive IDs, clients can use them with confidence that the 205 server will not have discarded the state without warning. 207 In exchange, the server knows it can aggressively prune inactive 208 regions from the priority tree, because placeholders will be used to 209 "root" any persistent structure of the tree which the client cares 210 about retaining. For prioritization purposes, a node in the tree is 211 considered "inactive" when the corresponding stream has been closed 212 for at least two round-trip times (using any reasonable estimate 213 available on the server). This delay helps mitigate race conditions 214 where the server has pruned a node the client believed was still 215 active and used as a Stream Dependency. 217 Specifically, the server MAY at any time: 219 o Identify and discard branches of the tree containing only inactive 220 nodes (i.e. a node with only other inactive nodes as descendants, 221 along with those descendants) 223 o Identify and condense interior regions of the tree containing only 224 inactive nodes, allocating weight appropriately 225 x x x 226 | | | 227 P P P 228 / \ | | 229 I I ==> I ==> A 230 / \ | | 231 A I A A 232 | | 233 A A 235 Figure 2: Example of Priority Tree Pruning 237 In the example in Figure 2, "P" represents a Placeholder, "A" 238 represents an active node, and "I" represents an inactive node. In 239 the first step, the server discards two inactive branches (each a 240 single node). In the second step, the server condenses an interior 241 inactive node. Note that these transformations will result in no 242 change in the resources allocated to a particular active stream. 244 Clients MUST assume the server is actively performing such pruning 245 and MUST NOT declare a dependency on a stream it knows to have been 246 closed. 248 3. Incorporating Placeholders in HTTP/QUIC 250 HTTP/QUIC [HQ] uses a different PRIORITY frame which already permits 251 selecting either a stream or a Push ID (a new concept in HTTP/QUIC) 252 to be prioritized or used as a dependency. Expanding this frame to 253 support placeholders as well requires additional bits. 255 The PRIORITY frame currently uses two flag bits to indicate Request/ 256 Push dependencies on Request/Push. If the full matrix of 257 dependencies is to be supported (Request/Push/Placeholder dependent 258 on Request/Push/Placeholder), four bits would be required to 259 represent the space, with several invalid flag combinations being 260 defined. (If one combination were eliminated, three flags would be 261 sufficient to represent the remaining combinations, but the semantics 262 of individual flags would be unclear.) 264 HTTP/QUIC does not have the implicit closure of streams like HTTP/2. 265 While client implementations could reset streams which they intend to 266 use as priority placeholders, there has been interest in creating 267 greater clarity and synchronization between the client and server 268 views of the priority tree. 270 4. Security Considerations 272 This extension is believed to improve security relative to [RFC7540], 273 as it helps to constrain a previously unbounded state commitment. 275 5. IANA Considerations 277 This document registers one new frame type and one new setting. 279 5.1. SETTINGS_PLACEHOLDERS Setting 281 The "SETTINGS_PLACEHOLDERS" setting is registered in the "HTTP/2 282 Settings" registry established in [RFC7540]. 284 Name: SETTINGS_PLACEHOLDERS 286 Code: 0xSETTING-TBD 288 Initial Value: not set 290 Specification: This document. 292 5.2. PLACEHOLDER_PRIORITY Frame 294 The "PLACEHOLDER_PRIORITY" frame is registered in the "HTTP/2 Frames" 295 registry established in [RFC7540]. 297 Name: PLACEHOLDER_PRIORITY 299 Code: 0xFRAME-TBD 301 Specification: This document. 303 6. References 305 6.1. Normative References 307 [HQ] Bishop, M., "Hypertext Transfer Protocol (HTTP) over 308 QUIC", draft-ietf-quic-http-07 (work in progress), October 309 2017. 311 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 312 Requirement Levels", BCP 14, RFC 2119, 313 DOI 10.17487/RFC2119, March 1997, 314 . 316 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 317 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 318 DOI 10.17487/RFC7540, May 2015, 319 . 321 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 322 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 323 May 2017, . 325 6.2. Informative References 327 [I-D.ietf-quic-http] 328 Bishop, M., "Hypertext Transfer Protocol (HTTP) over 329 QUIC", draft-ietf-quic-http-07 (work in progress), October 330 2017. 332 Appendix A. Acknowledgements 334 A substantial portion of Mike's work on this draft was supported by 335 Microsoft during his employment there. 337 Author's Address 339 Mike Bishop 340 Akamai 342 Email: mbishop@evequefou.be