idnits 2.17.1 draft-krasic-quic-qcram-04.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 document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 143: '...ulnerable header fields, BLOCKING MUST...' RFC 2119 keyword, line 150: '... flag MUST be set. If the peer does...' RFC 2119 keyword, line 210: '... Control Streams SHOULD contain only L...' RFC 2119 keyword, line 215: '...s on request and push streams MUST NOT...' RFC 2119 keyword, line 272: '... the table, and the connection MUST be...' (5 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 23, 2018) is 2284 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) == Outdated reference: A later version (-34) exists of draft-ietf-quic-http-08 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-08 -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 QUIC C. Krasic 3 Internet-Draft Google 4 Intended status: Standards Track January 23, 2018 5 Expires: July 27, 2018 7 Header Compression for HTTP over QUIC 8 draft-krasic-quic-qcram-04 10 Abstract 12 The design of the core QUIC transport subsumes many HTTP/2 features, 13 prominent among them stream multiplexing. A key advantage of the 14 QUIC transport is stream multiplexing free of head-of-line (HoL) 15 blocking between streams. In HTTP/2, multiplexed streams can suffer 16 HoL blocking due to TCP. 18 If HTTP/2's HPACK is used for header compression, HTTP/QUIC is still 19 vulnerable to HoL blocking, because of HPACK's assumption of in-order 20 delivery. This draft defines QCRAM, a variation of HPACK and 21 mechanisms in the HTTP/QUIC mapping that allow the flexibility to 22 avoid header-compression-induced HoL blocking. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on July 27, 2018. 41 Copyright Notice 43 Copyright (c) 2018 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Head-of-Line Blocking in HPACK . . . . . . . . . . . . . 3 60 1.2. Avoiding Head-of-Line Blocking in HTTP/QUIC . . . . . . . 3 61 2. HTTP over QUIC mapping extensions . . . . . . . . . . . . . . 4 62 2.1. HEADERS and PUSH_PROMISE . . . . . . . . . . . . . . . . 4 63 2.2. HEADER_ACK . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. HPACK extensions . . . . . . . . . . . . . . . . . . . . . . 5 65 3.1. Allowed Instructions . . . . . . . . . . . . . . . . . . 5 66 3.2. Header Block Prefix . . . . . . . . . . . . . . . . . . . 5 67 3.3. Hybrid absolute-relative indexing . . . . . . . . . . . . 6 68 3.4. Preventing Eviction Races . . . . . . . . . . . . . . . . 6 69 3.4.1. Blocked Evictions . . . . . . . . . . . . . . . . . . 7 70 3.5. Refreshing Entries with Duplication . . . . . . . . . . . 7 71 4. Performance considerations . . . . . . . . . . . . . . . . . 7 72 4.1. Speculative table updates . . . . . . . . . . . . . . . . 7 73 4.2. Fixed overhead. . . . . . . . . . . . . . . . . . . . . . 8 74 4.3. Co-ordinated Packetization . . . . . . . . . . . . . . . 8 75 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 77 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 79 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 80 8.2. Informative References . . . . . . . . . . . . . . . . . 9 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 83 1. Introduction 85 The QUIC transport protocol was designed from the outset to support 86 HTTP semantics, and its design subsumes many of the features of 87 HTTP/2. QUIC's stream multiplexing comes into some conflict with 88 header compression. A key goal of the design of QUIC is to improve 89 stream multiplexing relative to HTTP/2 by eliminating HoL (head of 90 line) blocking, which can occur in HTTP/2. HoL blocking can happen 91 because all HTTP/2 streams are multiplexed onto a single TCP 92 connection with its in-order semantics. QUIC can maintain 93 independence between streams because it implements core transport 94 functionality in a fully stream-aware manner. However, the HTTP/QUIC 95 mapping is still subject to HoL blocking if HPACK is used directly. 96 HPACK exploits multiplexing for greater compression, shrinking the 97 representation of headers that have appeared earlier on the same 98 connection. In the context of QUIC, this imposes a vulnerability to 99 HoL blocking (see Section 1.1). 101 QUIC is described in [QUIC-TRANSPORT]. The HTTP/QUIC mapping is 102 described in [QUIC-HTTP]. For a full description of HTTP/2, see 103 [RFC7540]. The description of HPACK is [RFC7541], with important 104 terminology in Section 1.3. 106 QCRAM modifies HPACK to allow correctness in the presence of out-of- 107 order delivery, with flexibility for implementations to balance 108 between resilience against HoL blocking and optimal compression 109 ratio. The design goals are to closely approach the compression 110 ratio of HPACK with substantially less head-of-line blocking under 111 the same loss conditions. 113 QCRAM is intended to be a relatively non-intrusive extension to 114 HPACK; an implementation should be easily shared within stacks 115 supporting both HTTP/2 over (TLS+)TCP and HTTP/QUIC. 117 1.1. Head-of-Line Blocking in HPACK 119 HPACK enables several types of header representations, one of which 120 also adds the header to a dynamic table of header values. These 121 values are then available for reuse in subsequent header blocks 122 simply by referencing the entry number in the table. 124 If the packet containing a header is lost, that stream cannot 125 complete header processing until the packet is retransmitted. This 126 is unavoidable. However, other streams which rely on the state 127 created by that packet _also_ cannot make progress. This is the 128 problem which QUIC solves in general, but which is reintroduced by 129 HPACK when the loss includes a HEADERS frame. 131 1.2. Avoiding Head-of-Line Blocking in HTTP/QUIC 133 In the example above, the second stream contained a reference to data 134 which might not yet have been processed by the recipient. Such 135 references are called "vulnerable," because the loss of a different 136 packet can keep the reference from being usable. 138 The encoder can choose on a per-header-block basis whether to favor 139 higher compression ratio (by permitting vulnerable references) or HoL 140 resilience (by avoiding them). This is signaled by the BLOCKING flag 141 in HEADERS and PUSH_PROMISE frames (see Section 2). 143 If a header block contains no vulnerable header fields, BLOCKING MUST 144 be 0. This implies that the header fields are represented either as 145 references to dynamic table entries which are known to have been 146 received, or as Literal header fields (see [RFC7541] Section 6.2). 148 If a header block contains any header field which references dynamic 149 table state which the peer might not have received yet, the BLOCKING 150 flag MUST be set. If the peer does not yet have the appropriate 151 state, such blocks might not be processed on arrival. 153 The header block contains a prefix (Section 3.2). This prefix 154 contains table offset information that establishes total ordering 155 among all headers, regardless of reordering in the transport (see 156 Section 3.3). In blocking mode, the prefix additionally identifies 157 the minimum state required to process any vulnerable references in 158 the header block (see "Depends" in Section Section 3.3). When the 159 necessary state has arrived, the header block can be processed. 160 Notice that while blocked, HB's header field data remains in stream 161 B's flow control window. 163 2. HTTP over QUIC mapping extensions 165 2.1. HEADERS and PUSH_PROMISE 167 HEADERS and PUSH_PROMISE frames define a new flag. 169 BLOCKING (0x01): Indicates the stream might need to wait for 170 dependent headers before processing. If 0, the frame can be 171 processed immediately upon receipt. 173 HEADERS frames can be sent on the Connection Control Stream as well 174 as on request / push streams. 176 2.2. HEADER_ACK 178 The HEADER_ACK frame (type=0x8) is sent from the decoder to the 179 encoder on the Control Stream when the decoder has fully processed a 180 header block. It is used by the encoder to determine whether 181 subsequent indexed representations that might reference that block 182 are vulnerable to HoL blocking. 184 The HEADER_ACK frame indicates the stream on which the header block 185 was processed by encoding the Stream ID as a variable-length integer. 186 The same Stream ID can be identified multiple times, as multiple 187 header-containing blocks can be sent on a single stream in the case 188 of intermediate responses, trailers, pushed requests, etc. as well as 189 on the Control Streams. 191 Since header frames on each stream are received and processed in 192 order, this gives the encoder precise feedback on which header blocks 193 within a stream have been fully processed. This information can then 194 be used to correctly track outstanding stream references to 195 checkpoints. 197 0 1 2 3 4 5 6 7 198 +---+---+---+---+---+---+---+---+ 199 | Stream ID [i] | 200 +---+---------------------------+ 202 HEADER_ACK frame 204 The HEADER_ACK frame does not define any flags. 206 3. HPACK extensions 208 3.1. Allowed Instructions 210 HEADERS frames on the Control Streams SHOULD contain only Literal 211 with Incremental Indexing representations. Frames on this stream 212 modify the dynamic table state without generating output to any 213 particular request. 215 HEADERS and PUSH_PROMISE frames on request and push streams MUST NOT 216 contain Literal with Incremental Indexing representations. Frames on 217 these streams reference the dynamic table in a particular state 218 without modifying it, but emit the headers for an HTTP request or 219 response. 221 3.2. Header Block Prefix 223 In HEADERS and PUSH_PROMISE frames, HPACK Header data is prefixed by 224 an integer: "Base Index". "Base index" is the cumulative number of 225 entries added to the table prior to encoding the current block, it is 226 encoded as a single 8-bit prefix integer: 228 0 1 2 3 4 5 6 7 229 +-+-+-+-+-+-+-+-+ 230 |Base Index (8+)| 231 +---------------+ 233 Figure 1: Absolute indexing (BLOCKING=0x0) 235 Section 3.3 describes the role of "Base Index". 237 When the BLOCKING flag is 0x1, a the prefix additionally contains a 238 second HPACK integer (8-bit prefix) 'Depends': 240 0 1 2 3 4 5 6 7 241 +-+-+-+-+-+-+-+-+ 242 |Base Index (8+)| 243 +---------------+ 244 |Depends (8+)| 245 +---------------+ 247 Figure 2: Absolute indexing (BLOCKING=0x1) 249 Depends is used to identify header dependencies, namely the largest 250 table entry referred to by indexed representations within the 251 following header block. Its usage is described in Section 1.2. The 252 largest index referenced is "Base Index - Depends". 254 3.3. Hybrid absolute-relative indexing 256 HPACK indexed entries refer to an entry by its current position in 257 the dynamic table. As Figure 1 of [RFC7541] illustrates, newer 258 entries have smaller indices, and older entries are evicted first if 259 the table is full. Under this scheme, each insertion to the table 260 causes the index of all existing entries to change (implicitly). 261 Implicit index updates are acceptable for HTTP/2 because TCP is 262 totally ordered, but are problematic in the out-of-order context of 263 QUIC. 265 QCRAM uses a hybrid absolute-relative indexing approach. The prefix 266 defined in Section 3.2 is used by the decoder to interpret all 267 subsequent HPACK instructions at absolute positions for indexed 268 lookups and insertions. 270 Since QCRAM handles blocking at the header block level, it is an 271 error if the HPACK decoder encounters an indexed representation that 272 refers to an entry missing from the table, and the connection MUST be 273 closed with the "HTTP_HPACK_DECOMPRESSION_FAILED" error code. 275 3.4. Preventing Eviction Races 277 Due to out-of-order arrival, QCRAM's eviction algorithm requires 278 changes (relative to HPACK) to avoid the possibility that an indexed 279 representation is decoded after the referenced entry has already been 280 evicted. QCRAM employs a two-phase eviction algorithm, in which the 281 encoder will not evict entries that have outstanding (unacknowledged) 282 references. 284 3.4.1. Blocked Evictions 286 The decoder MUST NOT permit an entry to be evicted while a reference 287 to that entry remains unacknowledged. If a new header to be inserted 288 into the dynamic table would cause the eviction of such an entry, the 289 encoder MUST NOT emit the insert instruction until the reference has 290 been processed by the decoder and acknowledged. 292 The encoder can emit a literal representation for the new header in 293 order to avoid encoding delays, and MAY insert the header into the 294 table later if desired. 296 To ensure that the blocked eviction case is rare, references to the 297 oldest entries in the dynamic table SHOULD be avoided. When one of 298 the oldest entries in the table is still actively used for 299 references, the encoder SHOULD emit an Indexed-Duplicate 300 representation instead (see Section 3.5). 302 3.5. Refreshing Entries with Duplication 304 0 1 2 3 4 5 6 7 305 +-+-+-+-+-+-+-+-+ 306 |0|0|1|Index(5+)| 307 +-+-+-+---------+ 309 Figure 3: Indexed Header Field with Duplication 311 _Indexed-Duplicates_ insert a new entry into the dynamic table which 312 duplicates an existing entry. [RFC7541] allows duplicate HPACK table 313 entries, that is entries that have the same name and value. 315 This replaces the HPACK instruction for Dynamic Table Size Update 316 (see Section 6.3 of [RFC7541], which is not supported by HTTP over 317 QUIC. 319 4. Performance considerations 321 4.1. Speculative table updates 323 Implementations can _speculatively_ send header frames on the HTTP 324 Control Streams which are not needed for any current HTTP request or 325 response. Such headers could be used strategically to improve 326 performance. For instance, the encoder might decide to _refresh_ by 327 sending Indexed-Duplicate representations for popular header fields 328 (Section 3.2), ensuring they have small indices and hence minimal 329 size on the wire. 331 4.2. Fixed overhead. 333 HPACK defines overhead as 32 bytes ([RFC7541] Section 4.1). QCRAM 334 adds some per-entry state, to track acknowledgment status and 335 eviction reference count. A larger value than 32 might be more 336 accurate for QCRAM. 338 4.3. Co-ordinated Packetization 340 When a dynamic table entry is both defined and referenced by header 341 blocks within the same packet, there is no risk of HoL blocking and 342 using an indexed representation is strictly better than using a 343 literal. An implementation could attempt to exploit this exception 344 by employing co-ordination between QCRAM compression and QUIC 345 transport packetization. However, if the packet is lost, the 346 transport might choose a different packetization when retransmitting 347 the missing data. 349 5. Security Considerations 351 TBD. 353 6. IANA Considerations 355 This document registers a new frame type, HEADER_ACK, for HTTP/QUIC. 356 This will need to be added to the IANA Considerations of [QUIC-HTTP]. 358 7. Acknowledgments 360 This draft draws heavily on the text of [RFC7541]. The indirect 361 input of those authors is gratefully acknowledged, as well as ideas 362 from: 364 o Mike Bishop 366 o Patrick McManus 368 o Biren Roy 370 o Alan Frindell 372 o Ian Swett 374 o Ryan Hamilton 376 8. References 378 8.1. Normative References 380 [QUIC-HTTP] 381 Bishop, M., "Hypertext Transfer Protocol (HTTP) over 382 QUIC", draft-ietf-quic-http-08 (work in progress), 383 December 2017. 385 [RFC7541] Peon, R. and H. Ruellan, "HPACK: Header Compression for 386 HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, 387 . 389 8.2. Informative References 391 [QUIC-TRANSPORT] 392 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 393 and Secure Transport", draft-ietf-quic-transport-08 (work 394 in progress), December 2017. 396 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 397 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 398 DOI 10.17487/RFC7540, May 2015, 399 . 401 Author's Address 403 Charles 'Buck' Krasic 404 Google 406 Email: ckrasic@google.com