idnits 2.17.1 draft-tsvwg-quic-protocol-01.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: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 12 instances of too long lines in the document, the longest one being 3 characters in excess of 72. 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). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: o QUIC Version: A 32 bit opaque tag that represents the version of the QUIC protocol. Only present if the public flags contain FLAG_VERSION (i.e public_flags & FLAG_VERSION !=0). A client may set this flag, and include EXACTLY one proposed version, as well as including arbitrary data (conforming to that version). A server may set this flag when the client-proposed version was unsupported, and may then provide a list (0 or more) of acceptable versions, but MUST not include any data after the version(s). Examples of version values in recent experimental versions include "Q025" which corresponds to byte 9 containing 'Q", byte 10 containing '0", etc. [See list of changes in various versions listed at the end of this document.] -- The document date (July 8, 2015) is 3214 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 1401 -- Looks like a reference, but probably isn't: '2' on line 1403 -- Looks like a reference, but probably isn't: '3' on line 1405 == Unused Reference: 'RFC2119' is defined on line 1385, but no explicit reference was found in the text == Unused Reference: 'QUIC-CC' is defined on line 1396, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Hamilton 3 Internet-Draft J. Iyengar 4 Intended status: Informational I. Swett 5 Expires: January 9, 2016 A. Wilk 6 Google 7 July 8, 2015 9 QUIC: A UDP-Based Secure and Reliable Transport for HTTP/2 10 draft-tsvwg-quic-protocol-01 12 Abstract 14 QUIC (Quick UDP Internet Connection) is a new multiplexed and secure 15 transport atop UDP, designed from the ground up and optimized for 16 HTTP/2 semantics. While built with HTTP/2 as the primary application 17 protocol, QUIC builds on decades of transport and security 18 experience, and implements mechanisms that make it attractive as a 19 modern general-purpose transport. QUIC provides multiplexing and 20 flow control equivalent to HTTP/2, security equivalent to TLS, and 21 connection semantics, reliability, and congestion control equivalent 22 to TCP. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 9, 2016. 41 Copyright Notice 43 Copyright (c) 2015 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 1. Contributors 58 This protocol is the outcome of work by many engineers, not just the 59 authors of this document. The design and rationale behind QUIC draw 60 significantly from work by Jim Roskind. In alphabetical order, the 61 contributors to the project are: Wan-Teh Chang, Britt Cyr, Ryan 62 Hamilton, Jana Iyengar, Fedor Kouranov, Jo Kulik, Adam Langley, Jim 63 Roskind, Robbie Shade, Satyam Shekhar, Ian Swett, Raman Tenneti, 64 Antonio Vicente, Patrik Westin, Alyssa Wilk, Dale Worley, Daniel 65 Ziegler. 67 2. Acknowledgments 69 Special thanks are due to the following for helping shape QUIC and 70 its deployment: Chris Bentzel, Misha Efimov, Roberto Peon, Alistair 71 Riddoch, Siddharth Vijayakrishnan, and Assar Westerlund. QUIC has 72 also benefited immensely from discussions with folks in private 73 conversations and public ones on the proto-quic@chromium.org mailing 74 list. 76 3. Introduction 78 QUIC (Quick UDP Internet Connection) is a new multiplexed and secure 79 transport atop UDP, designed from the ground up and optimized for 80 HTTP/2 semantics. While built with HTTP/2 as the primary application 81 protocol, QUIC builds on decades of transport and security 82 experience, and implements mechanisms that make it attractive as a 83 modern general-purpose transport. QUIC provides multiplexing and 84 flow control equivalent to HTTP/2, security equivalent to TLS, and 85 connection semantics, reliability, and congestion control equivalent 86 to TCP. 88 QUIC operates entirely in userspace, and is currently shipped to 89 users as a part of the Chromium browser, enabling rapid deployment 90 and experimentation. As a userspace transport atop UDP, QUIC allows 91 innovations which have proven difficult to deploy with existing 92 protocols as they are hampered by legacy clients and middleboxes, or 93 by prolonged Operating System development and deployment cycles. 95 An important goal for QUIC is to inform better transport design 96 through rapid experimentation. As a result, we hope to inform and 97 where possible migrate distilled changes into TCP and TLS, which tend 98 to have much longer iteration cycles. 100 This document describes the conceptual design and the wire 101 specification of the QUIC protocol. Accompanying documents describe 102 the combined crypto and transport handshake [QUIC-CRYPTO], and loss 103 recovery and congestion control [draft-quic-loss-recovery]. 104 Additional resources, including a more detailed rationale document, 105 are available on the Chromium QUIC webpage [1]. 107 4. Conventions and Definitions 109 All integer values used in QUIC, including length, version, and type, 110 are in little-endian byte order, and not in network byte order. QUIC 111 does not enforce alignment of types in dynamically sized frames. 113 A few terms that are used throughout this document are defined below. 115 o "Client": The endpoint initiating a QUIC connection. 117 o "Server": The endpoint accepting incoming QUIC connections. 119 o "Endpoint": The client or server end of a connection. 121 o "Stream": A bi-directional flow of bytes across a logical channel 122 within a QUIC connection. 124 o "Connection": A conversation between two QUIC endpoints with a 125 single encryption context that multiplexes streams within it. 127 o "Connection ID": The identifier for a QUIC connection. 129 o "QUIC Packet": A well-formed UDP payload that can be parsed by a 130 QUIC receiver. QUIC packet size in this document refers to the 131 UDP payload size. 133 5. A QUIC Overview 135 We now briefly describe QUIC's key mechanisms and benefits. QUIC is 136 functionally equivalent to TCP+TLS+HTTP/2, but implemented on top of 137 UDP. Key advantages of QUIC over TCP+TLS+HTTP/2 include: 139 o Connection establishment latency 141 o Flexible congestion control 143 o Multiplexing without head-of-line blocking 144 o Authenticated and encrypted header and payload 146 o Stream and connection flow control 148 o Forward error correction 150 o Connection migration 152 5.1. Connection Establishment Latency 154 For a complete description of connection establishment, please see 155 the QUIC Crypto design [2] document. Briefly, QUIC handshakes 156 frequently require zero roundtrips before sending payload, as 157 compared to 1-3 roundtrips for TCP+TLS. 159 The first time a QUIC client connects to a server, the client must 160 perform a 1-roundtrip handshake in order to acquire the necessary 161 information to complete the handshake. The client sends an inchoate 162 (empty) client hello (CHLO), the server sends a rejection (REJ) with 163 the information the client needs to make forward progress. This 164 information includes a source address token, which is used to verify 165 the client's IP on a subsequent CHLO, and the server's certificates. 166 The next time the client sends a CHLO, it can use the cached 167 credentials from the previous connection to immediately send 168 encrypted requests to the server. 170 5.2. Flexible Congestion Control 172 QUIC has pluggable congestion control and richer signaling than TCP, 173 which enables QUIC to provide richer information to congestion 174 control algorithms than TCP. Currently, the default congestion 175 control is a reimplementation of TCP Cubic; we are currently 176 experimenting with alternative approaches. 178 One example of richer information is that each packet, both original 179 and retransmitted, carries a new sequence number. This allows a QUIC 180 sender to distinguish ACKs for retransmissions from ACKs for original 181 transmissions, thus avoiding TCP's retransmission ambiguity problem. 182 QUIC ACKs also explicitly carry the delay between the receipt of a 183 packet and its acknowledgment being sent, and together with the 184 monotonically-increasing sequence numbers, this allows for precise 185 roundtrip-time (RTT) calculation. 187 Finally, QUIC's ACK frames support up to 256 NACK ranges, so QUIC is 188 more resilient to reordering than TCP (with SACK), as well as able to 189 keep more bytes on the wire when there is reordering or loss. Both 190 client and server have a more accurate picture of which packets the 191 peer has received. 193 5.3. Stream and Connection Flow Control 195 QUIC implements stream- and connection-level flow control, closely 196 following HTTP/2's flow control. QUIC's stream-level flow control 197 works as follows. A QUIC receiver advertises the absolute byte 198 offset within each stream upto which the receiver is willing to 199 receive data. As data is sent, received, and delivered on a 200 particular stream, the receiver sends WINDOW_UPDATE frames that 201 increase the advertised offset limit for that stream, allowing the 202 peer to send more data on that stream. 204 In addition to per-stream flow control, QUIC implements connection- 205 level flow control to limit the aggregate buffer that a QUIC receiver 206 is willing to allocate to a connection. Connection flow control 207 works in the same way as stream flow control, but the bytes delivered 208 and highest received offset are all aggregates across all streams. 210 Similar to TCP's receive-window autotuning, QUIC implements 211 autotuning of flow control credits for both stream and connection 212 flow controllers. QUIC's autotuning increases the size of the 213 credits sent per WINDOW_UPDATE frame if it appears to be limiting the 214 sender's rate, and throttles the sender when the receiving 215 application is slow. 217 5.4. Multiplexing 219 HTTP/2 on TCP suffers from head-of-line blocking in TCP. Since 220 HTTP/2 multiplexes many streams atop TCP's single-bytestream 221 abstraction, a loss of a TCP segment results in blocking of all 222 subsequent segments until a retransmission arrives, irrespective of 223 the HTTP/2 stream that is encapsulated in subsequent segments. 225 Because QUIC is designed from the ground up for multiplexed 226 operation, lost packets carrying data for an individual stream 227 generally only impact that specific stream. Each stream frame can be 228 immediately dispatched to that stream on arrival, so streams without 229 loss can continue to be reassembled and make forward progress in the 230 application. 232 Caveat: QUIC currently compresses HTTP headers via HTTP/2 HPACK 233 header compression, which imposes head-of-line blocking for header 234 frames only. 236 5.5. Authenticated and Encrypted Header and Payload 238 TCP headers appear in plaintext on the wire and not authenticated, 239 causing a plethora of injection and header manipulation issues for 240 TCP, such as receive-window manipulation and sequence-number 241 overwriting. While some of these are active attacks, others are 242 mechanisms used by middleboxes in the network sometimes in an attempt 243 to transparently improve TCP performance. However, even 244 "performance-enhancing" middleboxes still effectively limit the 245 evolvability of the transport protocol, as has been observed in the 246 design of MPTCP and in its subsequent deployability issues. 248 QUIC packets are always authenticated and typically the payload is 249 fully encrypted. The parts of the packet header which are not 250 encrypted are still authenticated by the receiver, so as to thwart 251 any packet injection or manipulation by third parties. QUIC protects 252 connections from witting or unwitting middlebox manipulation of end- 253 to-end communication. 255 Caveat: PUBLIC_RESET packets that reset a connection are currently 256 not authenticated. 258 5.6. Forward Error Correction 260 In order to recover lost packets without waiting for a 261 retransmission, QUIC currently employs a simple XOR-based FEC scheme. 262 An FEC packet contains parity of the packets in the FEC group. If 263 one of the packets in the group is lost, the contents of that packet 264 can be recovered from the FEC packet and the remaining packets in the 265 group. The sender may decide whether to send FEC packets to optimize 266 specific scenarios (e.g., beginning and end of a request). 268 5.7. Connection Migration 270 TCP connections are identified by a 4-tuple of source address, source 271 port, destination address and destination port. A well-known problem 272 with TCP is that connections do not survive IP address changes (for 273 example, by switching from WiFi to cellular) or port number changes 274 (when a client's NAT binding expires causing a change in the port 275 number seen at the server). While MPTCP addresses the connection 276 migration problem for TCP, it is still plagued by lack of middlebox 277 support and lack of OS deployment. 279 QUIC connections are identified by a 64-bit Connection ID, randomly 280 generated by the client. QUIC can survive IP address changes and NAT 281 re-bindings since the Connection ID remains the same across these 282 migrations. QUIC also provides automatic cryptographic verification 283 of a migrating client, since a migrating client continues to use the 284 same session key for encrypting and decrypting packets. 286 6. Packet Types and Formats 288 QUIC has four packet types: Version Negotiation Packets, Frame 289 Packets, FEC Packets, and Public Reset Packets. All QUIC packets 290 should be sized to fit within the path's MTU to avoid IP 291 fragmentation. Path MTU discovery is a work in progress, and the 292 current QUIC implementation uses a 1350-byte maximum QUIC packet size 293 for IPv6, 1370 for IPv4. 295 6.1. QUIC Common Packet Header 297 All QUIC packets on the wire begin with a common header sized between 298 2 and 21 bytes. The wire format for the common header is as follows: 300 0 1 2 3 4 8 301 +--------+--------+--------+--------+--------+--- ---+ 302 | Public | Connection ID (0, 8, 32, or 64) ... | -> 303 |Flags(8)| (variable length) | 304 +--------+--------+--------+--------+--------+--- ---+ 306 9 10 11 12 307 +--------+--------+--------+--------+ 308 | QUIC Version (32) | -> 309 | (optional) | 310 +--------+--------+--------+--------+ 312 13 14 15 16 17 18 19 20 313 +--------+--------+--------+--------+--------+--------+--------+--------+ 314 | Sequence Number (8, 16, 32, or 48) |Private | FEC (8)| 315 | (variable length) |Flags(8)| (opt) | 316 +--------+--------+--------+--------+--------+--------+--------+--------+ 318 QUIC packets are authenticated and encrypted. The first part of the 319 common header upto and including the Sequence Number field is 320 authenticated but not encrypted, and the rest of the packet starting 321 with the Private Flags field is encrypted. 323 The unencrypted payload may include various type-dependent header 324 bytes as described below. 326 The fields in the common header are the following: 328 o Public Flags: 330 * Bit at 0x01 is set to indicate that the packet contains a QUIC 331 Version. This bit must be set by a client in all packets until 332 confirmation from the server arrives agreeing to the proposed 333 version is received by the client. A server indicates 334 agreement on a version by sending packets without setting this 335 bit. Version Negotiation is described in more detail later. 337 * Bit at 0x02 is set to indicate that the packet is a Public 338 Reset packet. 340 * Two bits at 0x0C indicate the size of the Connection ID that is 341 present in the packet. These bits must be set to 0x0C in all 342 packets until negotiated to a different value for a given 343 direction (e.g., client may request fewer bytes of the 344 Connection ID be presented). 346 + 0x0C indicates an 8-byte Connection ID is present 348 + 0x08 indicates that a 4-byte Connection ID is present 350 + 0x04 indicates that a 1-byte Connection ID is used 352 + 0x00 indicates that the Connection ID is omitted 354 * Two bits at 0x30 indicate the number of low-order-bytes of the 355 packet sequence number that are present in each packet. The 356 bits are only used for Frame Packets. For Public Reset and 357 Version Negotiation Packets (sent by the server) which don't 358 have a sequence number, these bits are not used and must be set 359 to 0. Within this 2 bit mask: 361 + 0x30 indicates that 6 bytes of the sequence number is 362 present 364 + 0x20 indicates that 4 bytes of the sequence number is 365 present 367 + 0x10 indicates that 2 bytes of the sequence number is 368 present 370 + 0x00 indicates that 1 byte of the sequence number is present 372 * Two bits at 0xC0 are currently unused, and must be set to 0. 374 o Connection ID: This is an unsigned 64 bit statistically random 375 number selected by the client that is the identifier of the 376 connection. Because QUIC connections are designed to remain 377 established even if the client roams, the IP 4-tuple (source IP, 378 source port, destination IP, destination port) may be insufficient 379 to identify the connection. For each transmission direction, when 380 less uniqueness is sufficient to identify the connection, a 381 truncated transmitted Connection ID length is negotiable. 383 o QUIC Version: A 32 bit opaque tag that represents the version of 384 the QUIC protocol. Only present if the public flags contain 385 FLAG_VERSION (i.e public_flags & FLAG_VERSION !=0). A client may 386 set this flag, and include EXACTLY one proposed version, as well 387 as including arbitrary data (conforming to that version). A 388 server may set this flag when the client-proposed version was 389 unsupported, and may then provide a list (0 or more) of acceptable 390 versions, but MUST not include any data after the version(s). 391 Examples of version values in recent experimental versions include 392 "Q025" which corresponds to byte 9 containing 'Q", byte 10 393 containing '0", etc. [See list of changes in various versions 394 listed at the end of this document.] 396 o Sequence Number: The lower 8, 16, 32, or 48 bits of the sequence 397 number, based on which FLAG_?BYTE_SEQUENCE_NUMBER flag is set in 398 the public flags. See "Sequence numbers" below. 400 o Private Flags: 402 * 0x01 = FLAG_ENTROPY - for data packets, signifies that this 403 packet contains the 1 bit of entropy, for fec packets, contains 404 the xor of the entropy of protected packets. 406 * 0x02 = FLAG_FEC_GROUP - indicates whether the fec byte is 407 present. 409 * 0x04 = FLAG_FEC - signifies that this packet represents an FEC 410 packet. 412 o FEC (FEC Group Number Offset): An FEC Group Number is the Packet 413 Sequence Number of the first packet in the FEC group. The FEC 414 Group Number Offset is an 8 bit unsigned value which should be 415 subtracted from the current packet's Packet Sequence Number to 416 yield the FEC Group Number for this packet. This is only present 417 if the private flags contain FLAG_FEC_GROUP. All packets within a 418 single FEC group must have Sequence Numbers encoded into an 419 identical number of bytes (i.e., the Sequence Number coding must 420 not change during a group) 422 o Sequence Number: Each QUIC Frame Packet (as opposed to public 423 reset and version negotiation packets) is assigned a sequence 424 number by the sender. The first packet sent by an endpoint shall 425 have a sequence number of 1, and each subsequent packet shall have 426 a sequence number one larger than that of the previous packet. 427 The lower 64 bits of the sequence number may be used as part of a 428 cryptographic nonce; therefore, a QUIC endpoint must not send a 429 packet with a sequence number that cannot be represented in 64 430 bits. If a QUIC endpoint transmits a packet with a sequence 431 number of (2^64-1), that packet must include a CONNECTION_CLOSE 432 frame with an error code of QUIC_SEQUENCE_NUMBER_LIMIT_REACHED, 433 and the endpoint must not transmit any additional packets. At 434 most the lower 48 bits of a sequence number are transmitted. To 435 enable unambiguous reconstruction of the sequence number by the 436 receiver, a QUIC endpoint must not transmit a packet whose 437 sequence number is larger by (2^(bitlength-2)) than the largest 438 sequence number for which an acknowledgement is known to have been 439 transmitted by the receiver. Therefore, there must never be more 440 than (2^46) packets in flight. Any truncated sequence number 441 shall be inferred to have the value closest to the one more than 442 the largest known sequence number of the endpoint which 443 transmitted the packet that originally contained the truncated 444 sequence number. The transmitted portion of the sequence number 445 matches the lowest bits of the inferred value. 447 6.2. Version Negotiation Packet 449 (Describe version negotiation packet.) 451 6.3. Frame Packet 453 Beyond the Common Header, Frame Packets have a payload that is a 454 series of type-prefixed frames. The format of frame types is defined 455 later in this document, but the general format of a Frame Packet is 456 as follows: 458 +--------+---...---+--------+---...---+ 459 | Type | Payload | Type | Payload | 460 +--------+---...---+--------+---...---+ 462 6.4. FEC Packet 464 FEC packets (those packets with FLAG_FEC set) have a payload that 465 simply contains an XOR of the null-padded payload of each Data Packet 466 in the FEC group. 468 +-----...----+ 469 | Redundancy | 470 +-----...----+ 472 6.5. Public Reset Packet 474 Public reset packets begin with an 8-bit public flags and 64-bit 475 Connection ID. The rest of the public reset packets is encoded as if 476 it were a crypto handshake message of the tag PRST (see accompanying 477 crypto document for more about QUIC Tags): 479 0 1 2 3 4 8 480 +--------+--------+--------+--------+--------+-- --+ 481 | Public | Connection ID (64) ... | -> 482 |Flags(8)| | 483 +--------+--------+--------+--------+--------+-- --+ 485 9 10 11 12 13 14 486 +--------+--------+--------+--------+--------+--------+--- 487 | Quic Tag (32) | Tag value map ... -> 488 | (PRST) | (variable length) 489 +--------+--------+--------+--------+--------+--------+--- 491 Tag value map: The tag value map contains the following tag-values: 493 o RNON (public reset nonce proof) - a 64-bit unsigned integer. 494 Mandatory. 496 o RSEQ (rejected sequence number) - a 64-bit sequence number. 497 Mandatory. 499 o CADR (client address) - the observed client IP address and port 500 number. Optional. 502 (TODO: Public Reset packet should include authenticated (destination) 503 server IP/port.) 505 7. Life of a QUIC Connection 507 7.1. Connection Establishment 509 A QUIC client is the endpoint that initiates a connection. QUIC's 510 connection establishment intertwines version negotiation with the 511 crypto and transport handshakes to reduce connection establishment 512 latency. We first describe version negotiation below. 514 (Describe Version Negotiation.) 516 The rest of the connection establishment is described in the crypto 517 handshake document [QUIC-CRYPTO]. The crypto handshake is 518 encapsulated within Frame Packets, as stream data on the crypto 519 stream (described later in this section). 521 During connection establishment, QUIC sends various "Tags" inside the 522 handshake packets for negotiating transport parameters. The 523 currently used Tags are described later in the document. 525 7.2. Data Transfer 527 QUIC implements connection reliability, congestion control, and flow 528 control. QUIC flow control closely follows HTTP/2's flow control. 529 QUIC reliability and congestion control are described in an 530 accompanying document. A QUIC connection uses a single packet 531 sequence number space for shared congestion control and loss recovery 532 across the connection. 534 All data transferred in a QUIC connection, including the crypto 535 handshake, is sent as data inside streams, but the ACKs acknowledge 536 QUIC Packets. 538 This section conceptually describes the use of streams for data 539 transfer within a QUIC connection. The various frames that are 540 mentioned in this section are described in the section on Frame Types 541 and Formats. 543 7.2.1. Life of a QUIC Stream 545 Streams are independent sequences of bi-directional data cut into 546 stream frames. Streams can be created either by the client or the 547 server, can concurrently send data interleaved with other streams, 548 and can be cancelled. QUIC's stream lifetime is modeled closely 549 after HTTP/2's [RFC7540]. (HTTP/2's usage of QUIC streams is 550 described in more detail later in the document.) 552 Stream creation is done implicitly, by sending a STREAM frame for a 553 given stream. To avoid stream ID collision, the Stream-ID must be 554 even if the server initiates the stream, and odd if the client 555 initiates the stream. 0 is not a valid Stream-ID. Stream 1 is 556 reserved for the crypto handshake, which should be the first client- 557 initiated stream. When using HTTP/2 over QUIC, Stream 3 is reserved 558 for transmitting compressed headers for all other streams, ensuring 559 reliable in-order delivery and processing of headers. 561 Stream-IDs from each side of the connection must increase 562 monotonically as new streams are created. E.g. Stream 2 may be 563 created after stream 3, but stream 7 must not be created after stream 564 9. The peer may receive streams out of order. For example, if a 565 server receives packet 10 including frames for stream 9 before it 566 receives packet 9 including frames for stream 7, it should handle 567 this gracefully. 569 If the endpoint receiving a STREAM frame does not want to accept the 570 stream, it can immediately respond with a RST_STREAM frame (described 571 below). Note, however, that the initiating endpoint may have already 572 sent data on the stream as well; this data must be ignored. 574 Once a stream is created, it can be used to send and receive data. 575 This means that a series of stream frames can be sent by a QUIC 576 endpoint on a stream until the stream is terminated in that 577 direction. 579 Either QUIC endpoint can terminate a stream normally. There are 580 three ways that streams can be terminated: 582 1. Normal termination: Since streams are bidirectional, streams can 583 be "half-closed" or "closed". When one side of the stream sends 584 a frame with the FIN bit set to true, the stream is considered to 585 be "half-closed" in that direction. A FIN indicates that no 586 further data will be sent from the sender of the FIN on this 587 stream. When a QUIC endpoint has both sent and received a FIN, 588 the endpoint considers the stream to be "closed". While the FIN 589 should be sent with the last user data for a stream, the FIN bit 590 can be sent on an empty stream frame following the last data on 591 the stream. 593 2. Abrupt termination: Either the client or server can send a 594 RST_STREAM frame for a stream at any time. A RST_STREAM frame 595 contains an error code to indicate the reason for failure (error 596 codes are listed later in the document.) When a RST_STREAM frame 597 is sent from the stream originator, it indicates a failure to 598 complete the stream and that no further data will be sent on the 599 stream. When a RST_STREAM frame is sent from the stream 600 receiver, the sender, upon receipt, should stop sending any data 601 on the stream. The stream receiver should be aware that there is 602 a race between data already in transit from the sender and the 603 time the RST_STREAM frame is received. In order to ensure that 604 the connection-level flow control is correctly accounted, even if 605 a RST_STREAM frame is received, a sender needs to ensure that 606 either: the FIN and all bytes in the stream are received by the 607 peer or a RST_STREAM frame is received by the peer. This also 608 means that the sender of a RST_STREAM frame needs to continue 609 responding to incoming STREAM_FRAMEs on this stream with the 610 appropriate WINDOW_UPDATEs to ensure that the sender does not get 611 flow control blocked attempting to delivery the FIN. 613 3. Streams are also terminated when the connection is terminated, as 614 described in the next section. 616 7.3. Connection Termination 618 Connections should remain open until they become idle for a pre- 619 negotiated period of time. When a server decides to terminate an 620 idle connection, it should not notify the client to avoid waking up 621 the radio on mobile devices. A QUIC connection, once established, 622 can be terminated in one of two ways: 624 1. Explicit Shutdown: An endpoint sends a CONNECTION_CLOSE frame to 625 the peer initiating a connection termination. An endpoint may 626 send a GOAWAY frame to the peer prior to a CONNECTION_CLOSE to 627 indicate that the connection will soon be terminated. A GOAWAY 628 frame when sent signals to the peer that any active streams will 629 continue to be processed, but the sender of the GOAWAY will not 630 initiate any additional streams and will not accept any new 631 incoming streams. On termination of the active streams, a 632 CONNECTION_CLOSE may be sent. If an endpoint sends a 633 CONNECTION_CLOSE frame while unterminated streams are active (no 634 FIN bit or RST_STREAM frames have been sent or received for one 635 or more streams), then the peer must assume that the streams were 636 incomplete and were abnormally terminated. 638 2. Implicit Shutdown: The default idle timeout for a QUIC connection 639 is 30 seconds, and is a required parameter("ICSL") in connection 640 negotiation. The maximum is 10 minutes. If there is no network 641 activity for the duration of the idle timeout, the connection is 642 closed. By default a CONNECTION_CLOSE frame will be sent. A 643 silent close option can be enabled when it is expensive to send 644 an explicit close, such as mobile networks that must wake up the 645 radio. 647 An endpoint may also send a PUBLIC_RESET packet at any time during 648 the connection to abruptly terminate an active connection. A 649 PUBLIC_RESET is the QUIC equivalent of a TCP RST. 651 8. Frame Types and Formats 653 QUIC Frame Packets are populated by frames. which have a Frame Type 654 byte, which itself has a type-dependent interpretation, followed by 655 type-dependent frame header fields. All frames are contained within 656 single QUIC Packets and no frame can span across a QUIC Packet 657 boundary. 659 8.1. Frame Types 661 There are two interpretations for the Frame Type byte, resulting in 662 two frame types: Special Frame Types, and Regular Frame Types. 663 Special Frame Types encode both a Frame Type and corresponding flags 664 all in the Frame Type byte, while Regular Frame Types use the Frame 665 Type byte simply. 667 Currently defined Special Frame Types are: 669 +------------------+-----------------------------+ 670 | Type-field value | Control Frame-type | 671 +------------------+-----------------------------+ 672 | 1fdooossB | STREAM | 673 | 01ntllmmB | ACK | 674 | 001xxxxxB | CONGESTION_FEEDBACK | 675 +------------------+-----------------------------+ 677 Currently defined Regular Frame Types are: 679 +------------------+-----------------------------+ 680 | Type-field value | Control Frame-type | 681 +------------------+-----------------------------+ 682 | 00000000B (0x00) | PADDING | 683 | 00000001B (0x01) | RST_STREAM | 684 | 00000010B (0x02) | CONNECTION_CLOSE | 685 | 00000011B (0x03) | GOAWAY | 686 | 00000100B (0x04) | WINDOW_UPDATE | 687 | 00000101B (0x05) | BLOCKED | 688 | 00000110B (0x06) | STOP_WAITING | 689 | 00000111B (0x07) | PING | 690 +------------------+-----------------------------+ 692 8.2. STREAM Frame 694 The STREAM frame is used to both implicitly create a stream and to 695 send data on it, and is as follows: 697 0 1 ... SLEN 698 +--------+--------+--------+--------+--------+ 699 |Type (8)| Stream ID (8, 16, 24, or 32 bits) | 700 | | (Variable length SLEN bytes) | 701 +--------+--------+--------+--------+--------+ 703 SLEN+1 SLEN+2 ... SLEN+OLEN 704 +--------+--------+--------+--------+--------+--------+--------+--------+ 705 | Offset (0, 16, 24, 32, 40, 48, 56, or 64 bits) (variable length) | 706 | (Variable length: OLEN bytes) | 707 +--------+--------+--------+--------+--------+--------+--------+--------+ 709 SLEN+OLEN+1 SLEN+OLEN+2 710 +-------------+-------------+ 711 | Data length (0 or 16 bits)| 712 | Optional(maybe 0 bytes) | 713 +------------+--------------+ 715 The fields in the STREAM frame header are as follows: 717 o Frame Type: The Frame Type byte is an 8-bit value containing 718 various flags (1fdooossB): 720 * The leftmost bit must be set to 1 indicating that this is a 721 STREAM frame. 723 * The 'f' bit is the FIN bit. When set to 1, this bit indicates 724 the sender is done sending on this stream and wishes to "half- 725 close" (described in more detail later.) 727 * which is described in more detail later in this document. 729 * The 'd' bit indicates whether a Data Length is present in the 730 STREAM header. When set to 0, this field indicates that the 731 STREAM frame extends to the end of the Packet. 733 * The next three 'ooo' bits encode the length of the Offset 734 header field as 0, 16, 24, 32, 40, 48, 56, or 64 bits long. 736 * The next two 'ss' bits encode the length of the Stream ID 737 header field as 8, 16, 24, or 32 bits long. 739 o Stream ID: A variable-sized unsigned ID unique to this stream. 741 o Offset: A variable-sized unsigned number specifying the byte 742 offset in the stream for this block of data. 744 o Data length: An optional 16-bit unsigned number specifying the 745 length of the data in this stream frame. The option to omit the 746 length should only be used when the packet is a "full-sized" 747 Packet, to avoid the risk of corruption via padding. 749 A stream frame must always have either non-zero data length or the 750 FIN bit set. 752 8.3. ACK Frame 754 The ACK frame is sent to inform the peer which packets have been 755 received, as well as which packets are still considered missing by 756 the receiver (the contents of missing packets may need to be resent). 757 The design of QUIC's ACK frame is different from TCP's and SCTP's 758 SACK representations in that QUIC ACKs indicate the largest sequence 759 number observed thus far followed by a list of missing packet, or 760 NACK, ranges indicating gaps in packets received below this sequence 761 number. To limit the NACK ranges to the ones that haven't yet been 762 communicated to the peer, the peer periodically sends STOP_WAITING 763 frames that signal the receiver to stop waiting for packets below a 764 specified squence number, raising the "least unacked" sequence number 765 at the receiver. A sender of an ACK frame thus reports only those 766 NACK ranges between the received least unacked and the reported 767 largest observed sequence numbers. The frame is as follows: 769 0 1 N 770 +--------+--------+---------------------------------------------------+ 771 |Type (8)|Received| Largest Observed (8, 16, 32, or 48 bits) | 772 | |Entropy | (variable length) | 773 +--------+--------+---------------------------------------------------+ 775 N+1 N+2 N+3 N+4 N+8 777 +--------+--------+---------+--------+--------------------------------+ 778 |Largest Observed | Num | Delta | Time Since Largest Observed | 779 | Delta Time (16) |Timestamp|Largest | | 780 | | | (8) |Observed| | 781 +--------+--------+---------+--------+--------------------------------+ 783 N+9 N+11 - X 784 +--------+------------------+ 785 | Delta | Time | 786 |Largest | Since Previous | 787 |Observed|Timestamp (Repeat)| 788 +--------+------------------+ 789 X X+1 - Y Y+1 790 +--------+-------------------------------------------------+--------+ 791 | Number | Missing Packet Sequence Number Delta | Range | 792 | Ranges | (repeats Number Ranges times with Range Length) | Length | 793 | (opt) | |(Repeat)| 794 +--------+-------------------------------------------------+--------+ 796 Y+2 Y+3 - Z 797 +--------+-----------------------------------------------------+ 798 | Number | Revived Packet (8, 16, 32, or 48 bits) | 799 | Revived| Sequence Number (variable length) | 800 | (opt) | (repeats Number Revied times) | 801 +--------+-----------------------------------------------------+ 803 The fields in the ACK frame are as follows: 805 o Frame Type: The Frame Type byte is an 8-bit value containing 806 various flags (01ntllmmB). 808 * The first two bits must be set to 01 indicating that this is an 809 ACK frame. 811 * The 'n' bit indicates whether the frame has any NACK ranges. 813 * The 't' bit indicates whether the ACK frame has been truncated. 814 Truncation can happen when the complete ACK frame does not fit 815 within a single QUIC Packet, or when the number of NACK ranges 816 exceeds the maximum number of reportable NACK ranges (255). 818 When truncated, the ACK frame limits the largest observed 819 sequence number to the largest that can be reported, even 820 though the receiver may have received packets with sequence 821 numbers larger than the largest observed. 823 * The two 'll' bits encode the length of the Largest Observed 824 field as 1, 2, 4, or 6 bytes long. 826 * The two 'mm' bits encode the length of the Missing Packet 827 Sequence Number Delta field as 1, 2, 4, or 6 bytes long. 829 o Received Entropy: An 8 bit unsigned value specifying the 830 cumulative hash of entropy in all received packets up to the 831 largest observed packet. Entropy accumulation is described later 832 in this section. 834 o Largest Observed: A variable-sized unsigned value representing the 835 largest sequence number the peer has observed. When an ACK frame 836 is truncated, it indicates a sequence number greater than the 837 specified largest observed has been received, but information 838 about those additional receptions can't fit into this frame 839 (typically due to packet size restrictions). 841 o Largest Observed Delta Time: A 16 bit unsigned float with 11 842 explicit bits of mantissa and 5 bits of explicit exponent, 843 specifying the time elapsed in microseconds from when largest 844 observed was received until this Ack frame was sent. The bit 845 format is loosely modeled after IEEE 754. For example, 1 846 microsecond is represented as 0x1, which has an exponent of zero, 847 presented in the 5 high order bits, and mantissa of 1, presented 848 in the 11 low order bits. When the explicit exponent is greater 849 than zero, an implicit high-order 12th bit of 1 is assumed in the 850 mantissa. For example, a floatingvalue of 0x800 has an explicit 851 exponent of 1, as well as an explicit mantissa of 0, but then has 852 an effective mantissa of 4096 (12th bit is assumed to be 1). 853 Additionally, the actual exponent is one-less than the explicit 854 exponent, and the value represents 4096 microseconds. Any values 855 larger than the representable range are clamped to 0xFFFF. 857 o Num Timestamp: An 8-bit unsigned value specifying the number of 858 TCP timestamps that are included in this frame. There will be 859 this many pairs of following in the 860 timestamps. 862 o Delta Largest Observed: An 8-bit unsigned value specifying the 863 sequence number delta from the first timestamp to the largest 864 observed. 866 o Time Since Largest Observed: A 32-bit unsigned value specifying 867 the first timestamp. This is the time delta in microseconds from 868 the time the receiver's packet framer was created. 870 o Time Since Previous Timestamp: A 16-bit unsigned value specifying 871 the first timestamp. This is the time delta from the previous 872 timestamp. 874 o Num Ranges: An optional 8-bit unsigned value specifying the number 875 of missing packet ranges between largest observed and least 876 unacked. Only present if the 'n' flag bit is 1. 878 o Missing Packet Sequence Number Delta: A variable-sized sequence 879 number delta. For the first missing packet range, it is a delta 880 from the largest observed. For subsequent nack ranges, it is the 881 number of packets received between ranges. In the case of the 882 first nack range, a value of 0 specifies that the packet reported 883 as the largest observed is missing. In the case of the later nack 884 ranges, a value of 0 indicates the missing packet ranges are 885 contiguous (used only when more than 256 packets in a row were 886 lost). 888 o Range Length: An 8-bit unsigned value specifying one less than the 889 number of sequential nacks in the range. 891 o Num Revived: An 8-bit unsigned value specifying the number of 892 revived packets, recovered via FEC. Just like the Num Ranges 893 field, this field is only present if the 'n' flag bit is 1. 895 o Revived Packet Sequence Number: A variable-sized unsigned value 896 representing a packet the peer has revived via FEC. Its length is 897 the same as the length of the Largest Observed field. All 898 sequence numbers in this list are sorted in ascending order 899 (smallest first) and must also be present in the list of NACK 900 ranges. 902 8.3.1. Entropy Accumulation 904 The entropy bits for a subset of packets (known to a receiver or 905 sender) are accumulated into an 8 bit unsigned value, and similarly 906 presented in both a STOP_WAITING frame and an ACK frame. If we 907 defined E(k) to be the FLAG_ENTROPY bit present in packet sequence 908 number k, then the k'th packet's contribution C(k) is defined to be 909 E(k) left shifted by k mod 8 bits. The accumulated entropy is then 910 the bitwise-XOR sum of the contributions C(k), for all packets in the 911 desired subset. 913 8.4. STOP_WAITING Frame 915 The STOP_WAITING frame is sent to inform the peer that it should not 916 continue to wait for packets with sequence numbers lower than a 917 specified value. The sequence number is encoded in 1, 2, 4 or 6 918 bytes, using the same coding length as is specified for the sequence 919 number for the enclosing packet's header (specified in the QUIC Frame 920 Packet's Public Flags field.) The frame is as follows: 922 0 1 2 3 4 5 6 7 923 +--------+--------+--------+--------+--------+--------+-------+-------+ 924 |Type (8)|Sent | Least unacked delta (8, 16, 32, or 48 bits) | 925 | |Entropy | (variable length) | 926 +--------+--------+--------+--------+--------+--------+-------+-------+ 928 The fields in the STOP_WAITING frame are as follows: 930 o Frame Type: The Frame Type byte is an 8-bit value that must be set 931 to 0x06 indicating that this is a STOP_WAITING frame. 933 o Sent Entropy: An 8-bit unsigned value specifying the cumulative 934 hash of entropy in all sent packets up to the packet with sequence 935 number one less than the least unacked packet. [See "Entropy 936 Accumulation" section in the ACK frame section for details of this 937 calculation.] 939 o Least Unacked Delta: A variable length sequence number delta with 940 the same length as the packet header's sequence number. In the 941 case of an FEC revived packet, the same length as the other 942 packets in the FEC group. Subtract it from the header's packet 943 sequence number to determine the least unacked. The resulting 944 least unacked is the smallest sequence number of any packet for 945 which the sender is still awaiting an ack. If the receiver is 946 missing any packets smaller than this value, the receiver should 947 consider those packets to be irrecoverably lost. 949 8.5. WINDOW_UPDATE Frame 951 The WINDOW_UPDATE frame is used to inform the peer of an increase in 952 an endpoint's flow control receive window. The stream ID can be 0, 953 indicating this WINDOW_UPDATE applies to the connection level flow 954 control window, or > 0 indicating that the specified stream should 955 increase its flow control window. The frame is as follows: 957 An absolute byte offset is specified, and the receiver of a 958 WINDOW_UPDATE frame may only send up to that number of bytes on the 959 specified stream. Violating flow control by sending further bytes 960 will result in the receiving endpoint closing the connection. 962 On receipt of multiple WINDOW_UPDATE frames for a specific stream ID, 963 it is only necessary to keep track of the maximum byte offset. 965 Both stream and session windows start with a default value of 16 KB, 966 but this is typically increased during the handshake. To do this, an 967 endpoint should include SFCW (Stream Flow Control Window) and CFCW 968 (Connection/Session Flow Control Window) tags in the CHLO/SHLO (tags 969 are described in the QUIC Crypto document). The value associated 970 with each tag should be the number of bytes for initial stream window 971 and initial connection window respectively. 973 The frame is as follows: 975 0 1 4 5 12 976 +--------+--------+-- ... --+-------+--------+-- ... --+-------+ 977 |Type(8) | Stream ID (32 bits) | Byte offset (64 bits) | 978 +--------+--------+-- ... --+-------+--------+-- ... --+-------+ 980 The fields in the WINDOW_UPDATE frame are as follows: 982 o Frame Type: The Frame Type byte is an 8-bit value that must be set 983 to 0x04 indicating that this is a WINDOW_UPDATE frame. 985 o Stream ID: ID of the stream whose flow control windows is begin 986 updated, or 0 to specify the connection-level flow control window. 988 o Byte offset: A 64-bit unsigned integer indicating the absolute 989 byte offset of data which can be sent on the given stream. In the 990 case of connection level flow control, the cumulative number of 991 bytes which can be sent on all currently open streams. 993 8.6. BLOCKED Frame 995 The BLOCKED frame is used to indicate to the remote endpoint that 996 this endpoint is ready to send data (and has data to send), but is 997 currently flow control blocked. This is a purely informational 998 frame, which is extremely useful for debugging purposes. A receiver 999 of a BLOCKED frame should simply discard it (after possibly printing 1000 a helpful log message). The frame is as follows: 1002 0 1 2 3 4 1003 +--------+--------+--------+--------+--------+ 1004 |Type(8) | Stream ID (32 bits) | 1005 +--------+--------+--------+--------+--------+ 1007 The fields in the BLOCKED frame are as follows: 1009 o Frame Type: The Frame Type byte is an 8-bit value that must be set 1010 to 0x05 indicating that this is a BLOCKED frame. 1012 o Stream ID: A 32-bit unsigned number indicating the stream which is 1013 flow control blocked. A non-zero Stream ID field specifies the 1014 stream that is flow control blocked. When zero, the Stream ID 1015 field indicates that the connection is flow control blocked at the 1016 connection level. 1018 8.7. CONGESTION_FEEDBACK Frame 1020 The CONGESTION_FEEDBACK frame is an experimental frame currently not 1021 used. It is intended to provide extra congestion feedback 1022 information outside the scope of the standard ack frame. A 1023 CONGESTION_FEEDBACK frame must have the first three bits of the Frame 1024 Type set to 001. The last 5 bits of the Frame Type field are 1025 reserved for future use. 1027 8.8. PADDING Frame 1029 The PADDING frame pads a packet with 0x00 bytes. When this frame is 1030 encountered, the rest of the packet is expected to be padding bytes. 1031 The frame contains 0x00 bytes and extends to the end of the QUIC 1032 packet. A PADDING frame only has a Frame Type field, and must have 1033 the 8-bit Frame Type field set to 0x00. 1035 8.9. RST_STREAM Frame 1037 The RST_STREAM frame allows for abnormal termination of a stream. 1038 When sent by the creator of a stream, it indicates the creator wishes 1039 to cancel the stream. When sent by the receiver of a stream, it 1040 indicates an error or that the receiver did not want to accept the 1041 stream, so the stream should be closed. The frame is as follows: 1043 0 1 4 5 12 8 16 1044 +-------+--------+-- ... ----+--------+-- ... ------+-------+-- ... ------+ 1045 |Type(8)| StreamID (32 bits) | Byte offset (64 bits)| Error code (32 bits)| 1046 +-------+--------+-- ... ----+--------+-- ... ------+-------+-- ... ------+ 1048 The fields in a RST_STREAM frame are as follows: 1050 o Frame type: The Frame Type is an 8-bit value that must be set to 1051 0x04 specifying that this is a RST_STREAM frame. 1053 o Stream ID: The 32-bit Stream ID of the stream being terminated. 1055 o Byte offset: A 64-bit unsigned integer indicating the absolute 1056 byte offset of the end of data for this stream. 1058 o Error code: A 32-bit QuicErrorCode which indicates why the stream 1059 is being closed. QuicErrorCodes are listed later in this 1060 document. 1062 8.10. PING frame 1064 The PING frame can be used by an endpoint to verify that a peer is 1065 still alive. The PING frame contains no payload. The receiver of a 1066 PING frame simply needs to ACK the packet containing this frame. The 1067 PING frame should be used to keep a connection alive when a stream is 1068 open. The default is to do this after 15 seconds of quiescence, 1069 which is much shorter than most NATs time out. A PING frame only has 1070 a Frame Type field, and must have the 8-bit Frame Type field set to 1071 0x07. 1073 8.11. CONNECTION_CLOSE frame 1075 The CONNECTION_CLOSE frame allows for notification that the 1076 connection is being closed. If there are streams in flight, those 1077 streams are all implicitly closed when the connection is closed. 1078 (Ideally, a GOAWAY frame would be sent with enough time that all 1079 streams are torn down.) The frame is as follows: 1081 0 1 4 5 6 7 1082 +--------+--------+-- ... -----+--------+--------+--------+----- ... 1083 |Type(8) | Error code (32 bits)| Reason phrase | Reason phrase 1084 | | | length (16 bits)|(variable length) 1085 +--------+--------+-- ... -----+--------+--------+--------+----- ... 1087 The fields of a CONNECTION_CLOSE frame are as follows: 1089 o Frame Type: An 8-bit value that must be set to 0x02 specifying 1090 that this is a CONNECTION_CLOSE frame. 1092 o Error Code: A 32-bit field containing the QuicErrorCode which 1093 indicates the reason for closing this connection. 1095 o Reason Phrase Length: A 16-bit unsigned number specifying the 1096 length of the reason phrase. This may be zero if the sender 1097 chooses to not give details beyond the QuicErrorCode. 1099 o Reason Phrase: An optional human-readable explanation for why the 1100 connection was closed. 1102 8.12. GOAWAY Frame 1104 The GOAWAY frame allows for notification that the connection should 1105 stop being used, and will likely be aborted in the future. Any 1106 active streams will continue to be processed, but the sender of the 1107 GOAWAY will not initiate any additional streams, and will not accept 1108 any new streams. The frame is as follows: 1110 0 1 4 5 6 7 8 1111 +--------+--------+-- ... -----+-------+-------+-------+------+ 1112 |Type(8) | Error code (32 bits)| Last Good Stream ID (32 bits)| -> 1113 +--------+--------+-- ... -----+-------+-------+-------+------+ 1115 9 10 11 1116 +--------+--------+--------+----- ... 1117 | Reason phrase | Reason phrase 1118 | length (16 bits)|(variable length) 1119 +--------+--------+--------+----- ... 1121 The fields of a GOAWAY frame are as follows: 1123 o Frame type: An 8-bit value that must be set to 0x06 specifying 1124 that this is a GOAWAY frame. 1126 o Error Code: A 32-bit field containing the QuicErrorCode which 1127 indicates the reason for closing this connection. 1129 o Last Good Stream ID: The last Stream ID which was accepted by the 1130 sender of the GOAWAY message. If no streams were replied to, this 1131 value must be set to 0. 1133 o Reason Phrase Length: A 16-bit unsigned number specifying the 1134 length of the reason phrase. This may be zero if the sender 1135 chooses to not give details beyond the error code. 1137 o Reason Phrase: An optional human-readable explanation for why the 1138 connection was closed. 1140 9. Quic Connection Negotiation Tags 1142 (TODO: List Tags.) 1144 10. QuicErrorCodes 1146 The number to code mappings for QuicErrorCodes are currently defined 1147 in the Chromium source code in src/net/quic/quic_protocol.h. (TODO: 1148 hardcode numbers and add them here) 1149 o QUIC_NO_ERROR: There was no error. This is not valid for 1150 RST_STREAM frames or CONNECTION_CLOSE frames 1152 o QUIC_STREAM_DATA_AFTER_TERMINATION: There were data frames after 1153 the a fin or reset. 1155 o QUIC_SERVER_ERROR_PROCESSING_STREAM: There was some server error 1156 which halted stream processing. 1158 o QUIC_MULTIPLE_TERMINATION_OFFSETS: The sender received two 1159 mismatching fin or reset offsets for a single stream. 1161 o QUIC_BAD_APPLICATION_PAYLOAD: The sender received bad application 1162 data. 1164 o QUIC_INVALID_PACKET_HEADER: The sender received a malformed packet 1165 header. 1167 o QUIC_INVALID_FRAME_DATA: The sender received an frame data. The 1168 more detailed error codes below are prefered where possible. 1170 o QUIC_INVALID_FEC_DATA: FEC data is malformed. 1172 o QUIC_INVALID_RST_STREAM_DATA: Stream rst data is malformed 1174 o QUIC_INVALID_CONNECTION_CLOSE_DATA: Connection close data is 1175 malformed. 1177 o QUIC_INVALID_ACK_DATA: Ack data is malformed. 1179 o QUIC_DECRYPTION_FAILURE: There was an error decrypting. 1181 o QUIC_ENCRYPTION_FAILURE: There was an error encrypting. 1183 o QUIC_PACKET_TOO_LARGE: The packet exceeded MaxPacketSize. 1185 o QUIC_PACKET_FOR_NONEXISTENT_STREAM: Data was sent for a stream 1186 which did not exist. 1188 o QUIC_CLIENT_GOING_AWAY: The client is going away (browser close, 1189 etc.) 1191 o QUIC_SERVER_GOING_AWAY: The server is going away (restart etc.) 1193 o QUIC_INVALID_STREAM_ID: A stream ID was invalid. 1195 o QUIC_TOO_MANY_OPEN_STREAMS: Too many streams already open. 1197 o QUIC_CONNECTION_TIMED_OUT: We hit our pre-negotiated (or default) 1198 timeout 1200 o QUIC_CRYPTO_TAGS_OUT_OF_ORDER: Handshake message contained out of 1201 order tags. 1203 o QUIC_CRYPTO_TOO_MANY_ENTRIES: Handshake message contained too many 1204 entries. 1206 o QUIC_CRYPTO_INVALID_VALUE_LENGTH: Handshake message contained an 1207 invalid value length. 1209 o QUIC_CRYPTO_MESSAGE_AFTER_HANDSHAKE_COMPLETE: A crypto message was 1210 received after the handshake was complete. 1212 o QUIC_INVALID_CRYPTO_MESSAGE_TYPE: A crypto message was received 1213 with an illegal message tag. 1215 o QUIC_SEQUENCE_NUMBER_LIMIT_REACHED: Transmitting an additional 1216 packet would cause a sequence number to be reused. 1218 11. Priority 1220 (TODO: implement) 1222 QUIC will use the HTTP/2 prioritization mechanism. Roughly, a stream 1223 may be dependent on another stream. In this situation, the "parent" 1224 stream should effectively starve the "child" stream. In addition, 1225 parent streams have an explicit priority. Parent streams should not 1226 starve other parent streams, but should make progress proportional to 1227 their relative priority. 1229 12. HTTP/2 Layering over QUIC 1231 Since QUIC integrates various HTTP/2 mechanisms with transport 1232 mechanisms, QUIC implements a number of features that are also 1233 specified in HTTP/2. As a result, QUIC allows HTTP/2 mechanisms to 1234 be replaced by QUIC's implementation, reducing complexity in the 1235 HTTP/2 protocol. This section briefly describes how HTTP/2 semantics 1236 can be offered over a QUIC implementation. 1238 12.1. Stream Management 1240 When HTTP/2 headers and data are sent over QUIC, the QUIC layer 1241 handles most of the stream management. HTTP/2 Stream IDs are 1242 replaced by QUIC Stream IDs. HTTP/2 does not need to do any explicit 1243 stream framing when using QUIC---data sent over a QUIC stream simply 1244 consists of HTTP/2 headers or body. Requests and responses are 1245 considered complete when the QUIC stream is closed in the 1246 corresponding direction. 1248 Stream flow control is handled by QUIC, and does not need to be re- 1249 implemented in HTTP/2. QUIC's flow controller replaces the two 1250 levels of poorly matched flow controllers in current HTTP/2 1251 deployments---one at the HTTP/2 level, and the other at the TCP 1252 level. 1254 12.2. HTTP/2 Header Compression 1256 QUIC implements HPACK header compression [3] for HTTP/2, which 1257 unfortunately introduces some Head-of-Line blocking since HTTP/2 1258 header blocks must be decompressed in the order they were compressed. 1260 Since streams may be processed in arbitrary order at a receiver, 1261 strict ordering across headers is enforced by sending all headers on 1262 a dedicated headers stream, with Stream ID 3. An HTTP/2 receiver 1263 using QUIC would thus process data from a stream only after receiving 1264 the corresponding header on the headers stream. 1266 Future work will tweak the compressor and decompressor in QUIC so 1267 that the compressed output does not depend on unacked previous 1268 compressed state. This could be done, perhaps, by creating 1269 "checkpoints" of HPACK state which are updated when headers have been 1270 acked. When compressing headers QUIC would only compress relative to 1271 the previous "checkpoint". 1273 12.3. Parsing HTTP/2 Headers 1275 HTTP/2 uses a SYN stream to create new streams and to negotiate 1276 various stream parameters, including stream priority. Since stream 1277 creation is implicit in QUIC, there is no equivalent of a SYN stream. 1278 Also, since there is no explicit stream priority in QUIC, the current 1279 HTTP/2 mapping on QUIC communicates HTTP/2 stream priority by 1280 prepending it to the beginning of the HTTP/2 headers in the headers 1281 stream. Each HTTP/2 header sent on the headers stream is as follows: 1283 0 3 4 7 8 11 12 1284 +--------+- ... ---+--------+- ... --+--------+- ... ---+------ ... 1285 | Priority | Stream ID | Headers length | Headers 1286 +--------+- ... ---+--------+- ... --+--------+- ... ---+------ ... 1288 Priority type: A 32-bit unsigned number specifying the stream's 1289 HTTP/2 priority 1291 Stream ID: A 32-bit unsigned number specifying the QUIC Stream ID 1292 associated with this HTTP/2 header 1293 Headers length: A 32-bit unsigned number encoding the length, in 1294 bytes, of the compressed headers to follow 1296 Headers: HTTP/2 compressed headers 1298 12.4. Persistent Connections 1300 Unlike when using TCP, the underlying connection for QUIC is 1301 guaranteed to be persistent. The HTTP "Connection" header is 1302 therefore does not apply. For best performance, it is expected that 1303 clients will not close a QUIC connection until the user navigates 1304 away from all web pages using that connection, or until the server 1305 closes the connection. 1307 12.5. QUIC Negotiation in HTTP 1309 The Alternate-Protocol header is used to negotiate use of QUIC on 1310 future HTTP requests. To specify QUIC as an alternate protocol 1311 available on port 123, a server uses: 1313 "Alternate-Protocol: 123:quic" 1315 When a client receives a Alternate-Protocol header advertising QUIC, 1316 it can then attempt to use QUIC for future secure connections on that 1317 domain. Since middleboxes and/or firewalls can block QUIC and/or UDP 1318 communication, a client should implement a graceful fallback to TCP 1319 when QUIC reachability is broken. 1321 Note that the server may reply with multiple field values or a comma- 1322 separated field value for Alternate-Protocol to indicate the various 1323 transports it supports. 1325 A server can also send a header to notify that QUIC should not be 1326 used on this domain. If it sends the alternate-protocol-required 1327 header, the client should remember to not use QUIC on that domain in 1328 future, and not do any UDP probing to see if QUIC is available. 1330 13. Recent Changes By Version 1332 o Q009: added priority as the first 4 bytes on spdy streams. 1334 o Q010: renumber the various frame types 1336 o Q011: shrunk the fnv128 hash on NULL encrypted packets from 16 1337 bytes to 12 bytes. 1339 o Q012: optimize the ack frame format to reduce the size and better 1340 handle ranges of nacks, which should make truncated acks virtually 1341 impossible. Also adding an explicit flag for truncated acks and 1342 moving the ack outside of the connection close frame. 1344 o Q013: Compressed headers for *all* data streams are serialized 1345 into a reserved stream. This ensures serialized handling of 1346 headers, independent of stream cancellation notification. 1348 o Q014: Added WINDOW_UPDATE and BLOCKED frames, no behavioral 1349 change. 1351 o Q015: Removes the accumulated_number_of_lost_packets field from 1352 the TCP and inter arrival congestion feedback frames and adds an 1353 explicit list of recovered packets to the ack frame. 1355 o Q016: Breaks out the sent_info field from the ACK frame into a new 1356 STOP_WAITING frame. 1358 o Changed GUID to Connection ID 1360 o Q017: Adds stream level flow control 1362 o Q018: Added a PING frame 1364 o Q019: Adds session/connection level flow control 1366 o Q020: Allow endpoints to set different stream/session flow control 1367 windows 1369 o Q021: Crypto and headers streams are flow controlled (at stream 1370 level) 1372 o Q023: Ack frames include packet timestamps 1374 o Q024: HTTP/2-style header compression 1376 o Q025: HTTP/2-style header keys. Removal of error_details from the 1377 RST_STREAM frame. 1379 . 1381 14. References 1383 14.1. Normative References 1385 [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate 1386 Requirement Levels", March 1997. 1388 14.2. Informative References 1390 [RFC7540] Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer 1391 Protocol Version 2 (HTTP/2)", May 2015. 1393 [QUIC-CRYPTO] 1394 Langley, A. and W. Chang, "QUIC Crypto", June 2015. 1396 [QUIC-CC] Swett, I. and J. Iyengar, "QUIC Loss Recovery and 1397 Congestion Control", June 2015. 1399 14.3. URIs 1401 [1] https://www.chromium.org/quic 1403 [2] http://goo.gl/jOvOQ5 1405 [3] http://http2.github.io/http2-spec/compression.html 1407 Authors' Addresses 1409 Ryan Hamilton 1410 Google 1412 Email: rch@google.com 1414 Janardhan Iyengar 1415 Google 1417 Email: jri@google.com 1419 Ian Swett 1420 Google 1422 Email: ianswett@google.com 1424 Alyssa Wilk 1425 Google 1427 Email: alyssar@google.com