idnits 2.17.1 draft-bishop-httpbis-priority-placeholder-00.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 ([I-D.ietf-quic-http], [RFC7540]), 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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 25, 2017) is 2439 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) ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) == Outdated reference: A later version (-34) exists of draft-ietf-quic-http-04 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTPbis M. Bishop 3 Internet-Draft Microsoft 4 Intended status: Standards Track July 25, 2017 5 Expires: January 26, 2018 7 Priority Placeholders in HTTP/2 8 draft-bishop-httpbis-priority-placeholder-00 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 ([I-D.ietf-quic-http]). This document proposes an extension to the 17 HTTP/2 priority scheme for 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 http://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 January 26, 2018. 36 Copyright Notice 38 Copyright (c) 2017 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 (http://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 . . . . . . . . . . . . . 3 56 2.1. Priority Placeholder Setting . . . . . . . . . . . . . . 3 57 2.1.1. Mid-session updates . . . . . . . . . . . . . . . . . 3 58 2.2. Frame Modifications . . . . . . . . . . . . . . . . . . . 3 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. Security Considerations . . . . . . . . . . . . . . . . . . . 6 63 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 64 4.1. SETTINGS_PLACEHOLDERS Setting . . . . . . . . . . . . . . 6 65 4.2. PLACEHOLDER_PRIORITY Frame . . . . . . . . . . . . . . . 6 66 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 5.1. Normative References . . . . . . . . . . . . . . . . . . 7 68 5.2. Informative References . . . . . . . . . . . . . . . . . 7 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 71 1. Introduction 73 Stream Priority is described in [RFC7540], Section 5.3. Priority is 74 communicated using PRIORITY frames and with reference to other 75 streams, with stream 0 being the root of the tree. Each stream 76 depends on one other stream with a particular weight; these weights 77 represent relative priorities among the multiple children of a 78 stream. 80 Unfortunately, the scheme as specified encourages servers to actively 81 maintain closed streams in the priority tree, since other streams 82 might reference them later. This produces an unbounded state 83 commitment on the part of the server if it is to correctly reflect 84 any possible reference the client might make. While priorities are 85 only advisory and the server is free to discard as much state as it 86 needs to, references to streams which are no longer in the server's 87 state are treated as references to the root of the tree. This can 88 result in wildly different conceptions of the priority tree between 89 client and server, a situation which all parties would prefer to 90 avoid. 92 1.1. Notational Conventions 94 The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this 95 document. It's not shouting; when they are capitalized, they have 96 the special meaning defined in [RFC2119]. 98 2. The Priority Placeholder Extension 100 This extension consists of an additional setting Section 2.1, changes 101 to the set of HTTP/2 frames Section 2.2, and modified state 102 management logic on the server Section 2.3. 104 2.1. Priority Placeholder Setting 106 An HTTP/2 peer that supports Priority Placeholders indicates this 107 using the HTTP/2 "SETTINGS_PLACEHOLDERS" (0xSETTING-TBD) setting. 109 When a value for the "SETTINGS_PLACEHOLDERS" setting is not set, this 110 indicates that the peer does not support the extension, and other 111 protocol elements in this document MUST NOT be used. A client that 112 supports this extension SHOULD set this value to 0 (0x00). 114 A server which supports this extension MUST set this value to a non- 115 zero number indicating the number of placeholders it is willing to 116 make available to the client, which MUST be at most 2^31-1. Clients 117 MUST NOT use the protocol elements in this document unless the server 118 has indicated support by setting a non-zero value. 120 2.1.1. Mid-session updates 122 HTTP/2 permits settings to change during the course of a connection. 123 This setting can be freely increased at any time without consequence, 124 and servers SHOULD NOT reduce the value during the lifetime of a 125 connection. 127 If a client receives a reduction in the number of permitted 128 placeholders, it MUST assume that all placeholders over the new limit 129 have been pruned from the tree and SHOULD immediately issue PRIORITY 130 and PLACEHOLDER_PRIORITY frames as necessary to rebuild the priority 131 tree as desired. Once the SETTINGS frame has been acknowledged, 132 servers should treat the excess placeholders as inactive and prune 133 them following the same logic in Section 2.3. 135 2.2. Frame Modifications 136 2.2.1. Existing Frame Types 138 When client and server have opted in to this extension, the HTTP/2 139 PRIORITY frame and HEADERS frame contain one additional flag: 141 DEPENDENT_ON_PLACEHOLDER (0x2): When set, bit 1 indicates that the 142 value in the Stream Dependency field is a Placeholder ID rather 143 than a Stream ID. 145 In HEADERS, this flag MUST NOT be set if the PRIORITY flag is not 146 set. 148 2.2.2. PLACEHOLDER_PRIORITY Frame 150 The PLACEHOLDER_PRIORITY (type=0xFRAME-TBD) frame specifies the 151 sender-advised priority of a placeholder. It MUST be sent only on 152 Stream 0. The semantics of the Stream Dependency, Weight, and E flag 153 are the same as in the HTTP/2 PRIORITY frame. 155 The flags defined are: 157 E (0x01): Indicates that the stream dependency is exclusive (see 158 [RFC7540], Section 5.3). 160 DEPENDENT_ON_PLACEHOLDER (0x2): When set, bit 1 indicates that the 161 value in the Stream Dependency field is a Placeholder ID rather 162 than a Stream ID. 164 0 1 2 3 165 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 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 |0| Placeholder ID (31) | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 |0| Stream Dependency (31) | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | Weight (8) | 172 +-+-+-+-+-+-+-+-+ 174 Figure 1: PRIORITY frame payload 176 The PLACEHOLDER_PRIORITY frame payload has the following fields: 178 Prioritized Stream: A 31-bit stream identifier for the request 179 stream whose priority is being updated. 181 Stream Dependency: A 31-bit stream or placeholder identifier for the 182 request stream that this stream depends on (see [RFC7540], 183 Section 5.3). 185 Weight: An unsigned 8-bit integer representing a priority weight for 186 the stream (see [RFC7540], Section 5.3). Add one to the value to 187 obtain a weight between 1 and 256. 189 A PLACEHOLDER_PRIORITY frame MUST have a payload length of nine 190 octets. A PLACEHOLDER_PRIORITY frame of any other length MUST be 191 treated as a connection error of type PROTOCOL_ERROR if the sender 192 has advertised support for this extension, and ignored otherwise. 194 2.3. Priority Management Logic 196 This extension provides a mechanism for servers to limit how many 197 additional IDs which do not refer to an active request will be used 198 to maintain priority state. Because the server commits to maintain 199 these inactive IDs, clients can use them with confidence that the 200 server will not have discarded the state without warning. 202 In exchange, the server knows it can aggressively prune inactive 203 regions from the priority tree, because placeholders will be used to 204 "root" any persistent structure of the tree which the client cares 205 about retaining. For prioritization purposes, a node in the tree is 206 considered "inactive" when the corresponding stream has been closed 207 for at least two round-trip times (using any reasonable estimate 208 available on the server). This delay helps mitigate race conditions 209 where the server has pruned a node the client believed was still 210 active and used as a Stream Dependency. 212 Specifically, the server MAY at any time: 214 o Identify and discard branches of the tree containing only inactive 215 nodes (i.e. a node with only other inactive nodes as descendants, 216 along with those descendants) 218 o Identify and condense interior regions of the tree containing only 219 inactive nodes, allocating weight appropriately 221 x x x 222 | | | 223 P P P 224 / \ | | 225 I I ==> I ==> A 226 / \ | | 227 A I A A 228 | | 229 A A 231 Figure 2: Example of Priority Tree Pruning 233 In the example in Figure 2, "P" represents a Placeholder, "A" 234 represents an active node, and "I" represents an inactive node. In 235 the first step, the server discards two inactive branches (each a 236 single node). In the second step, the server condenses an interior 237 inactive node. Note that these transformations will result in no 238 change in the resources allocated to a particular active stream. 240 Clients MUST assume the server is actively performing such pruning 241 and MUST NOT declare a dependency on a stream it knows to have been 242 closed. 244 3. Security Considerations 246 This extension is believed to improve security relative to [RFC7540], 247 as it helps to constrain a previously unbounded state commitment. 249 4. IANA Considerations 251 This document registers one new frame type and one new setting. 253 4.1. SETTINGS_PLACEHOLDERS Setting 255 The "SETTINGS_PLACEHOLDERS" setting is registered in the "HTTP/2 256 Settings" registry established in [RFC7540]. 258 Name: SETTINGS_PLACEHOLDERS 260 Code: 0xSETTING-TBD 262 Initial Value: not set 264 Specification: This document. 266 4.2. PLACEHOLDER_PRIORITY Frame 268 The "PLACEHOLDER_PRIORITY" frame is registered in the "HTTP/2 Frames" 269 registry established in [RFC7540]. 271 Name: PLACEHOLDER_PRIORITY 273 Code: 0xFRAME-TBD 275 Specification: This document. 277 5. References 279 5.1. Normative References 281 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 282 Requirement Levels", BCP 14, RFC 2119, 283 DOI 10.17487/RFC2119, March 1997, 284 . 286 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 287 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 288 DOI 10.17487/RFC7540, May 2015, 289 . 291 5.2. Informative References 293 [I-D.ietf-quic-http] 294 Bishop, M., "Hypertext Transfer Protocol (HTTP) over 295 QUIC", draft-ietf-quic-http-04 (work in progress), June 296 2017. 298 Author's Address 300 Mike Bishop 301 Microsoft 303 Email: michael.bishop@microsoft.com