idnits 2.17.1 draft-bishop-quic-http-and-qpack-02.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 (February 8, 2017) is 2633 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-01 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-01 ** 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 Microsoft 4 Intended status: Standards Track February 8, 2017 5 Expires: August 12, 2017 7 Header Compression for HTTP/QUIC 8 draft-bishop-quic-http-and-qpack-02 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 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 August 12, 2017. 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. QPACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.1. Basic model . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.2. Changes to Static and Dynamic Tables . . . . . . . . . . 4 58 2.2.1. Changes to Header Table Size . . . . . . . . . . . . 4 59 2.2.2. Dynamic Table State Synchronization . . . . . . . . . 5 60 2.3. Format of Header Management stream . . . . . . . . . . . 6 61 2.3.1. Insert . . . . . . . . . . . . . . . . . . . . . . . 6 62 2.3.2. Delete . . . . . . . . . . . . . . . . . . . . . . . 7 63 2.3.3. Delete-Ack . . . . . . . . . . . . . . . . . . . . . 10 64 2.4. Format of Encoded Headers on Message Streams . . . . . . 10 65 2.4.1. Indexed Header Field Representation . . . . . . . . . 10 66 2.4.2. Literal Header Field Representation . . . . . . . . . 11 67 3. Use in HTTP/QUIC . . . . . . . . . . . . . . . . . . . . . . 12 68 4. Performance Considerations . . . . . . . . . . . . . . . . . 12 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 71 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 72 8. Normative References . . . . . . . . . . . . . . . . . . . . 14 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 75 1. Introduction 77 HPACK has a number of features that were intended to provide 78 performance advantages to HTTP/2, but which don't live well in an 79 out-of-order environment such as that provided by QUIC. 81 The largest challenge is the fact that elements are referenced by a 82 very fluid index. Not only is the index implicit when an item is 83 added to the header table, the index will change without notice as 84 other items are added to the header table. Static entries occupy the 85 first 61 values, followed by dynamic entries. A newly-added dynamic 86 entry would cause older dynamic entries to be evicted, and the 87 retained items are then renumbered beginning with 62. This means 88 that, without processing all preceding header sets, no index into the 89 dynamic table can be interpreted, and the index of a given entry 90 cannot be predicted. 92 Any solution to the above will almost certainly fall afoul of the 93 memory constraints the decompressor imposes. The automatic eviction 94 of entries is done based on the compressor's declared dynamic table 95 size, which MUST be less than the maximum permitted by the 96 decompressor (and relayed using an HTTP/2 SETTINGS value). 98 Further, streams in QUIC are lossy in the presence of stream resets. 99 While HTTP/2 (via TCP) guarantees the delivery of all previously-sent 100 data on a stream even if that stream is reset, QUIC does not 101 retransmit lost frames if a stream has been reset, and may discard 102 data which has not yet been delivered to the application. 104 Previous versions of QPACK were small deltas of HPACK to introduce 105 order-resiliency. This version departs from HPACK more substantially 106 to add resilience against reset message streams. 108 In the following sections, this document proposes a new version of 109 HPACK which makes different trade-offs, enabling partial out-of-order 110 interpretation and bounded memory consumption with minimal head-of- 111 line blocking. None of the proposed improvements to HPACK (strongly- 112 typed fields, binary compression of common header syntax) are 113 currently included, but certainly could be. 115 1.1. Terminology 117 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 118 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 119 and "OPTIONAL" are to be interpreted as described in BCP 14, 120 [RFC2119] and indicate requirement levels for compliant 121 implementations. 123 2. QPACK 125 2.1. Basic model 127 HPACK combines header table modification and message header emission 128 in a single sequence of coded bytes. QPACK bifurcates these into two 129 channels: 131 o A connection-wide series of table update instructions sent on a 132 dedicated headers stream 134 o Non-modifying instructions which use the current header table 135 state to encode message headers 137 Because the per-message instructions introduce no changes to the 138 header table state, no state is lost if these instructions are 139 discarded due to a stream reset. 141 2.2. Changes to Static and Dynamic Tables 143 QPACK uses two tables for associating header fields to indexes. The 144 static table is unchanged from [RFC7541]. 146 The dynamic table is a map from index to header field. Indices are 147 arbitrary numbers greater than the last index of the static table and 148 less than 2^27. Each insert instruction will specify the index being 149 modified. While any index MAY be chosen for a new entry, smaller 150 numbers will yield better compression performance. 152 The dynamic table is still constrained to the size specified by the 153 decoder. An attempt to add a header to the dynamic table which 154 causes it to exceed the maximum size MUST be treated as an error by a 155 decoder. To enable encoders to reclaim space, encoders can delete 156 entries in the dynamic table, but can only reuse the index or the 157 space after receiving confirmation of a successful deletion. 159 Because it is possible for QPACK frames to arrive which reference 160 indices which have not yet been defined, such frames MUST wait until 161 another frame has arrived and defined the index. In order to guard 162 against malicious peers, implementations SHOULD impose a time limit 163 and treat expiration of the timer as a decoding error. However, if 164 the implementation chooses not to abort the connection, the remainder 165 of the header block MUST be decoded and the output discarded. 167 2.2.1. Changes to Header Table Size 169 HTTP/QUIC prohibits mid-stream changes of settings. As a result, 170 only one table size change is possible: From the value a client 171 assumes during the 0-RTT flight to the actual value included in the 172 server's SETTINGS frame. The assumed value is required to be either 173 a server's previous value or zero. A server whose configuration has 174 recently changed MAY overlook inadvertent violations of its maximum 175 table size during the first round-trip. 177 In the case that the value has increased, either from zero to a non- 178 zero value or from the cached value to a higher value, no action is 179 required by the client. The encoder can simply begin using the 180 additional space. In the case that the value has decreased, the 181 encoder MUST immediately emit delete instructions which, upon 182 completion, would bring the table within the required size. 184 Regardless of changes to header table size, the encoder MUST NOT add 185 entries to the table which would result in a size greater than the 186 maximum permitted. This can imply that no additions are permitted 187 while waiting for these delete instructions to complete. 189 2.2.2. Dynamic Table State Synchronization 191 In order to ensure table consistency, all modifications of the header 192 table occur on a dedicated control stream. Message control streams 193 contain only indexed and literal header entries. 195 No entries are automatically evicted from the dynamic table. Size 196 management is purely the responsibility of the encoder, which MUST 197 NOT exceed the declared memory size of the decoder. 199 The encoder SHOULD track the following information about each entry 200 in the table: 202 o The list of recently-active streams which reference the entry in a 203 trailer block, if any 205 o The list of recently-active streams which reference the entry in a 206 non-trailer block, if any 208 "Recently-active" streams are those which are still open or were 209 closed less than a reasonable number of RTTs ago. An implementation 210 MAY vary its definition of "recent" to trade off memory consumption 211 and timely completion of deletes. 213 The encoder MUST consider memory as committed beginning when the 214 indexed entry is assigned. 216 When the encoder wishes to delete an inserted value, it flows through 217 the following set of states: 219 1. *Delete requested.* The encoder emits a delete instruction 220 indicating which streams might have referenced the entry. The 221 encoder MUST NOT reference the entry in any subsequent frame 222 until this state machine has completed and MUST continue to 223 include the entry in its calculation of consumed memory. 225 2. *Delete pending.* The decoder receives the delete instruction and 226 checks the current state of its incoming streams (see 227 Section 2.3.2.2). If more references might arrive, it stores the 228 streams still needed and waits for them to complete. 230 3. *Delete acknowledged.* The decoder has received all QPACK frames 231 which reference the deleted value, and can safely delete the 232 entry. The decoder SHOULD promptly emit a Delete-Ack instruction 233 on the header management stream. 235 4. *Delete completed.* When the encoder receives a Delete-Ack 236 instruction acknowledging the delete, it no longer counts the 237 size of the deleted entry against the table size and MAY emit 238 insert instructions for the field with a new value. 240 2.3. Format of Header Management stream 242 The header management stream contains a series of QPACK instructions 243 with no message boundaries. Data on this stream SHOULD be processed 244 as soon as it arrives. 246 This section describes the instructions which are possible on the 247 Header Management stream. 249 2.3.1. Insert 251 An addition to the header table starts with the '1' one-bit pattern, 252 followed by the new index of the header represented as an integer 253 with a 7-bit prefix. This value is always greater than the number of 254 entries in the static table. 256 If the header field name matches the header field name of an entry 257 stored in the static table or the dynamic table, the header field 258 name can be represented using the index of that entry. In this case, 259 the index of the entry is represented as an integer with an 8-bit 260 prefix (see Section 5.1 of [RFC7541]). This value is always non- 261 zero. 263 0 1 2 3 4 5 6 7 264 +---+---+---+---+---+---+---+---+ 265 | 1 | New Index (7+) | 266 +---+---+-----------------------+ 267 | Name Index (8+) | 268 +---+---------------------------+ 269 | H | Value Length (7+) | 270 +---+---------------------------+ 271 | Value String (Length octets) | 272 +-------------------------------+ 274 Insert Header Field -- Indexed Name 276 Otherwise, the header field name is represented as a string literal 277 (see Section 5.2 of [RFC7541]). A value 0 is used in place of the 278 8-bit index, followed by the header field name. 280 0 1 2 3 4 5 6 7 281 +---+---+---+---+---+---+---+---+ 282 | 1 | New Index (7+) | 283 +---+---+-----------------------+ 284 | 0 | 285 +---+---+-----------------------+ 286 | H | Name Length (7+) | 287 +---+---------------------------+ 288 | Name String (Length octets) | 289 +---+---------------------------+ 290 | H | Value Length (7+) | 291 +---+---------------------------+ 292 | Value String (Length octets) | 293 +-------------------------------+ 295 Insert Header Field -- New Name 297 Either form of header field name representation is followed by the 298 header field value represented as a string literal (see Section 5.2 299 of [RFC7541]). 301 An encoder MUST NOT attempt to place a value at an index not known to 302 be vacant. A decoder MUST treat the attempt to insert into an 303 occupied slot as a fatal error. 305 2.3.2. Delete 307 A deletion from the header table starts with the '00' two bit 308 pattern, followed by the index of the affected entry represented as 309 an integer with a 6-bit prefix. This value is always greater than 310 the number of entries in the static table. 312 A delete instruction then encodes a series of stream IDs which might 313 have contained references to the entry in question. 315 0 1 2 3 4 5 6 7 316 +---+---+---+---+---+---+---+---+ 317 | 0 | 0 | Index (6+) | 318 +---+---+-----------------------+ 319 | Non-Trailer List (*) ... 320 +-------------------------------+ 321 | Trailer List (*) ... 322 +-------------------------------+ 324 Delete Instruction 326 Both the Non-Trailer List and Trailer List are Stream ID Lists (see 327 below) encoding a list of streams which might have referenced the 328 entry either in non-trailer or trailer blocks. 330 2.3.2.1. Stream ID List 332 A Stream ID List encodes a sequence of stream IDs in two parts: 333 First, a Horizon value indicates the first non-occurrence about which 334 data is maintained. If data is maintained from the beginning of the 335 connection, the Horizon is zero. This allows senders to succinctly 336 express both old state which has been discarded and large regions 337 where many or all streams contain references. 339 Following the horizon, a sequence of deltas indicates all streams 340 since the Horizon on which a value has been used. 342 In the simplest case, a Stream ID List might be a horizon value 343 followed by one zero byte. This indicates an absolute cut-off after 344 which the entry is guaranteed not to be referenced. 346 0 1 2 3 4 5 6 7 347 +-------------------------------+ 348 | Horizon (8+) | 349 +-------------------------------+ 350 | NumEntries (8+) | 351 +-------------------------------+ 352 | [Delta1 (8+)] | 353 +-------------------------------+ 354 | [Delta2 (8+)] | 355 +-------------------------------+ 356 ... 357 +-------------------------------+ 358 | [DeltaN (8+)] | 359 +-------------------------------+ 361 Stream ID List 363 The field are as follows: 365 Horizon: The ID of the first stream for which the sender retains 366 state which does not reference the deleted entry in the indicated 367 block 369 NumEntries: The number of streams greater than the Horizon which 370 might reference the entry and are listed in the remainder of the 371 instruction 373 Delta1..N: A sequence of streams greater than the Horizon which 374 might reference the entry, encoded as the difference in stream 375 number from the previously-listed stream. This field is repeated 376 NumEntries times. 378 2.3.2.2. Delete Validation 380 In order to safely delete an entry, a decoder MUST ensure that all 381 outstanding references have arrived and been processed. Because no 382 data is available about stream IDs less than the Horizon, a decoder 383 MUST assume that any earlier stream ID might have contained a 384 reference to the value in question. 386 A decoder can ensure all outstanding references have been processed 387 by verifying that the following statements are true: 389 o In the Non-Trailer Block, all streams less than the Horizon and 390 all streams explicitly listed are in one of two states: 392 * closed 394 * headers completely processed 396 o In the Trailer Block, all streams less than the Horizon and all 397 streams explicitly listed are in one of three states: 399 * closed 401 * headers completely processed AND no trailers are expected 403 * trailers completely processed 405 An implementation MAY omit the "trailers completely processed" case, 406 since the stream is expected to close immediately after receipt of 407 the trailers block. 409 If these conditions are not met upon receipt of a Delete instruction, 410 a decoder MUST wait to emit a Delete-Ack instruction until the 411 outstanding streams have reached an appropriate state. 413 Note that a decoder MAY condense the list of specified streams by 414 increasing the Horizon value and discarding those explicitly-listed 415 stream IDs which are less than the new Horizon it has chosen. This 416 delays delete completion, but reduces the amount of state to be 417 tracked by the decoder without changing the correctness of the 418 requirements above. 420 2.3.3. Delete-Ack 422 Confirmation that a delete has completed is expressed by an 423 instruction which starts with the '01' two-bit pattern, followed by 424 the index of the affected entry represented as an integer with a 425 6-bit prefix. This value is always greater than the number of 426 entries in the static table. 428 Note that unlike all other instructions, this instruction refers to 429 the receiver's dynamic table, not the sender's. 431 0 1 2 3 4 5 6 7 432 +---+---+---+---+---+---+---+---+ 433 | 0 | 1 | Index (6+) | 434 +---+---+-----------------------+ 436 Delete-Ack Instruction 438 This instruction MUST NOT be sent before the conditions described in 439 Section 2.3.2.2 have been satisfied, and SHOULD be sent as soon as 440 possible once they are. 442 2.4. Format of Encoded Headers on Message Streams 444 Frames which carry HTTP message headers encode them using the 445 following instructions: 447 2.4.1. Indexed Header Field Representation 449 An indexed header field representation identifies an entry in either 450 the static table or the dynamic table and causes that header field to 451 be added to the decoded header list, as described in Section 3.2 of 452 [RFC7541]. 454 0 1 2 3 4 5 6 7 455 +---+---+---+---+---+---+---+---+ 456 | 1 | Index (7+) | 457 +---+---------------------------+ 459 Indexed Header Field 461 An indexed header field starts with the '1' 1-bit pattern, followed 462 by the index of the matching header field, represented as an integer 463 with a 7-bit prefix (see Section 5.1 of [RFC7541]). 465 The index value of 0 is not used. It MUST be treated as a decoding 466 error if found in an indexed header field representation. 468 2.4.2. Literal Header Field Representation 470 A literal header field representation starts with the '0' 1-bit 471 pattern and causes a header field to be added the decoded header 472 list. 474 The second bit, 'N', indicates whether an intermediary is permitted 475 to add this header to the dynamic header table on subsequent hops. 476 When the 'N' bit is set, the encoded header MUST always be encoded 477 with this specific literal representation. In particular, when a 478 peer sends a header field that it received represented as a literal 479 header field with the 'N' bit set, it MUST use the same 480 representation to forward this header field. This bit is intended 481 for protecting header field values that are not to be put at risk by 482 compressing them (see Section 7.1 of [RFC7541] for more details). 484 If the header field name matches the header field name of an entry 485 stored in the static table or the dynamic table, the header field 486 name can be represented using the index of that entry. In this case, 487 the index of the entry is represented as an integer with a 6-bit 488 prefix (see Section 5.1 of [RFC7541]). This value is always non- 489 zero. 491 0 1 2 3 4 5 6 7 492 +---+---+---+---+---+---+---+---+ 493 | 0 | N | Name Index (6+) | 494 +---+---+-----------------------+ 495 | H | Value Length (7+) | 496 +---+---------------------------+ 497 | Value String (Length octets) | 498 +-------------------------------+ 500 Literal Header Field -- Indexed Name 502 Otherwise, the header field name is represented as a string literal 503 (see Section 5.2 of [RFC7541]). A value 0 is used in place of the 504 6-bit index, followed by the header field name. 506 0 1 2 3 4 5 6 7 507 +---+---+---+---+---+---+---+---+ 508 | 0 | N | 0 | 509 +---+---+-----------------------+ 510 | H | Name Length (7+) | 511 +---+---------------------------+ 512 | Name String (Length octets) | 513 +---+---------------------------+ 514 | H | Value Length (7+) | 515 +---+---------------------------+ 516 | Value String (Length octets) | 517 +-------------------------------+ 519 Literal Header Field -- Literal Name 521 Either form of header field name representation is followed by the 522 header field value represented as a string literal (see Section 5.2). 524 3. Use in HTTP/QUIC 526 HTTP/QUIC [I-D.ietf-quic-http] currently retains the HPACK encoder/ 527 decoder from HTTP/2, using a Sequence number to enforce ordering. 528 Using QPACK instead would entail the following changes: 530 o The Sequence field is removed from HEADERS frames (Section 5.2.2) 531 and PUSH_PROMISE frames (Section 5.2.6). 533 o Header Block Fragments consist of QPACK data instead of HPACK 534 data. 536 o An additional control stream is reserved for header table updates. 537 Alternately, this could be carried by HEADERS frames on the 538 connection control stream. 540 A HEADERS or PUSH_PROMISE frame MAY contain an arbitrary number of 541 QPACK instructions, but QPACK instructions SHOULD NOT cross a 542 boundary between successive HEADERS frames. A partial HEADERS or 543 PUSH_PROMISE frame MAY be processed upon arrival and the resulting 544 partial header set emitted or buffered according to implementation 545 requirements. 547 4. Performance Considerations 549 While QPACK is designed to minimize head-of-line blocking between 550 streams on header decoding, there are some situations in which lost 551 or delayed packets can still impact the performance of header 552 compression. 554 References to indexed entries will block if the frame containing the 555 entry definition is lost or delayed. Encoders MAY choose to trade 556 off compression efficiency and avoid blocking by using literal 557 instructions rather than referencing the dynamic table until the 558 insertion is believed to be complete. 560 Since it is possible to insert header values without emitting them on 561 a stream, an encoder MAY proactively insert header values which it 562 believes will be needed on future requests. 564 Delayed frames which prevent deletes from completing can prevent the 565 encoder from adding any new entries due to the maximum table size. 566 This does not block the encoder from continuing to make requests, but 567 could sharply limit compression performance. Encoders would be well- 568 served to delete entries in advance of encountering the table 569 maximum. Decoders SHOULD be prompt about emitting Delete-Ack 570 instructions to enable the encoder to recover the table space. 572 5. Security Considerations 574 A malicious encoder might attempt to consume a large amount of space 575 on the decoder by opening the maximum number of streams, adding 576 entries to the table, then sending delete instructions enumerating 577 many streams in a Stream ID List. 579 To guard against such attacks, a decoder SHOULD bound its state 580 tracking by generalizing the list of streams to be tracked. This is 581 most easily achieved by advancing the Horizon to a later value and 582 discarding explicit Stream IDs to track, but can also be accomplished 583 by eliding explicit streams in ranges. This does not cause any loss 584 of consistency for deletes, but could delay completion and reduce 585 performance if done aggressively. 587 6. IANA Considerations 589 This document currently makes no request of IANA, and might not need 590 to. 592 7. Acknowledgements 594 This draft draws heavily on the text of [RFC7541]. The indirect 595 input of those authors is gratefully acknowledged, as well as ideas 596 gleefully stolen from: 598 o Jana Iyengar 600 o Patrick McManus 601 o Martin Thomson 603 o Charles 'Buck' Krasic 605 o Kyle Rose 607 8. Normative References 609 [I-D.ietf-quic-http] 610 Bishop, M., "Hypertext Transfer Protocol (HTTP) over 611 QUIC", draft-ietf-quic-http-01 (work in progress), January 612 2017. 614 [I-D.ietf-quic-transport] 615 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 616 and Secure Transport", draft-ietf-quic-transport-01 (work 617 in progress), January 2017. 619 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 620 Requirement Levels", BCP 14, RFC 2119, 621 DOI 10.17487/RFC2119, March 1997, 622 . 624 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 625 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 626 DOI 10.17487/RFC7540, May 2015, 627 . 629 [RFC7541] Peon, R. and H. Ruellan, "HPACK: Header Compression for 630 HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, 631 . 633 Author's Address 635 Mike Bishop 636 Microsoft 638 Email: michael.bishop@microsoft.com