idnits 2.17.1 draft-bishop-quic-http-and-qpack-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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 154 characters in excess of 72. ** The abstract seems to contain references ([I-D.shade-quic-http2-mapping], [RFC7540], [RFC7541], [I-D.hamilton-quic-transport-protocol]), 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 (November 15, 2016) is 2718 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 (-01) exists of draft-bishop-httpbis-extended-settings-00 ** Downref: Normative reference to an Informational draft: draft-bishop-httpbis-extended-settings (ref. 'I-D.bishop-httpbis-extended-settings') ** Downref: Normative reference to an Experimental draft: draft-hamilton-quic-transport-protocol (ref. 'I-D.hamilton-quic-transport-protocol') ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) Summary: 7 errors (**), 0 flaws (~~), 3 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 Microsoft 4 Intended status: Standards Track November 15, 2016 5 Expires: May 19, 2017 7 HTTP over QUIC - Mapping and Header Compression 8 draft-bishop-quic-http-and-qpack-00 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 receiver in the same order 16 as generated by the sender. This draft refines HPACK to loosen the 17 ordering requirements for use over QUIC 18 [I-D.hamilton-quic-transport-protocol] and describes changes to 19 [I-D.shade-quic-http2-mapping] to leverage the new compression. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on May 19, 2017. 38 Copyright Notice 40 Copyright (c) 2016 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. QPACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.1. Changes to Static and Dynamic Tables . . . . . . . . . . 3 59 2.1.1. Dynamic table state synchronization . . . . . . . . . 4 60 2.2. Changes to Binary Format . . . . . . . . . . . . . . . . 5 61 2.2.1. Literal Header Field Representation . . . . . . . . . 5 62 2.2.2. Deletion . . . . . . . . . . . . . . . . . . . . . . 6 63 2.2.3. The QPACK-ACK frame . . . . . . . . . . . . . . . . . 7 64 3. HTTP over QUIC Mapping . . . . . . . . . . . . . . . . . . . 7 65 3.1. Stream usage . . . . . . . . . . . . . . . . . . . . . . 8 66 3.2. On-Stream Framing Definition . . . . . . . . . . . . . . 8 67 3.2.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . 9 68 3.2.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . 9 69 3.2.3. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . 10 70 3.2.4. PRIORITY . . . . . . . . . . . . . . . . . . . . . . 10 71 3.2.5. SETTINGS . . . . . . . . . . . . . . . . . . . . . . 11 72 3.2.6. Other frames not mentioned . . . . . . . . . . . . . 11 73 3.3. HTTP Message Exchanges . . . . . . . . . . . . . . . . . 11 74 4. Performance Considerations . . . . . . . . . . . . . . . . . 13 75 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 80 8.2. Informative References . . . . . . . . . . . . . . . . . 14 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 83 1. Introduction 85 HPACK has a number of features that were intended to provide 86 performance advantages to HTTP/2, but which don't live well in an 87 out-of-order environment such as that provided by QUIC. 89 The largest challenge is the fact that elements are referenced by a 90 very fluid index. Not only is the index implicit when an item is 91 added to the header table, the index will change without notice as 92 other items are added to the header table. Static entries occupy the 93 first 61 values, followed by dynamic entries. A newly-added dynamic 94 entry would cause older dynamic entries to be evicted, and the 95 retained items are then renumbered beginning with 62. This means 96 that, without processing all preceding header sets, no index into the 97 dynamic table can be interpreted, and the index of a given entry 98 cannot be predicted. 100 Any solution to the above will almost certainly fall afoul of the 101 memory constraints the decompressor imposes. The automatic eviction 102 of entries is done based on the compressor's declared dynamic table 103 size, which MUST be less than the maximum permitted by the 104 decompressor (and relayed using an HTTP/2 SETTINGS value). 106 In the following sections, this document proposes a new version of 107 HPACK which makes different trade-offs, enabling out-of-order 108 interpretation and bounded memory consumption with minimal head-of- 109 line blocking. None of the proposed improvements to HPACK (strongly- 110 typed fields, binary compression of common header syntax) are 111 currently included, but certainly could be. 113 1.1. Terminology 115 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 116 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 117 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 118 [RFC2119] and indicate requirement levels for compliant STuPiD 119 implementations. 121 2. QPACK 123 2.1. Changes to Static and Dynamic Tables 125 QPACK uses two tables for associating header fields to indexes. The 126 static table is unchanged from [RFC7541]. 128 The dynamic table is a map from index to header field. Indices are 129 arbitrary numbers greater than the last index of the static table. 130 Each insert instruction will specify the index being modified. While 131 any index MAY be chosen for a new entry, smaller numbers will yield 132 better compression performance. Once an index has been assigned, its 133 value is immutable for the lifetime of that dynamic table. 135 In order to improve resiliency to reordering, an encoder MAY send 136 multiple insert instructions for the same value to the same index. 137 However, any attempt to insert a different value to an occupied index 138 is a fatal error. 140 The dynamic table is still constrained to the size specified by the 141 receiver. An attempt to add a header to the dynamic table which 142 causes it to exceed the maximum size MUST be treated as an error by a 143 decoder. 145 Because it is possible for QPACK frames to arrive which reference 146 indices which have not yet been defined, such frames MUST wait until 147 another frame has arrived and defined the index. In order to guard 148 against malicious senders, implementations SHOULD impose a time limit 149 and treat expiration of the timer as a decoding error. However, if 150 the implementation chooses not to abort the connection, the remainder 151 of the header block MUST be decoded and the output discarded. 153 2.1.1. Dynamic table state synchronization 155 No entries are evicted from the dynamic table. Size management is 156 purely the responsibility of the sender, which MUST NOT exceed the 157 declared memory size of the receiver. 159 Both sender and receiver will maintain a count of references to the 160 indexed entry. This count includes: 162 o Insertions to the field, both the initial and any redundant 163 indexed literal emissions. 165 o Literal values which use the indexed entry to provide the header 166 name 168 o Explicit emissions of the indexed value 170 The sender MUST consider memory as committed beginning with the first 171 time the indexed entry is assigned. An encoder MAY repeat the 172 insertion instruction in other frames rather than leveraging the 173 index while it waits for the frame to arrive. 175 When the sender wishes to delete an inserted value, it flows through 176 the following set of states: 178 1. *Delete requested.* The sender emits a delete instruction 179 including the terminal value of the reference counter. The 180 sender MUST NOT reference the entry in any subsequent frame until 181 this state machine has completed and MUST continue to include the 182 entry in its calculation of consumed memory. 184 2. *Delete pending.* The receiver receives the delete instruction 185 and compares the sender's counter with its own. If the 186 receiver's counter is less than the sender's, it stores the 187 sender's counter and waits for other QPACK frames to arrive. 189 3. *Delete acknowledged.* The receiver has received all QPACK frames 190 which reference the deleted value, and can safely delete the 191 entry. The receiver SHOULD promptly emit a QPACK-ACK frame, but 192 MAY delay briefly waiting for other pending deletes as well. 194 4. *Delete completed.* When the sender receives a QPACK-ACK frame 195 acknowledging the delete, it no longer counts the size of the 196 deleted entry against the table size and MAY emit insert 197 instructions for the field with a new value. 199 The decoder can receive a delete instruction for a vacant table 200 entry. A decoder MUST NOT consider this to be an error, but MUST 201 handle the delete as usual even while waiting for the definition to 202 arrive. 204 2.2. Changes to Binary Format 206 2.2.1. Literal Header Field Representation 208 (This section replaces [RFC7541], Section 6.2.1.) 210 A literal header field with indexing representation results in 211 inserting a header field to the decoded header list and inserting it 212 as a new entry into the dynamic table. 214 0 1 2 3 4 5 6 7 215 +---+---+---+---+---+---+---+---+ 216 | 0 | 1 | New Index (6+) | 217 +---+---+-----------------------+ 218 | Name Index (8+) | 219 +---+---------------------------+ 220 | H | Value Length (7+) | 221 +---+---------------------------+ 222 | Value String (Length octets) | 223 +-------------------------------+ 225 Literal Header Field with Indexing -- Indexed Name 227 0 1 2 3 4 5 6 7 228 +---+---+---+---+---+---+---+---+ 229 | 0 | 1 | New Index (6+) | 230 +---+---+-----------------------+ 231 | 0 | 232 +---+---+-----------------------+ 233 | H | Name Length (7+) | 234 +---+---------------------------+ 235 | Name String (Length octets) | 236 +---+---------------------------+ 237 | H | Value Length (7+) | 238 +---+---------------------------+ 239 | Value String (Length octets) | 240 +-------------------------------+ 242 Literal Header Field with Indexing -- New Name 244 A literal header field with incremental indexing representation 245 starts with the '01' 2-bit pattern, followed by the new index of the 246 header represented as an integer with a 6-bit prefix. This value is 247 always greater than the number of entries in the static table. 249 If the header field name matches the header field name of an entry 250 stored in the static table or the dynamic table, the header field 251 name can be represented using the index of that entry. In this case, 252 the index of the entry is represented as an integer with an 8-bit 253 prefix (see Section 5.1 of [RFC7231]). This value is always non- 254 zero. 256 Otherwise, the header field name is represented as a string literal 257 (see Section 5.2 of [RFC7231]). A value 0 is used in place of the 258 8-bit index, followed by the header field name. 260 Either form of header field name representation is followed by the 261 header field value represented as a string literal (see Section 5.2). 263 An encoder MUST NOT attempt to place a value at an index not known to 264 be vacant. An encoder MAY insert the same value to the same vacant 265 slot multiple times in different frames, to reduce the risk of 266 blocking from out-of-order frame interpretation. However, a decoder 267 MUST treat the attempt to insert a different header field into an 268 occupied slot as a fatal error. 270 2.2.2. Deletion 272 (This section replaces [RFC7541], Section 6.2.3.) 273 *DISCUSS:* I stole the never-indexed instruction code to avoid 274 renumbering _all_ the instructions to fit a new one. If we think we 275 still need this in QUIC, we'll have to do the renumbering later. 277 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 0 | 0 | 0 | 1 | RefCount (4+) | +---+---+---+---+---------------+ | Index (8+) | +-------------------------------+ ~~~~~~~~~~ 279 Header Field Deletion 281 The sender may delete an entry in the dynamic header table at any 282 time in order to stay below the receiver's declared memory boundary. 283 This instruction tells the receiver that they should prepare to 284 delete the specified entry after all preceding frames referencing it 285 have been received. The delete instruction includes the count of 286 such frames to facilitate the receiver's garbage collection process. 288 2.2.3. The QPACK-ACK frame 290 Each peer MUST periodically emit a QPACK-ACK frame (0xTBD) on QUIC 291 stream 3 to reflect the current state of its header table. A peer 292 MAY omit sending a new QPACK-ACK frame if the dynamic table has not 293 changed since the last frame. 295 The QPACK-ACK frame defines no flags and consists of a bitmap. The 296 first bit in the bitmap reflects the first index after the static 297 table (currently 62), and each successive bit indicates the next 298 integer value. Each bit MUST be set if the indexed entry has had a 299 delete complete since the preceding QUIC frame and MUST be unset 300 otherwise. Indices beyond the end of the QPACK-ACK frame are assumed 301 to be unset. 303 Upon receipt, an encoder uses the table to confirm which items have 304 been deleted. At this point, the space can be recovered by the 305 encoder and the encoder can safely reuse the index for future 306 insertions. 308 3. HTTP over QUIC Mapping 310 [I-D.shade-quic-http2-mapping] refers to QUIC Stream 3 as carrying 311 "headers," but more accurately, it carries a nearly-complete HTTP/2 312 session, complete with framing and multiplexing. The mapping deletes 313 certain elements of HTTP/2's framing layer which can be delegated to 314 the QUIC transport layer. 316 This was done in large part for expediency, reusing HTTP/2 code in 317 place anywhere no QUIC-specific approach had yet been added. A 318 primary driver of this is the need for in-order reliable delivery of 319 frames carrying HPACK data (HEADERS, CONTINUATION, PUSH_PROMISE). 321 While the ability to reuse HTTP/2 framing is useful, the double-mux 322 layer is unwieldy and has proved unpopular in the working group. 323 This section presents an alternate mapping preserving some HTTP/2 324 code, but delegating all multiplexing to the QUIC layer. 326 QPACK would permit header data to be on-stream with the request/ 327 response bodies, but some framing is still required. It would be 328 possible (and perhaps desirable) to introduce a simplified version of 329 HTTP/2's framing on each QUIC stream. 331 3.1. Stream usage 333 In both QUIC and HTTP/2, odd-numbered streams are client-initiated, 334 while even-numbered streams are server-initiated. A single HTTP 335 transaction spans two streams, differentiated by the next stream bit. 336 This means that the client's first request occurs on QUIC streams 5 337 and 7, the second on stream 9 and 11, and so on. This amounts to the 338 second least-significant bit differentiating the two streams in a 339 request. 341 The payload of each frame type is unmodified from HTTP/2 unless 342 otherwise noted. Frames which would be sent on stream zero in HTTP/2 343 are sent on QUIC stream 3. 345 Because stream creation does not depend on particular frames, the 346 requirement that a stream begin only with HEADERS is omitted. 348 The second stream is used to carry any message payload, eliminating 349 the DATA frame. The first stream is the request control stream and 350 is used to carry all other frames which would have been on-stream in 351 HTTP/2. 353 3.2. On-Stream Framing Definition 355 Many framing concepts from HTTP/2 can be elided away on QUIC, because 356 the transport deals with them. Because these frames would already be 357 on a stream, they can omit the stream number. Because the frames do 358 not block multiplexing (QUIC's multiplexing occurs below this layer), 359 the support for variable-maximum-length packets can be removed. 360 Because stream termination is handled by QUIC, an END_STREAM flag is 361 not required. 363 On QUIC streams other than Stream 1, the general frame format is as 364 follows: 366 0 1 2 3 4 5 6 7 367 +---+---+---+---+---+---+---+---+ 368 | Length (16) | 369 | | 370 +---+---+---+---+---+---+---+---+ 371 | Type (8) | 372 +---+---+---+---+---+---+---+---+ 373 | Flags (8) | 374 +---+---+---+---+---+---+---+---+ 375 | Frame Payload ... 376 +---+---+---+---+---+---+---+---+ 378 HTTP/QUIC frame format 380 The fields are defined as in [RFC7540]. The frames currently defined 381 are described in this section: 383 3.2.1. DATA 385 DATA frames (type=0x0) do not exist. 387 3.2.2. HEADERS 389 The HEADERS frame (type=0x1) is used to carry part of a header set, 390 compressed using QPACK ({QPACK}). The PRIORITY-equivalent regions 391 have been removed, since a stream MAY begin with a PRIORITY frame and 392 the size of the QUIC stream format requires changes to how these 393 fields are handled. 395 Padding MUST NOT be used. The flags defined are: 397 o End Header Block (0x4): This frame concludes a header block. 399 The next frame on the same stream after a HEADERS frame without the 400 EHB flag set MUST be another HEADERS frame. A receiver MUST treat 401 the receipt of any other type of frame as a stream error. (Note that 402 QUIC can intersperse data from other streams between frames, or even 403 during transmission of frames, so multiplexing is not blocked by this 404 requirement.) 406 A full header block is contained in a sequence of zero or more 407 HEADERS frames without EHB set, followed by a HEADERS frame with EHB 408 set. 410 HEADERS frames from various streams may be processed by the QPACK 411 decoder in any order, completely or partially. It is not necessary 412 to withhold decoding results until the end of the header block has 413 arrived. However, depending on the contents, the processing of one 414 frame might depend on other QPACK frames. The results of decoding 415 MUST be emitted in the same order as the HEADERS frames were placed 416 on the stream. 418 3.2.3. PUSH_PROMISE 420 The PUSH_PROMISE frame (type=0x02) is used to carry a request header 421 set from server to client, as in HTTP/2. It contains the same flags 422 as HEADERS. 424 The payload contains a QPACK headers block encoding the request whose 425 response is promised, preceded by a 32-bit Stream ID indicating the 426 QUIC stream on which the response headers will be sent. (The 427 response body stream is implied by the headers stream, as defined in 428 Section 3.1.) 430 *TODO:* QUIC stream space may be enlarged; would need to redefine 431 Promised Stream field in this case. 433 3.2.4. PRIORITY 435 The PRIORITY frame (type=0x2) specifies the sender-advised priority 436 of a stream and is sent on Stream 3. It can refer to a stream in any 437 state, including idle or closed streams. 439 +---------------------------------------------------------------+ 440 | Prioritized Stream (32) | 441 +---------------------------------------------------------------+ 442 | Dependent Stream (32) | 443 +---------------+-----------------------------------------------+ 444 | Weight (8) | 445 +---------------+ 447 PRIORITY Frame Payload 449 The payload of a PRIORITY frame contains the following fields: 451 Prioritized Stream: The 32-bit stream identifier for the stream 452 whose priority is being modified. 454 Stream Dependency: 455 :The 32-bit stream identifier for the stream that this stream depends 456 on. 458 Weight: :An unsigned 8-bit integer representing a priority weight for 459 the stream (see Section 5.3). Add one to the value to obtain a 460 weight between 1 and 256. 462 The PRIORITY frame defines one flag: 464 EXCLUSIVE (0x01): 465 :Indicates that the stream dependency is exclusive (see [RFC7540] 466 Section 5.3). 468 If a PRIORITY frame is received which attempts to modify a stream 469 which is not a request control scheme, the recipient MUST respond 470 with a connection error (Section 5.4.1) of type PROTOCOL_ERROR. 472 The PRIORITY frame can affect a stream in any state. Note that this 473 frame could arrive after processing or frame sending has completed, 474 which would cause it to have no effect on the identified stream. For 475 a stream that is in the "half-closed (remote)" or "closed" state, 476 this frame can only affect processing of the identified stream and 477 its dependent streams; it does not affect frame transmission on that 478 stream. 480 The PRIORITY frame can create a dependency on a stream in the "idle" 481 or "closed" state. This allows for the reprioritization of a group 482 of dependent streams by altering the priority of an unused or closed 483 parent stream. 485 A PRIORITY frame with a length other than 9 octets MUST be treated as 486 a connection error of type FRAME_SIZE_ERROR. 488 3.2.5. SETTINGS 490 The EXTENDED_SETTINGS frame as defined in 491 [I-D.bishop-httpbis-extended-settings] will be renamed SETTINGS and 492 will replace the HTTP/2 SETTINGS frame. 494 *TODO:* SETTINGS_ACK and stream state. Do we need to emit the ACK on 495 every active stream? What about idle streams and in-flight data? 497 3.2.6. Other frames not mentioned 499 QUIC stream 3 is equivalent to HTTP/2's stream 0, and the same 500 framing is used as for other streams. SETTINGS frames remain on 501 stream 3, as do any other HTTP/2 stream-zero frames. This enables 502 HTTP/2 extension frames which do not have a hard cross-stream 503 ordering requirement to continue to function. 505 3.3. HTTP Message Exchanges 507 A client sends an HTTP request on a new pair of QUIC stream. A 508 server sends an HTTP response on the same streams as the request. 510 An HTTP message (request or response) consists of: 512 1. for a response only, zero or more header blocks (a sequence of 513 HEADERS frames with End Header Block set on the last) on the 514 control stream containing the message headers of informational 515 (1xx) HTTP responses (see [RFC7230], Section 3.2 and [RFC7231], 516 Section 6.2), 518 2. one header block on the control stream containing the message 519 headers (see [RFC7230], Section 3.2), 521 3. the payload body (see [RFC7230], Section 3.3), sent on the data 522 stream 524 4. optionally, one header block on the control stream containing the 525 trailer-part, if present (see [RFC7230], Section 4.1.2). 527 If the message does not contain a body, the corresponding data stream 528 MUST still be half-closed without transferring any data. The 529 "chunked" transfer encoding defined in Section 4.1 of [RFC7230] MUST 530 NOT be used. 532 Trailing header fields are carried in a header block following the 533 body. Such a header block is a sequence of HEADERS frames with End 534 Header Block set on the last frame. Header blocks after the first 535 but before the end of the stream are invalid. These MUST be decoded 536 to maintain QPACK decoder state, but the resulting output MUST be 537 discarded. 539 An HTTP request/response exchange fully consumes a pair of streams. 540 After sending a request, a client closes the streams for sending; 541 after sending a response, the server closes its streams for sending 542 and the QUIC streams are fully closed. 544 A server can send a complete response prior to the client sending an 545 entire request if the response does not depend on any portion of the 546 request that has not been sent and received. When this is true, a 547 server MAY request that the client abort transmission of a request 548 without error by sending a RST_STREAM with an error code of NO_ERROR 549 after sending a complete response and closing its stream. Clients 550 MUST NOT discard responses as a result of receiving such a 551 RST_STREAM, though clients can always discard responses at their 552 discretion for other reasons. 554 4. Performance Considerations 556 While QPACK is designed to minimize head-of-line blocking between 557 streams on header decoding, there are some situations in which lost 558 or delayed packets can still impact the performance of header 559 compression. 561 References to indexed entries will block if the frame containing the 562 entry definition is lost or delayed. Encoders MAY choose to trade 563 off compression efficiency and avoid blocking by repeating the 564 literal-with-indexing instruction rather than referencing the dynamic 565 table until the insertion is known to be complete. 567 Delayed frames which prevent deletes from completing can prevent the 568 encoder from adding any new entries due to the maximum table size. 569 This does not block the encoder from continuing to make requests, but 570 could sharply limit compression performance. Encoders would be well- 571 served to delete entries in advance of encountering the table 572 maximum. Decoders SHOULD be prompt about emitting QPACK-ACK frames 573 to enable the sender to recover the table space. 575 5. Security Considerations 577 The security considerations for QPACK are believed to be the same as 578 for HPACK. 580 6. IANA Considerations 582 This document currently makes no request of IANA, but probably 583 should. 585 7. Acknowledgements 587 This draft draws heavily on the text of [RFC7540] and [RFC7541], as 588 well as the ideas of [I-D.shade-quic-http2-mapping]. The indirect 589 input of those authors is gratefully acknowledged, as well as ideas 590 gleefully stolen from: 592 o Jana Iyengar 594 o Patrick McManus 596 o Martin Thomson 598 o Charles 'Buck' Krasic 600 o Kyle Rose 602 8. References 604 8.1. Normative References 606 [I-D.bishop-httpbis-extended-settings] 607 Bishop, M., "HTTP/2 Extended SETTINGS Extension", draft- 608 bishop-httpbis-extended-settings-00 (work in progress), 609 June 2016. 611 [I-D.hamilton-quic-transport-protocol] 612 Hamilton, R., Iyengar, J., Swett, I., and A. Wilk, "QUIC: 613 A UDP-Based Multiplexed and Secure Transport", draft- 614 hamilton-quic-transport-protocol-01 (work in progress), 615 October 2016. 617 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 618 Requirement Levels", BCP 14, RFC 2119, 619 DOI 10.17487/RFC2119, March 1997, 620 . 622 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 623 Protocol (HTTP/1.1): Message Syntax and Routing", 624 RFC 7230, DOI 10.17487/RFC7230, June 2014, 625 . 627 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 628 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 629 DOI 10.17487/RFC7231, June 2014, 630 . 632 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 633 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 634 DOI 10.17487/RFC7540, May 2015, 635 . 637 [RFC7541] Peon, R. and H. Ruellan, "HPACK: Header Compression for 638 HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, 639 . 641 8.2. Informative References 643 [I-D.shade-quic-http2-mapping] 644 Shade, R. and M. Warres, "HTTP/2 Semantics Using The QUIC 645 Transport Protocol", draft-shade-quic-http2-mapping-00 646 (work in progress), July 2016. 648 Author's Address 650 Mike Bishop 651 Microsoft 653 Email: michael.bishop@microsoft.com