idnits 2.17.1 draft-bishop-quic-http-and-qpack-06.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 ([RFC7540], [RFC7541], [I-D.ietf-quic-transport]), 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 (December 11, 2017) is 2327 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-07 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-07 ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 QUIC Working Group M. Bishop 3 Internet-Draft Akamai 4 Intended status: Standards Track December 11, 2017 5 Expires: June 14, 2018 7 Header Compression for HTTP/QUIC 8 draft-bishop-quic-http-and-qpack-06 10 Abstract 12 HTTP/2 [RFC7540] uses HPACK [RFC7541] for header compression. 13 However, HPACK relies on the in-order message-based semantics of the 14 HTTP/2 framing layer in order to function. Messages can only be 15 successfully decoded if processed by the decoder in the same order as 16 generated by the encoder. This draft refines HPACK to loosen the 17 ordering requirements for use over QUIC [I-D.ietf-quic-transport]. 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 June 14, 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 (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. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. QPACK - Concepts . . . . . . . . . . . . . . . . . . . . . . 3 56 2.1. Changes to Static and Dynamic Tables . . . . . . . . . . 4 57 2.1.1. Dynamic Table State Synchronization . . . . . . . . . 4 58 2.2. Encoding Constraints . . . . . . . . . . . . . . . . . . 6 59 2.2.1. Permitted References . . . . . . . . . . . . . . . . 6 60 2.2.2. Header Table Size . . . . . . . . . . . . . . . . . . 6 61 3. Wire Format . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 3.1. Feedback Stream . . . . . . . . . . . . . . . . . . . . . 8 63 3.1.1. HEADERS_DONE . . . . . . . . . . . . . . . . . . . . 8 64 3.1.2. ACK_FLUSH . . . . . . . . . . . . . . . . . . . . . . 8 65 3.1.3. DROP . . . . . . . . . . . . . . . . . . . . . . . . 9 66 3.1.4. ACK_DROP . . . . . . . . . . . . . . . . . . . . . . 9 67 3.2. Checkpoint Streams . . . . . . . . . . . . . . . . . . . 9 68 3.2.1. INSERT . . . . . . . . . . . . . . . . . . . . . . . 10 69 3.2.2. TOUCH . . . . . . . . . . . . . . . . . . . . . . . . 11 70 3.3. Request Streams . . . . . . . . . . . . . . . . . . . . . 12 71 3.3.1. Indexed Header Field Representation . . . . . . . . . 12 72 3.3.2. Literal Header Field Representation . . . . . . . . . 12 73 4. Use in HTTP/QUIC . . . . . . . . . . . . . . . . . . . . . . 14 74 4.1. SETTING_QPACK_BLOCKING_PERMITTED . . . . . . . . . . . . 14 75 4.2. SETTING_QPACK_INITIAL_CHECKPOINT . . . . . . . . . . . . 14 76 5. Implementation trade-offs . . . . . . . . . . . . . . . . . . 15 77 5.1. Compression Efficiency versus Blocking Avoidance . . . . 15 78 5.2. Timely State Transitions versus Decoder Complexity . . . 15 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 80 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 81 7.1. Settings . . . . . . . . . . . . . . . . . . . . . . . . 16 82 7.2. Errors . . . . . . . . . . . . . . . . . . . . . . . . . 17 83 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 84 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 85 9.1. Normative References . . . . . . . . . . . . . . . . . . 18 86 9.2. Informative References . . . . . . . . . . . . . . . . . 18 87 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 89 1. Introduction 91 HPACK has a number of features that were intended to provide 92 performance advantages to HTTP/2, but which don't live well in an 93 out-of-order environment such as that provided by QUIC. 95 The largest challenge is the fact that elements are referenced by a 96 very fluid index. Not only is the index implicit when an item is 97 added to the header table, the index will change without notice as 98 other items are added to the header table. Static entries occupy the 99 first 61 values, followed by dynamic entries. A newly-added dynamic 100 entry would cause older dynamic entries to be evicted, and the 101 retained items are then renumbered beginning with 62. This means 102 that, without processing all preceding header sets, no index into the 103 dynamic table can be interpreted, and the index of a given entry 104 cannot be predicted. 106 Any solution to the above will almost certainly fall afoul of the 107 memory constraints the decompressor imposes. The automatic eviction 108 of entries is done based on the compressor's declared dynamic table 109 size, which MUST be less than the maximum permitted by the 110 decompressor (and relayed using an HTTP/2 SETTINGS value). 112 Further, streams in QUIC are lossy in the presence of stream resets. 113 While HTTP/2 (via TCP) guarantees the delivery of all previously-sent 114 data on a stream even if that stream is reset, QUIC does not 115 retransmit lost frames if a stream has been reset, and may discard 116 data which has not yet been delivered to the application. 118 Early versions of QPACK were small deltas of HPACK to introduce 119 order-resiliency. Recent versions depart from HPACK more 120 substantially to add resilience against reset message streams and 121 reduce the impact of head-of-line blocking. 123 In the following sections, this document proposes a successor to 124 HPACK which makes different trade-offs, enabling partial out-of-order 125 interpretation and bounded memory consumption with minimal head-of- 126 line blocking. None of the proposed improvements to HPACK (strongly- 127 typed fields, binary compression of common header syntax) are 128 currently included, but certainly could be. 130 1.1. Terminology 132 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 133 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 134 and "OPTIONAL" are to be interpreted as described in BCP 14, 135 [RFC2119] and indicate requirement levels for compliant 136 implementations. 138 2. QPACK - Concepts 140 HPACK combines header table modification and message header emission 141 in a single sequence of coded bytes. QPACK bifurcates these into 142 three channels: 144 o Connection-wide sets of table update instructions sent on non- 145 request streams 147 o Connection-wide feedback on stream and checkpoint state on a 148 single non-request stream 150 o Non-modifying instructions which use the current header table 151 state to encode message headers on request streams 153 Because the per-message instructions introduce no changes to the 154 header table state, no state is lost if these instructions are 155 discarded due to a stream reset. Because the updates to the header 156 table supply their own order controls (the checkpoint logic), they 157 can be processed in any order and therefore delivered as messages 158 using unidirectional QUIC streams. 160 2.1. Changes to Static and Dynamic Tables 162 QPACK uses two tables for associating header fields to indexes. The 163 static table is unchanged from [RFC7541]. Unlike in [RFC7541], the 164 tables are not concatenated, but are referenced separately. 166 The dynamic table is a map from index to header field. Indices are 167 arbitrary numbers between 1 and 2^27. Each insert instruction will 168 specify the index being modified. While any index MAY be chosen for 169 a new entry, smaller numbers will yield better compression 170 performance. 172 With decoder consent (see Section 4.1), it is possible for QPACK 173 instructions to arrive which reference indices which have not yet 174 been defined. Such instructions MUST wait until the index definition 175 has arrived. In order to guard against malicious peers, 176 implementations supporting blocking SHOULD impose a time limit and 177 treat expiration of the timer as a decoding error. 179 2.1.1. Dynamic Table State Synchronization 181 In order to ensure table consistency, all modifications of the header 182 table occur as separate messages rather than on request streams. 183 Request streams contain only indexed and literal header entries. 185 No entries are automatically evicted from the dynamic table. Size 186 management is purely the responsibility of the encoder, which MUST 187 NOT exceed the declared memory size of the decoder. 189 To simplify state management in the dynamic table, _checkpoints_ are 190 introduced. A checkpoint is used to track entries added to the 191 dynamic table and streams that reference those entries, rather than 192 maintaining the full state of which streams reference which table 193 entries. 195 Checkpoints are unordered and have an identifier which MUST be unique 196 among checkpoints which have not been dropped. Each checkpoint has a 197 unidirectional stream which begins with its identifier and contains a 198 series of updates associated with that checkpoint. These updates 199 SHOULD be processed as they arrive; it is not necessary (and might 200 not be desirable) to wait for all instructions associated with a 201 checkpoint to arrive before beginning to process it. 203 The feedback stream is used to relay state transitions to the peer. 204 For example, when a decoder is done processing a header block, it 205 signals this using the HEADERS_DONE message. The encoder uses this 206 information to track which checkpoints can be dropped. 208 2.1.1.1. Checkpoint Lifecycle 210 A checkpoint is created by opening a new checkpoint stream. This 211 places the checkpoint in the NEW state for both encoder and decoder. 212 The encoder typically has at least one checkpoint in the NEW state. 214 Flushing a checkpoint is a two-step operation. First, the checkpoint 215 stream is closed. At that time, the encoder's NEW checkpoint becomes 216 PENDING. The decoder moves its NEW checkpoint directly to LIVE and 217 responds with an ACK_FLUSH message on the feedback stream. When the 218 encoder receives this message, its PENDING checkpoint becomes LIVE. 220 Unused entries are evicted indirectly, by dropping checkpoints. 221 Before a checkpoint can be dropped, its state is changed to DYING. 222 Changing a checkpoint's state to DYING allows the checkpoint to age 223 out. This is a strictly internal state on the encoder, and not 224 visible to the decoder. A DYING checkpoint can be returned to LIVE 225 at the encoder's discretion if necessary. 227 The encoder can change a DYING checkpoint to DEAD (sending a DROP 228 instruction) when it is no longer referenced by any outstanding 229 header blocks. The encoder sends the DROP command to the decoder 230 when it declares a checkpoint DEAD. 232 To ensure consistency, the decoder drops the corresponding checkpoint 233 and responds with an ACK_DROP message only when it has fully received 234 all instructions the encoder has issued up to that point. The 235 encoder drops the DEAD checkpoint upon receipt of the ACK_DROP 236 message. 238 When a checkpoint is dropped by encoder or decoder, the table entries 239 it references are checked: if an entry is no longer referenced by any 240 checkpoint, the entry is evicted. 242 Dropping a checkpoint and the entries associated with it is not 243 limited to just the oldest checkpoint; any DYING checkpoint - as long 244 as state transition rules are followed - may be dropped. This 245 flexibility permits the encoder to use a number of strategies for 246 entry eviction. 248 As long as the maximum dynamic table size is observed, new 249 checkpoints can be created; no upper limit on the number of 250 checkpoints is specified. A well-balanced spread of checkpoints 251 permits the encoder to recycle entries effectively. 253 2.2. Encoding Constraints 255 2.2.1. Permitted References 257 When encoding headers on a request stream or referencing existing 258 entries in a checkpoint stream, an encoder MAY reference any static 259 table entry or any dynamic header table entry referenced by a LIVE 260 checkpoint. References to entries in NEW or PENDING checkpoints are 261 permitted only if the client has set 262 "SETTING_QPACK_BLOCKING_PERMITTED" (see Section 4.1). 264 If a decoder receives a reference to an empty slot in the dynamic 265 table but has not sent "SETTING_QPACK_BLOCKING_PERMITTED", this MUST 266 be treated as: 268 o A stream error of type "ERROR_QPACK_INVALID_REFERENCE" if on a 269 request stream 271 o A connection error of type "ERROR_QPACK_INVALID_REFERENCE" if on a 272 checkpoint stream 274 References to DYING checkpoints are possible by returning the 275 checkpoint to LIVE, but this is usually inadvisable. Table entries 276 contained only in a DEAD checkpoint can never be referenced. 278 2.2.2. Header Table Size 280 As in HPACK, the dynamic table is constrained to the maximum size 281 specified by the decoder. An attempt to add a header to the dynamic 282 table or to create a new checkpoint which causes it to exceed the 283 maximum size MUST be treated as an error by a decoder. To enable 284 encoders to reclaim space, encoders can drop old checkpoints (see 285 Section 2.1.1). 287 The total table size is calculated as follows: 289 o The size of each entry is calculated as in HPACK 291 o Each checkpoint that has not been removed, regardless of state, 292 consumes 64 bytes 294 2.2.2.1. Table Size Changes 296 HTTP/QUIC prohibits mid-stream changes of settings. As a result, 297 only one table size change is possible: From the value a client 298 assumes during the 0-RTT flight to the actual value included in the 299 server's SETTINGS frame. The assumed value is required to be either 300 a server's previous value or zero. A server whose configuration has 301 recently changed MAY overlook inadvertent violations of its maximum 302 table size during the first round-trip. 304 In the case that the value has increased, either from zero to a non- 305 zero value or from the cached value to a higher value, no action is 306 required by the client. The encoder can simply begin using the 307 additional space. In the case that the value has decreased, the 308 encoder MUST move checkpoints to the DYING state which, upon removal, 309 would bring the table within the required size. 311 Regardless of changes to header table size, the encoder MUST NOT 312 create new checkpoints or add entries to the table which would result 313 in a size greater than the maximum permitted. This can imply that no 314 additions are permitted while waiting for old checkpoints to 315 complete. 317 3. Wire Format 319 QPACK instructions occur on three stream types, each of which uses a 320 separate instruction space. 322 The feedback stream is a bidirectional server-initiated stream used 323 for acknowledgement of actions and checkpoint state management. 324 Checkpoint streams are unidirectional streams from encoder to 325 decoder. Both types of streams consist of a series of QPACK 326 instructions with no message boundaries, preceded by a stream header 327 for checkpoint streams. 329 Finally, the contents of HEADERS and PUSH_PROMISE frames on request 330 streams reference the QPACK table state. 332 This section describes the instructions which are possible on each 333 stream type. 335 3.1. Feedback Stream 337 Stream 1, the first server-initiated bidirectional stream, is used as 338 the feedback stream, since the client does not need to begin sending 339 data on this stream until it has received data from the server. 341 This stream is critical to the HTTP/QUIC connection, and carries a 342 stream of the instructions defined in this section. Data on this 343 stream SHOULD be processed as soon as it arrives. 345 3.1.1. HEADERS_DONE 347 When the decoder has processed a frame containing header emission 348 instructions (Section 3.3, HEADERS or PUSH_PROMISE frames) on a 349 stream, it MUST emit a HEADERS_DONE message on the feedback stream. 350 The same Stream ID can be identified multiple times, as multiple 351 header-containing blocks can be sent on a single stream in the case 352 of intermediate responses, trailers, pushed requests, etc. 354 Since header frames on a request stream are received and processed in 355 order, this gives the encoder precise feedback on which header blocks 356 within a stream have been fully processed. This information can then 357 be used to correctly track outstanding stream references to 358 checkpoints. 360 0 1 2 3 4 5 6 7 361 +---+---+---+---+---+---+---+---+ 362 | 1 | Stream ID (7+) | 363 +---+---------------------------+ 365 HEADERS_DONE instruction 367 3.1.2. ACK_FLUSH 369 When the decoder has finished processing all instructions that make 370 up a checkpoint, it MUST indicate successful processing to the 371 encoder by emitting an ACK_FLUSH instruction on the feedback stream. 373 Upon emitting an ACK_FLUSH, the checkpoint transitions from NEW to 374 LIVE on the decoder. Upon receipt of an ACK_FLUSH, the checkpoint 375 transitions from PENDING to LIVE on the encoder. 377 0 1 2 3 4 5 6 7 378 +---+---+---+---+---+---+---+---+ 379 | 0 | 1 | 0 | Checkpoint ID (5+)| 380 +---+---------------------------+ 382 ACK_FLUSH instruction 384 3.1.3. DROP 386 When an encoder has received sufficient HEADERS_DONE messages to know 387 that a DYING checkpoint has no outstanding references, it emits a 388 DROP instruction to inform the decoder that the checkpoint can be 389 removed. Upon sending a DROP instruction, a DYING checkpoint becomes 390 DEAD. The DROP instruction also includes the ID of the encoder's 391 greatest checkpoint ID so far. 393 Upon receiving a DROP instruction, if all checkpoints up to and 394 including the Most Recent ID have been fully processed (transitioned 395 from NEW to LIVE), the identified LIVE checkpoint is removed from the 396 decoder state and an ACK_DROP instruction is emitted. Otherwise, the 397 decoder saves the DROP instruction until other checkpoints become 398 LIVE. 400 0 1 2 3 4 5 6 7 401 +---+---+---+---+---+---+---+---+ 402 | 0 | 1 | 0 | Checkpoint ID (5+)| 403 +---+---+---+-------------------+ 404 | Most Recent ID (8+) | 405 +-------------------------------+ 407 DROP instruction 409 3.1.4. ACK_DROP 411 When a decoder receives a DROP instruction, it removes the referenced 412 checkpoint from its state and clears any table entries which were 413 referenced only by that checkpoint. It then emits an ACK_DROP 414 instruction. When an encoder receives an ACK_DROP instruction, it 415 removes the corresponding DEAD checkpoint from its state and clears 416 any table entries which were referenced only by that checkpoint. 418 0 1 2 3 4 5 6 7 419 +---+---+---+---+---+---+---+---+ 420 | 0 | 1 | 1 | Checkpoint ID (5+)| 421 +---+---+---+-------------------+ 423 ACK_DROP instruction 425 3.2. Checkpoint Streams 427 Each checkpoint stream indicates the creation and content of a NEW 428 checkpoint. When the encoder has finished writing all data on the 429 stream, it changes the checkpoint to PENDING. When the decoder has 430 received and processed all data on the stream, it changes the 431 checkpoint to LIVE and generates an ACK_FLUSH. 433 Unidirectional streams in HTTP/QUIC begin with a stream header 434 indicating the nature of the stream content; the identifier for QPACK 435 checkpoints is 0x4B. 437 *Note to readers:* This header does not currently exist in the 438 main draft, but has manifested in several PRs, and would need to 439 be resurrected. 441 Following the stream header, a checkpoint stream contains its 442 checkpoint ID as an 8-bit prefix integer. The remainder of the 443 stream's data consists of the instructions defined in this section. 444 Checkpoint IDs begin at zero and increment by one for each new 445 checkpoint. 447 Data on checkpoint streams SHOULD be processed as soon as it arrives. 448 If multiple checkpoint streams are received at once, a decoder SHOULD 449 process data on each as it arrives if it has sent 450 "SETTINGS_QPACK_BLOCKING_PERMITTED", but MAY process checkpoint 451 streams one at a time. 453 3.2.1. INSERT 455 An addition to the dynamic table starts with the '1' one-bit pattern, 456 followed by the new index of the header represented as an integer 457 with a 7-bit prefix. The decoder adds the supplied header to the 458 checkpoint currently being processed, which is in the NEW state. 460 If the header field name matches the header field name of an entry 461 stored in the static table or the dynamic table, the header field 462 name can be represented using the index of that entry. In this case, 463 the "S" bit indicates whether the reference is to the static (S=1) or 464 dynamic (S=0) table and the index of the entry is represented as an 465 integer with an 7-bit prefix (see Section 5.1 of [RFC7541]). This 466 value is always non-zero. 468 If an INSERT instruction uses an existing dynamic table entry for the 469 name of an entry being added to the NEW checkpoint, both the existing 470 entry and the new entry are referenced by the NEW checkpoint. 472 0 1 2 3 4 5 6 7 473 +---+---+---+---+---+---+---+---+ 474 | 1 | New Index (7+) | 475 +---+---------------------------+ 476 | S | Name Index (7+) | 477 +---+---------------------------+ 478 | H | Value Length (7+) | 479 +---+---------------------------+ 480 | Value String (Length octets) | 481 +-------------------------------+ 483 INSERT instruction -- Indexed Name 485 Otherwise, the header field name is represented as a string literal 486 (see Section 5.2 of [RFC7541]). A value 0 is used in place of the 487 table reference, followed by the header field name. 489 0 1 2 3 4 5 6 7 490 +---+---+---+---+---+---+---+---+ 491 | 1 | New Index (7+) | 492 +---+---------------------------+ 493 | 0 | 494 +---+---------------------------+ 495 | H | Name Length (7+) | 496 +---+---------------------------+ 497 | Name String (Length octets) | 498 +---+---------------------------+ 499 | H | Value Length (7+) | 500 +---+---------------------------+ 501 | Value String (Length octets) | 502 +-------------------------------+ 504 INSERT instruction -- New Name 506 Either form of header field name representation is followed by the 507 header field value represented as a string literal (see Section 5.2 508 of [RFC7541]). 510 An encoder MUST NOT attempt to place a value at an index not known to 511 be vacant. A decoder MUST treat the attempt to insert into an 512 occupied slot as a fatal error. 514 3.2.2. TOUCH 516 This instruction is emitted to link a NEW checkpoint to an existing 517 header table entry created by a previous checkpoint. This causes the 518 entry not to be removed from the table so long as the current 519 checkpoint is alive. 521 0 1 2 3 4 5 6 7 522 +---+---+---+---+---+---+---+---+ 523 | 0 | Index (7+) | 524 +---+---------------------------+ 526 Indexed Header Field 528 The encoder SHOULD NOT issue multiple TOUCH commands for the same 529 entry in the context of the same NEW checkpoint. If a non-existent 530 index is specified, the decoder MUST treat is as an error. 532 3.3. Request Streams 534 Frames which carry HTTP message headers encode them using the 535 following instructions: 537 3.3.1. Indexed Header Field Representation 539 An indexed header field representation identifies an entry in either 540 the static table or the dynamic table and causes that header field to 541 be added to the decoded header list, as described in Section 3.2 of 542 [RFC7541]. 544 0 1 2 3 4 5 6 7 545 +---+---+---+---+---+---+---+---+ 546 | 1 | S | Index (6+) | 547 +---+---+-----------------------+ 549 Indexed Header Field 551 An indexed header field starts with the '1' 1-bit pattern, followed 552 by the "S" bit indicating whether the reference is into the static 553 (S=1) or dynamic (S=0) table. Finally, the index of the matching 554 header field is represented as an integer with a 6-bit prefix (see 555 Section 5.1 of [RFC7541]). 557 The index value of 0 is not used. It MUST be treated as a decoding 558 error if found in an indexed header field representation. 560 3.3.2. Literal Header Field Representation 562 A literal header field representation starts with the '0' 1-bit 563 pattern and causes a header field to be added the decoded header 564 list. 566 The second bit, 'N', indicates whether an intermediary is permitted 567 to add this header to the dynamic header table on subsequent hops. 568 When the 'N' bit is set, the encoded header MUST always be encoded 569 with this specific literal representation. In particular, when a 570 peer sends a header field that it received represented as a literal 571 header field with the 'N' bit set, it MUST use the same 572 representation to forward this header field. This bit is intended 573 for protecting header field values that are not to be put at risk by 574 compressing them (see Section 7.1 of [RFC7541] for more details). 576 If the header field name matches the header field name of an entry 577 stored in the static table or the dynamic table, the header field 578 name can be represented using the index of that entry. In this case, 579 the "S" bit indicates whether the reference is to the static (S=1) or 580 dynamic (S=0) table and the index of the entry is represented as an 581 integer with an 5-bit prefix (see Section 5.1 of [RFC7541]). This 582 value is always non-zero. 584 0 1 2 3 4 5 6 7 585 +---+---+---+---+---+---+---+---+ 586 | 0 | N | S | Name Index (5+) | 587 +---+---+---+-------------------+ 588 | H | Value Length (7+) | 589 +---+---------------------------+ 590 | Value String (Length octets) | 591 +-------------------------------+ 593 Literal Header Field -- Indexed Name 595 Otherwise, the header field name is represented as a string literal 596 (see Section 5.2 of [RFC7541]). A value 0 is used in place of the 597 6-bit index, followed by the header field name. 599 0 1 2 3 4 5 6 7 600 +---+---+---+---+---+---+---+---+ 601 | 0 | N | 0 | 602 +---+---+-----------------------+ 603 | H | Name Length (7+) | 604 +---+---------------------------+ 605 | Name String (Length octets) | 606 +---+---------------------------+ 607 | H | Value Length (7+) | 608 +---+---------------------------+ 609 | Value String (Length octets) | 610 +-------------------------------+ 612 Literal Header Field -- Literal Name 614 Either form of header field name representation is followed by the 615 header field value represented as a string literal (see Section 5.2 616 of [RFC7541]). 618 4. Use in HTTP/QUIC 620 HTTP/QUIC [I-D.ietf-quic-http] currently retains the HPACK encoder/ 621 decoder from HTTP/2, using a Sequence number to enforce ordering. 622 Using QPACK instead would entail the following changes: 624 o Header Blocks consist of QPACK data instead of HPACK data 626 o Just as unidirectional push streams have a stream header 627 identifying their Push ID, a header will need to be added to 628 differentiate checkpoint streams from pushes 630 o Stream 2 is reserved for the Feedback Stream 632 A HEADERS or PUSH_PROMISE frame MAY contain an arbitrary number of 633 QPACK instructions, but QPACK instructions SHOULD NOT cross a 634 boundary between successive HEADERS frames. A partial HEADERS or 635 PUSH_PROMISE frame MAY be processed upon arrival and the resulting 636 partial header set emitted or buffered according to implementation 637 requirements. 639 4.1. SETTING_QPACK_BLOCKING_PERMITTED 641 An HTTP/QUIC implementation can trade off the complexity of its QPACK 642 decoder against compression efficiency by permitting the peer's 643 compressor to reference unacknowledged entries. In the case of loss 644 on a checkpoint stream, such references might cause the processing of 645 request streams or other checkpoint streams to block, waiting for the 646 arrival of missing data. 648 If the decoder permits the encoder to make blocking references, it 649 sets "SETTING_QPACK_BLOCKING_PERMITTED" (0xSETTING-TBD1) to true. In 650 the default setting, false, the encoder MUST NOT encode a header 651 using a format that might block. 653 4.2. SETTING_QPACK_INITIAL_CHECKPOINT 655 An HTTP/QUIC implementation MAY include the 656 "SETTING_QPACK_INITIAL_CHECKPOINT" (0xSETTING_TBD2) setting, 657 containing the full serialization of an initial checkpoint stream's 658 data. If present, this setting MUST be fully processed by the peer 659 before decoding any checkpoint streams or header frames on request 660 streams. 662 The checkpoint defined by this setting is considered LIVE by both the 663 encoder and the decoder from the beginning of the connection. The 664 decoder does not need to send an ACK_FLUSH message confirming receipt 665 of this setting. 667 5. Implementation trade-offs 669 This document specifies a means for the encoder to express the 670 choices it made while encoding, but intentionally does not mandate 671 what those choices should be. In this section, potential areas for 672 implementation tuning are explored. 674 5.1. Compression Efficiency versus Blocking Avoidance 676 If blocking references are permitted, they will block if the frame 677 containing the entry definition is lost or delayed. Encoders MAY 678 choose to trade off compression efficiency and avoid blocking by 679 using literal instructions rather than referencing the dynamic table 680 until the insertion is believed to be complete. 682 The most efficient compression algorithm will reference a table entry 683 whenever it exists in the table, but risks blocking when subject to 684 packet loss or reordering. The most conservative algorithm will 685 always emit literals to guarantee that no blocking will ever occur. 686 Most implementations will choose a balance between these two 687 extremes. 689 Better efficiency while being similarly conservative can be achieved 690 by permitting references to table entries only once these entries are 691 confirmed to be present in the table. More optimization can be 692 achieved when the reference is known to be in the same packet as the 693 definition. 695 Increases in efficiency can be achieved by assuming greater risk of 696 blocking - implementations might choose a particular balance, or 697 adjust their aggressiveness based on observed network 698 characteristics. 700 Since it is possible to insert header values without emitting them on 701 a stream, an encoder MAY also proactively insert header values which 702 it believes will be needed on future requests, at the cost of reduced 703 compression efficiency for incorrect predictions. 705 The ability to split updates to the header table into discrete 706 checkpoints reduces the possibility for head-of-line blocking within 707 the checkpoint streams. Implementations SHOULD limit the size of 708 checkpoints to avoid head-of-line blocking within these messages. 710 5.2. Timely State Transitions versus Decoder Complexity 712 Anything which prevent checkpoints from transitioning from DYING to 713 DEAD can prevent the encoder from adding any new entries due to the 714 maximum table size. This does not block the encoder from continuing 715 to make requests, but could sharply limit compression performance. 716 Encoders would be well-served to begin moving checkpoint to DYING in 717 advance of encountering the table maximum. Decoders SHOULD be prompt 718 about emitting STREAM_DONE and ACK_DROP instructions to enable the 719 encoder to recover the table space. 721 Similarly, for decoders which prohibit blocking references, delaying 722 the transition of a checkpoint from PENDING to LIVE will degrade 723 compression performance. Decoders SHOULD consume checkpoint data and 724 emit ACK_FLUSH frames as promptly as possible. 726 Since decoders cannot safely drop old checkpoints until they have 727 fully processed any checkpoints which might have been open 728 concurrently, a long-lived checkpoint can delay the completion of an 729 ACK_DROP. Encoders SHOULD flush all NEW checkpoints as soon as 730 feasible after issuing a DROP instruction. 732 6. Security Considerations 734 A malicious encoder might attempt to consume a large amount of space 735 on the decoder, but as each decoder chooses how much memory to allow 736 the peer to consume, this state is bounded. 738 A malicious encoder might also send blocking references to entries 739 which will never actually be defined. This attack is comparable to a 740 "slow loris" attack in which a request is delivered very slowly in an 741 attempt to consume resources on the server. Similar mitigations 742 (request timers, etc.) SHOULD be employed to guard against such 743 attacks. 745 7. IANA Considerations 747 This document registers two settings and one error code with the 748 corresponding HTTP/QUIC registries. 750 7.1. Settings 752 This document registers two entries in the "HTTP/QUIC Settings" 753 registry established by [I-D.ietf-quic-http]. 755 Setting Name: SETTING_QPACK_BLOCKING_PERMITTED 757 Code: 0xSETTING-TBD1 759 Specification: Section 4.1 761 and 762 Setting Name: SETTING_QPACK_INITIAL_CHECKPOINT 764 Code: 0xSETTING-TBD2 766 Specification: Section 4.2 768 7.2. Errors 770 This document registers one error code in the "HTTP/QUIC Error Code" 771 registry established by [I-D.ietf-quic-http]. 773 Error name: ERROR_QPACK_INVALID_REFERENCE 775 Code: 0xERROR-TBD 777 Description: A blocking reference was received by a decoder which 778 did not permit it 780 Specification: Section 2.2.1 782 8. Acknowledgements 784 This draft draws heavily on the text of [RFC7541], and adopts (with 785 adaptation) the checkpoint model from [QMIN]. The direct and 786 indirect input of those authors is gratefully acknowledged, as well 787 as ideas gleefully stolen from: 789 o Jana Iyengar 791 o Patrick McManus 793 o Martin Thomson 795 o Charles 'Buck' Krasic 797 o Kyle Rose 799 o Alan Frindell 801 A substantial portion of Mike's work on this draft was supported by 802 Microsoft during his employment there. 804 9. References 805 9.1. Normative References 807 [I-D.ietf-quic-http] 808 Bishop, M., "Hypertext Transfer Protocol (HTTP) over 809 QUIC", draft-ietf-quic-http-07 (work in progress), October 810 2017. 812 [I-D.ietf-quic-transport] 813 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 814 and Secure Transport", draft-ietf-quic-transport-07 (work 815 in progress), October 2017. 817 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 818 Requirement Levels", BCP 14, RFC 2119, 819 DOI 10.17487/RFC2119, March 1997, 820 . 822 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 823 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 824 DOI 10.17487/RFC7540, May 2015, 825 . 827 [RFC7541] Peon, R. and H. Ruellan, "HPACK: Header Compression for 828 HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, 829 . 831 9.2. Informative References 833 [QMIN] Tikhonov, D., "QMIN: Header Compression for QUIC", draft- 834 tikhonov-quic-qmin-00 (work in progress), November 2017. 836 Author's Address 838 Mike Bishop 839 Akamai 841 Email: mbishop@evequefou.be