idnits 2.17.1 draft-tsvwg-quic-protocol-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 "Q015" 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 (June 17, 2015) is 3236 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 1386 -- Looks like a reference, but probably isn't: '2' on line 1388 -- Looks like a reference, but probably isn't: '3' on line 1390 == Unused Reference: 'RFC2119' is defined on line 1370, but no explicit reference was found in the text == Unused Reference: 'QUIC-CC' is defined on line 1381, 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 J. Iyengar 3 Internet-Draft I. Swett 4 Intended status: Informational Google 5 Expires: December 19, 2015 June 17, 2015 7 QUIC: A UDP-Based Secure and Reliable Transport for HTTP/2 8 draft-tsvwg-quic-protocol-00 10 Abstract 12 QUIC (Quick UDP Internet Connection) is a new multiplexed and secure 13 transport atop UDP, designed from the ground up and optimized for 14 HTTP/2 semantics. While built with HTTP/2 as the primary application 15 protocol, QUIC builds on decades of transport and security 16 experience, and implements mechanisms that make it attractive as a 17 modern general-purpose transport. QUIC provides multiplexing and 18 flow control equivalent to HTTP/2, security equivalent to TLS, and 19 connection semantics, reliability, and congestion control equivalent 20 to TCP. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on December 19, 2015. 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 1. Contributors 56 This document and protocol is the outcome of work by several 57 engineers at Google. 59 2. Introduction 61 QUIC (Quick UDP Internet Connection) is a new multiplexed and secure 62 transport atop UDP, designed from the ground up and optimized for 63 HTTP/2 semantics. While built with HTTP/2 as the primary application 64 protocol, QUIC builds on decades of transport and security 65 experience, and implements mechanisms that make it attractive as a 66 modern general-purpose transport. QUIC provides multiplexing and 67 flow control equivalent to HTTP/2, security equivalent to TLS, and 68 connection semantics, reliability, and congestion control equivalent 69 to TCP. 71 QUIC operates entirely in userspace, and is currently shipped to 72 users as a part of the Chromium browser, enabling rapid deployment 73 and experimentation. As a userspace transport atop UDP, QUIC allows 74 innovations which have proven difficult to deploy with existing 75 protocols as they are hampered by legacy clients and middleboxes, or 76 by prolonged Operating System development and deployment cycles. 78 An important goal for QUIC is to inform better transport design 79 through rapid experimentation. As a result, we hope to inform and 80 where possible migrate distilled changes into TCP and TLS, which tend 81 to have much longer iteration cycles. 83 This document describes the conceptual design and the wire 84 specification of the QUIC protocol. Accompanying documents describe 85 the combined crypto and transport handshake [QUIC-CRYPTO], and loss 86 recovery and congestion control [draft-quic-loss-recovery]. 87 Additional resources, including a more detailed rationale document, 88 are available on the Chromium QUIC webpage [1]. 90 3. Conventions and Definitions 92 All integer values used in QUIC, including length, version, and type, 93 are in little-endian byte order, and not in network byte order. QUIC 94 does not enforce alignment of types in dynamically sized frames. 96 A few terms that are used throughout this document are defined below. 98 o "Client": The endpoint initiating a QUIC connection. 100 o "Server": The endpoint accepting incoming QUIC connections. 102 o "Endpoint": The client or server end of a connection. 104 o "Stream": A bi-directional flow of bytes across a logical channel 105 within a QUIC connection. 107 o "Connection": A conversation between two QUIC endpoints with a 108 single encryption context that multiplexes streams within it. 110 o "Connection ID": The identifier for a QUIC connection. 112 o "QUIC Packet": A well-formed UDP payload that can be parsed by a 113 QUIC receiver. QUIC packet size in this document refers to the 114 UDP payload size. 116 4. A QUIC Overview 118 We now briefly describe QUIC's key mechanisms and benefits. QUIC is 119 functionally equivalent to TCP+TLS+HTTP/2, but implemented on top of 120 UDP. Key advantages of QUIC over TCP+TLS+HTTP/2 include: 122 o Connection establishment latency 124 o Flexible congestion control 126 o Multiplexing without head-of-line blocking 128 o Authenticated and Encrypted Header and Payload 130 o Stream and Connection Flow Control 132 o Forward error correction 134 o Connection migration 136 4.1. Connection Establishment Latency 138 For a complete description of connection establishment, please see 139 the QUIC Crypto design [2] document. Briefly, QUIC handshakes 140 frequently require zero roundtrips before sending payload, as 141 compared to 1-3 roundtrips for TCP+TLS. 143 The first time a QUIC client connects to a server, the client must 144 perform a 1-roundtrip handshake in order to acquire the necessary 145 information to complete the handshake. The client sends an inchoate 146 (empty) client hello (CHLO), the server sends a rejection (REJ) with 147 the information the client needs to make forward progress. This 148 information includes a source address token, which is used to verify 149 the client's IP on a subsequent CHLO, and the server's certificates. 150 The next time the client sends a CHLO, it can use the cached 151 credentials from the previous connection to immediately send 152 encrypted requests to the server. 154 4.2. Flexible Congestion Control 156 QUIC has pluggable congestion control, and richer signaling than TCP 157 means that it can provide richer information to the congestion 158 control algorithm than TCP. Currently, Google's implementation of 159 QUIC uses a reimplementation of TCP Cubic; we are currently 160 experimenting with alternative approaches. 162 One example of richer information is that each packet, both original 163 and retransmitted, carries a new sequence number. This allows a QUIC 164 sender to distinguish ACKs for retransmissions from ACKs for original 165 transmissions, thus avoiding TCP's retransmission ambiguity problem. 166 QUIC ACKs also explicitly carry the delay between the receipt of a 167 packet and its acknowledgment being sent, and together with the 168 monotonically-increasing sequence numbers, this allows for precise 169 roundtrip-time (RTT) calculation. 171 Finally, QUIC's ACK frames support up to 256 NACK ranges, so QUIC is 172 more resilient to reordering than TCP (with SACK), as well as able to 173 keep more bytes on the wire when there is reordering or loss. Both 174 client and server have a more accurate picture of which packets the 175 peer has received. 177 4.3. Stream and Connection Flow Control 179 QUIC implements stream- and connection-level flow control, closely 180 following HTTP/2's flow control. QUIC's stream-level flow control 181 works as follows. A QUIC receiver advertises the absolute byte 182 offset within each stream upto which the receiver is willing to 183 receive data. As data is sent, received, and delivered on a 184 particular stream, the receiver sends WINDOW_UPDATE frames that 185 increase the advertised offset limit for that stream, allowing the 186 peer to send more data on that stream. 188 In addition to per-stream flow control, QUIC implements connection- 189 level flow control to limit the aggregate buffer that a QUIC receiver 190 is willing to allocate to a connection. Connection flow control 191 works in the same way as stream flow control, but the bytes delivered 192 and highest received offset are all aggregates across all streams. 194 Similar to TCP's receive-window autotuning, QUIC implements 195 autotuning of flow control credits for both stream and connection 196 flow controllers. QUIC's autotuning increases the size of the 197 credits sent per WINDOW_UPDATE frame if it appears to be limiting the 198 sender's rate, and throttles the sender when the receiving 199 application is slow. 201 4.4. Multiplexing 203 HTTP/2 on TCP suffers from head-of-line blocking in TCP. Since 204 HTTP/2 multiplexes many streams atop TCP's single-bytestream 205 abstraction, a loss of a TCP segment results in blocking of all 206 subsequent segments until a retransmission arrives, irrespective of 207 the HTTP/2 stream that is encapsulated in subsequent segments. 209 Because QUIC is designed from the ground up for multiplexed 210 operation, lost packets carrying data for an individual stream 211 generally only impact that specific stream. Each stream frame can be 212 immediately dispatched to that stream on arrival, so streams without 213 loss can continue to be reassembled and make forward progress in the 214 application. 216 Caveat: QUIC currently compresses HTTP headers via HTTP/2 HPACK 217 header compression, which imposes head-of-line blocking for header 218 frames only. 220 4.5. Authenticated and Encrypted Header and Payload 222 TCP headers appear in plaintext on the wire and not authenticated, 223 causing a plethora of injection and header manipulation issues for 224 TCP, such as receive-window manipulation and sequence-number 225 overwriting. While some of these are active attacks, others are 226 mechanisms used by middleboxes in the network sometimes in an attempt 227 to transparently improve TCP performance. However, even 228 "performance-enhancing" middleboxes still effectively limit the 229 evolvability of the transport protocol, as has been observed in the 230 design of MPTCP and in its subsequent deployability issues. 232 QUIC packets are always encrypted. While some parts of the packet 233 header are not encrypted, they are still authenticated by the 234 receiver so as to thwart any packet injection or manipulation by 235 third parties. QUIC protects connections from witting or unwitting 236 middlebox manipulation of end-to-end communication. 238 (Caveat:PUBLIC_RESET packets that reset a connection are currently 239 not authenticated.) 241 4.6. Forward Error Correction 243 In order to recover lost packets without waiting for a 244 retransmission, QUIC currently employs a simple XOR-based FEC scheme. 245 An FEC packet contains parity of the packets in the FEC group. If 246 one of the packets in the group is lost, the contents of that packet 247 can be recovered from the FEC packet and the remaining packets in the 248 group. The sender may decide whether to send FEC packets to optimize 249 specific scenarios (e.g., beginning and end of a request). 251 4.7. Connection Migration 253 TCP connections are identified by a 4-tuple of source address, source 254 port, destination address and destination port. A well-known problem 255 with TCP is that connections do not survive IP address changes (for 256 example, by switching from WiFi to cellular) or port number changes 257 (when a client's NAT binding expires causing a change in the port 258 number seen at the server). While MPTCP addresses the connection 259 migration problem for TCP, it is still plagued by lack of middlebox 260 support and lack of OS deployment. 262 QUIC connections are identified by a 64-bit Connection ID, randomly 263 generated by the client. QUIC can survive IP address changes and NAT 264 re-bindings since the Connection ID remains the same across these 265 migrations. QUIC also provides automatic cryptographic verification 266 of a migrating client, since a migrating client continues to use the 267 same session key for encrypting and decrypting packets. 269 5. Packet Types and Formats 271 QUIC has four packet types: Version Negotiation Packets, Frame 272 Packets, FEC Packets, and Public Reset Packets. All QUIC packets 273 should be sized to fit within the path's MTU to avoid IP 274 fragmentation. Path MTU discovery is a work in progress, and the 275 current QUIC implementation uses a 1350-byte maximum QUIC packet size 276 for IPv6, 1370 for IPv4. 278 5.1. QUIC Common Packet Header 280 All QUIC packets on the wire begin with a common header sized between 281 2 and 21 bytes. The wire format for the common header is as follows: 283 0 1 2 3 4 8 284 +--------+--------+--------+--------+--------+--- ---+ 285 | Public | Connection ID (0, 8, 32, or 64) ... | -> 286 |Flags(8)| (variable length) | 287 +--------+--------+--------+--------+--------+--- ---+ 289 9 10 11 12 290 +--------+--------+--------+--------+ 291 | Quic Version (32) | -> 292 | (optional) | 293 +--------+--------+--------+--------+ 295 13 14 15 16 17 18 19 20 296 +--------+--------+--------+--------+--------+--------+--------+--------+ 297 | Sequence Number (8, 16, 32, or 48) |Private | FEC (8)| 298 | (variable length) |Flags(8)| (opt) | 299 +--------+--------+--------+--------+--------+--------+--------+--------+ 301 QUIC packets are authenticated and encrypted. The first part of the 302 common header upto and including the Sequence Number field is 303 authenticated but not encrypted, and the rest of the packet starting 304 with the Private Flags field is encrypted. 306 The unencrypted payload may include various type-dependent header 307 bytes as described below. 309 The fields in the common header are the following: 311 o Public Flags: 313 * Bit at 0x01 is set to indicate that the packet contains a QUIC 314 Version. This bit must be set by a client in all packets until 315 confirmation from the server arrives agreeing to the proposed 316 version is received by the client. A server indicates 317 agreement on a version by sending packets without setting this 318 bit. Version Negotiation is described in more detail later. 320 * Bit at 0x02 is set to indicate that the packet is a Public 321 Reset packet. 323 * Two bits at 0x0C indicate the size of the Connection ID that is 324 present in the packet. These bits must be set to 0x0C in all 325 packets until negotiated to a different value for a given 326 direction (e.g., client may request fewer bytes of the 327 Connection ID be presented). 329 + 0x0C indicates an 8-byte Connection ID is present 330 + 0x08 indicates that a 4-byte Connection ID is present 332 + 0x04 indicates that a 1-byte Connection ID is used 334 + 0x00 indicates that the Connection ID is omitted 336 * Two bits at 0x30 indicate the number of low-order-bytes of the 337 packet sequence number that are present in each packet. The 338 bits are only used for Frame Packets. For Public Reset and 339 Version Negotiation Packets (sent by the server) which don't 340 have a sequence number, these bits are not used and must be set 341 to 0. Within this 2 bit mask: 343 + 0x30 indicates that 6 bytes of the sequence number is 344 present 346 + 0x20 indicates that 4 bytes of the sequence number is 347 present 349 + 0x10 indicates that 2 bytes of the sequence number is 350 present 352 + 0x00 indicates that 1 byte of the sequence number is present 354 * Two bits at 0xC0 are currently unused, and must be set to 0. 356 o Connection ID: This is an unsigned 64 bit statistically random 357 number selected by the client that is the identifier of the 358 connection. Because QUIC connections are designed to remain 359 established even if the client roams, the IP 4-tuple (source IP, 360 source port, destination IP, destination port) may be insufficient 361 to identify the connection. For each transmission direction, when 362 less uniqueness is sufficient to identify the connection, a 363 truncated transmitted Connection ID length is negotiable. 365 o QUIC Version: A 32 bit opaque tag that represents the version of 366 the QUIC protocol. Only present if the public flags contain 367 FLAG_VERSION (i.e public_flags & FLAG_VERSION !=0). A client may 368 set this flag, and include EXACTLY one proposed version, as well 369 as including arbitrary data (conforming to that version). A 370 server may set this flag when the client-proposed version was 371 unsupported,, and may then provide a list (0 or more) of 372 acceptable versions, but MUST not include any data after the 373 version(s). Examples of version values in recent experimental 374 versions include "Q015" which corresponds to byte 9 containing 375 'Q", byte 10 containing '0", etc. [See list of changes in various 376 versions listed at the end of this document.] 378 o Sequence Number: The lower 8, 16, 32, or 48 bits of the sequence 379 number, based on which FLAG_?BYTE_SEQUENCE_NUMBER flag is set in 380 the public flags. See "Sequence numbers" below. 382 o Private Flags: 384 * 0x01 = FLAG_ENTROPY - for data packets, signifies that this 385 packet contains the 1 bit of entropy, for fec packets, contains 386 the xor of the entropy of protected packets. 388 * 0x02 = FLAG_FEC_GROUP - indicates whether the fec byte is 389 present. 391 * 0x04 = FLAG_FEC - signifies that this packet represents an FEC 392 packet. 394 o FEC (FEC Group Number Offset): An FEC Group Number is the Packet 395 Sequence Number of the first packet in the FEC group. The FEC 396 Group Number Offset is an 8 bit unsigned value which should be 397 subtracted from the current packet's Packet Sequence Number to 398 yield the FEC Group Number for this packet. This is only present 399 if the private flags contain FLAG_FEC_GROUP. All packets within a 400 single FEC group must have Sequence Numbers encoded into an 401 identical number of bytes (i.e., the Sequence Number coding must 402 not change during a group) 404 o Sequence Number: Each QUIC Frame Packet (as opposed to public 405 reset and version negotiation packets) is assigned a sequence 406 number by the sender. The first packet sent by an endpoint shall 407 have a sequence number of 1, and each subsequent packet shall have 408 a sequence number one larger than that of the previous packet. 409 The lower 64 bits of the sequence number may be used as part of a 410 cryptographic nonce; therefore, a QUIC endpoint must not send a 411 packet with a sequence number that cannot be represented in 64 412 bits. If a QUIC endpoint transmits a packet with a sequence 413 number of (2^64-1), that packet must include a CONNECTION_CLOSE 414 frame with an error code of QUIC_SEQUENCE_NUMBER_LIMIT_REACHED, 415 and the endpoint must not transmit any additional packets. At 416 most the lower 48 bits of a sequence number are transmitted. To 417 enable unambiguous reconstruction of the sequence number by the 418 receiver, a QUIC endpoint must not transmit a packet whose 419 sequence number is larger by (2^(bitlength-2)) than the largest 420 sequence number for which an acknowledgement is known to have been 421 transmitted by the receiver. Therefore, there must never be more 422 than (2^46) packets in flight. Any truncated sequence number 423 shall be inferred to have the value closest to the one more than 424 the largest known sequence number of the endpoint which 425 transmitted the packet that originally contained the truncated 426 sequence number. The transmitted portion of the sequence number 427 matches the lowest bits of the inferred value. 429 5.2. Version Negotiation Packet 431 (Describe version negotiation packet.) 433 5.3. Frame Packet 435 Beyond the Common Header, Frame Packets have a payload that is a 436 series of type-prefixed frames. The format of frame types is defined 437 later in this document, but the general format of a Frame Packet is 438 as follows: 440 +--------+---...---+--------+---...---+ 441 | Type | Payload | Type | Payload | 442 +--------+---...---+--------+---...---+ 444 5.4. FEC Packet 446 FEC packets (those packets with FLAG_FEC set) have a payload that 447 simply contains an XOR of the null-padded payload of each Data Packet 448 in the FEC group. 450 +-----...----+ 451 | Redundancy | 452 +-----...----+ 454 5.5. Public Reset Packet 456 Public reset packets begin with an 8-bit public flags and 64-bit 457 Connection ID. The rest of the public reset packets is encoded as if 458 it were a crypto handshake message of the tag PRST (see accompanying 459 crypto document for more about QUIC Tags): 461 0 1 2 3 4 8 462 +--------+--------+--------+--------+--------+-- --+ 463 | Public | Connection ID (64) ... | -> 464 |Flags(8)| | 465 +--------+--------+--------+--------+--------+-- --+ 467 9 10 11 12 13 14 468 +--------+--------+--------+--------+--------+--------+--- 469 | Quic Tag (32) | Tag value map ... -> 470 | (PRST) | (variable length) 471 +--------+--------+--------+--------+--------+--------+--- 473 Tag value map: The tag value map contains the following tag-values: 475 o RNON (public reset nonce proof) - a 64-bit unsigned integer. 476 Mandatory. 478 o RSEQ (rejected sequence number) - a 64-bit sequence number. 479 Mandatory. 481 o CADR (client address) - the observed client IP address and port 482 number. Optional. 484 (TODO: Public Reset packet should include authenticated (destination) 485 server IP/port.) 487 6. Life of a QUIC Connection 489 6.1. Connection Establishment 491 A QUIC client is the endpoint that initiates a connection. QUIC's 492 connection establishment intertwines version negotiation with the 493 crypto and transport handshakes to reduce connection establishment 494 latency. We first describe version negotiation below. 496 (Describe Version Negotiation.) 498 The rest of the connection establishment is described in the crypto 499 handshake document [QUIC-CRYPTO]. The crypto handshake is 500 encapsulated within Frame Packets, as stream data on the crypto 501 stream (described later in this section). 503 During connection establishment, QUIC sends various "Tags" inside the 504 handshake packets for negotiating transport parameters. The 505 currently used Tags are described later in the document. 507 6.2. Data Transfer 509 QUIC implements connection reliability, congestion control, and flow 510 control. QUIC flow control closely follows HTTP/2's flow control. 511 QUIC reliability and congestion control are described in an 512 accompanying document. A QUIC connection uses a single packet 513 sequence number space for shared congestion control and loss recovery 514 across the connection. 516 All data transferred in a QUIC connection, including the crypto 517 handshake, is sent as data inside streams, but the ACKs acknowledge 518 QUIC Packets. 520 This section conceptually describes the use of streams for data 521 transfer within a QUIC connection. The various frames that are 522 mentioned in this section are described in the section on Frame Types 523 and Formats. 525 6.2.1. Life of a QUIC Stream 527 Streams are independent sequences of bi-directional data cut into 528 stream frames. Streams can be created either by the client or the 529 server, can concurrently send data interleaved with other streams, 530 and can be cancelled. QUIC's stream lifetime is modeled closely 531 after HTTP/2's [RFC7540]. (HTTP/2's usage of QUIC streams is 532 described in more detail later in the document.) 534 Stream creation is done implicitly, by sending a STREAM frame for a 535 given stream. To avoid stream ID collision, the Stream-ID must be 536 even if the server initiates the stream, and odd if the client 537 initiates the stream. 0 is not a valid Stream-ID. Stream 1 is 538 reserved for the crypto handshake, which should be the first client- 539 initiated stream. Stream 3 is reserved for transmitting compressed 540 headers for all other streams, ensuring reliable in-order delivery 541 and processing of headers. 543 Stream-IDs from each side of the connection must increase 544 monotonically as new streams are created. E.g. Stream 2 may be 545 created after stream 3, but stream 7 must not be created after stream 546 9. The peer may receive streams out of order. For example, if a 547 server receives packet 10 including frames for stream 9 before it 548 receives packet 9 including frames for stream 7, it should handle 549 this gracefully. 551 If the endpoint receiving a STREAM frame does not want to accept the 552 stream, it can immediately respond with a RST_STREAM frame (described 553 below). Note, however, that the initiating endpoint may have already 554 sent data on the stream as well; this data must be ignored. 556 Once a stream is created, it can be used to send and receive data. 557 This means that a series of stream frames can be sent by a QUIC 558 endpoint on a stream until the stream is terminated in that 559 direction. 561 Either QUIC endpoint can terminate a stream normally. There are 562 three ways that streams can be terminated: 564 1. Normal termination: Since streams are bidirectional, streams can 565 be "half-closed" or "closed". When one side of the stream sends 566 a frame with the FIN bit set to true, the stream is considered to 567 be "half-closed" in that direction. A FIN indicates that no 568 further data will be sent from the sender of the FIN on this 569 stream. When a QUIC endpoint has both sent and received a FIN, 570 the endpoint considers the stream to be "closed". While the FIN 571 should be sent with the last user data for a stream, the FIN bit 572 can be sent on an empty stream frame following the last data on 573 the stream. 575 2. Abrupt termination: Either the client or server can send a 576 RST_STREAM frame for a stream at any time. A RST_STREAM frame 577 contains an error code to indicate the reason for failure (error 578 codes are listed later in the document.) When a RST_STREAM frame 579 is sent from the stream originator, it indicates a failure to 580 complete the stream and that no further data will be sent on the 581 stream. When a RST_STREAM frame is sent from the stream 582 receiver, the sender, upon receipt, should stop sending any data 583 on the stream. The stream receiver should be aware that there is 584 a race between data already in transit from the sender and the 585 time the RST_STREAM frame is received. In order to ensure that 586 the connection-level flow control is correctly accounted, even if 587 a RST_STREAM frame is received, a sender needs to ensure that 588 either: the FIN and all bytes in the stream are received by the 589 peer or a RST_STREAM frame is received by the peer. This also 590 means that the sender of a RST_STREAM frame needs to continue 591 responding to incoming STREAM_FRAMEs on this stream with the 592 appropriate WINDOW_UPDATEs to ensure that the sender does not get 593 flow control blocked attempting to delivery the FIN. 595 3. Streams are also terminated when the connection is terminated, as 596 described in the next section. 598 6.3. Connection Termination 600 Connections should remain open until they become idle for a pre- 601 negotiated period of time. When a server decides to terminate an 602 idle connection, it should not notify the client to avoid waking up 603 the radio on mobile devices. A QUIC connection, once established, 604 can be terminated in one of two ways: 606 1. Explicit Shutdown: An endpoint sends a CONNECTION_CLOSE frame to 607 the peer initiating a connection termination. An endpoint may 608 send a GOAWAY frame to the peer prior to a CONNECTION_CLOSE to 609 indicate that the connection will soon be terminated. A GOAWAY 610 frame when sent signals to the peer that any active streams will 611 continue to be processed, but the sender of the GOAWAY will not 612 initiate any additional streams and will not accept any new 613 incoming streams. On termination of the active streams, a 614 CONNECTION_CLOSE may be sent. If an endpoint sends a 615 CONNECTION_CLOSE frame while unterminated streams are active (no 616 FIN bit or RST_STREAM frames have been sent or received for one 617 or more streams), then the peer must assume that the streams were 618 incomplete and were abnormally terminated. 620 2. Implicit Shutdown: The default idle timeout for a QUIC connection 621 is 30 seconds, and is a required parameter("ICSL") in connection 622 negotiation. The maximum is 10 minutes. If there is no network 623 activity for the duration of the idle timeout, the connection is 624 closed. By default a CONNECTION_CLOSE frame will be sent. A 625 silent close option can be enabled when it is expensive to send 626 an explicit close, such as mobile networks that must wake up the 627 radio. 629 An endpoint may also send a PUBLIC_RESET packet at any time during 630 the connection to abruptly terminate an active connection. A 631 PUBLIC_RESET is the QUIC equivalent of a TCP RST. 633 7. Frame Types and Formats 635 QUIC Frame Packets are populated by frames. which have a Frame Type 636 byte, which itself has a type-dependent interpretation, followed by 637 type-dependent frame header fields. All frames are contained within 638 single QUIC Packets and no frame can span across a QUIC Packet 639 boundary. 641 7.1. Frame Types 643 There are two interpretations for the Frame Type byte, resulting in 644 two frame types: Special Frame Types, and Regular Frame Types. 645 Special Frame Types encode both a Frame Type and corresponding flags 646 all in the Frame Type byte, while Regular Frame Types use the Frame 647 Type byte simply. 649 Currently defined Special Frame Types are: 651 +------------------+-----------------------------+ 652 | Type-field value | Control Frame-type | 653 +------------------+-----------------------------+ 654 | 1fdooossB | STREAM | 655 | 01ntllmmB | ACK | 656 | 001xxxxxB | CONGESTION_FEEDBACK | 657 +------------------+-----------------------------+ 659 Currently defined Regular Frame Types are: 661 +------------------+-----------------------------+ 662 | Type-field value | Control Frame-type | 663 +------------------+-----------------------------+ 664 | 00000000B (0x00) | PADDING | 665 | 00000001B (0x01) | RST_STREAM | 666 | 00000010B (0x02) | CONNECTION_CLOSE | 667 | 00000011B (0x03) | GOAWAY | 668 | 00000100B (0x04) | WINDOW_UPDATE | 669 | 00000101B (0x05) | BLOCKED | 670 | 00000110B (0x06) | STOP_WAITING | 671 | 00000110B (0x07) | PING | 672 +------------------+-----------------------------+ 674 7.2. STREAM Frame 676 The STREAM frame is used to both implicitly create a stream and to 677 send data on it, and is as follows: 679 0 1 ... SLEN 680 +--------+--------+--------+--------+--------+ 681 |Type (8)| Stream ID (8, 16, 24, or 32 bits) | 682 | | (Variable length SLEN bytes) | 683 +--------+--------+--------+--------+--------+ 685 SLEN+1 SLEN+2 ... SLEN+OLEN 686 +--------+--------+--------+--------+--------+--------+--------+--------+ 687 | Offset (0, 16, 24, 32, 40, 48, 56, or 64 bits) (variable length) | 688 | (Variable length: OLEN bytes) | 689 +--------+--------+--------+--------+--------+--------+--------+--------+ 691 SLEN+OLEN+1 SLEN+OLEN+2 692 +-------------+-------------+ 693 | Data length (0 or 16 bits)| 694 | Optional(maybe 0 bytes) | 695 +------------+--------------+ 697 The fields in the STREAM frame header are as follows: 699 o Frame Type: The Frame Type byte is an 8-bit value containing 700 various flags (1fdooossB): 702 * The leftmost bit must be set to 1 indicating that this is a 703 STREAM frame. 705 * The 'f' bit is the FIN bit. When set to 1, this bit indicates 706 the sender is done sending on this stream and wishes to "half- 707 close" (described in more detail later.) 709 * which is described in more detail later in this document. 711 * The 'd' bit indicates whether a Data Length is present in the 712 STREAM header. When set to 0, this field indicates that the 713 STREAM frame extends to the end of the Packet. 715 * The next three 'ooo' bits encode the length of the Offset 716 header field as 0, 16, 24, 32, 40, 48, 56, or 64 bits long. 718 * The next two 'ss' bits encode the length of the Stream ID 719 header field as 8, 16, 24, or 32 bits long. 721 o Stream ID: A variable-sized unsigned ID unique to this stream. 723 o Offset: A variable-sized unsigned number specifying the byte 724 offset in the stream for this block of data. 726 o Data length: An optional 16-bit unsigned number specifying the 727 length of the data in this stream frame. The option to omit the 728 length should only be used when the packet is a "full-sized" 729 Packet, to avoid the risk of corruption via padding. 731 A stream frame must always have either non-zero data length or the 732 FIN bit set. 734 7.3. ACK Frame 736 The ACK frame is sent to inform the peer which packets have been 737 received, as well as which packets are still considered missing by 738 the receiver (the contents of missing packets may need to be resent). 739 The design of QUIC's ACK frame is different from TCP's and SCTP's 740 SACK representations in that QUIC ACKs indicate the largest sequence 741 number observed thus far followed by a list of missing packet, or 742 NACK, ranges indicating gaps in packets received below this sequence 743 number. To limit the NACK ranges to the ones that haven't yet been 744 communicated to the peer, the peer periodically sends STOP_WAITING 745 frames that signal the receiver to stop waiting for packets below a 746 specified squence number, raising the "least unacked" sequence number 747 at the receiver. A sender of an ACK frame thus reports only those 748 NACK ranges between the received least unacked and the reported 749 largest observed sequence numbers. The frame is as follows: 751 0 1 N 752 +--------+--------+---------------------------------------------------+ 753 |Type (8)|Received| Largest Observed (8, 16, 32, or 48 bits) | 754 | |Entropy | (variable length) | 755 +--------+--------+---------------------------------------------------+ 757 N+1 N+2 N+3 N+4 N+8 759 +--------+--------+---------+--------+--------------------------------+ 760 |Largest Observed | Num | Delta | Time Since Largest Observed | 761 | Delta Time (16) |Timestamp|Largest | | 762 | | | (8) |Observed| | 763 +--------+--------+---------+--------+--------------------------------+ 765 N+9 N+11 - X 766 +--------+------------------+ 767 | Delta | Time | 768 |Largest | Since Previous | 769 |Observed|Timestamp (Repeat)| 770 +--------+------------------+ 771 X X+1 - Y Y+1 772 +--------+-------------------------------------------------+--------+ 773 | Number | Missing Packet Sequence Number Delta | Range | 774 | Ranges | (repeats Number Ranges times with Range Length) | Length | 775 | (opt) | |(Repeat)| 776 +--------+-------------------------------------------------+--------+ 778 Y+2 Y+3 - Z 779 +--------+-----------------------------------------------------+ 780 | Number | Revived Packet (8, 16, 32, or 48 bits) | 781 | Revived| Sequence Number (variable length) | 782 | (opt) | (repeats Number Revied times) | 783 +--------+-----------------------------------------------------+ 785 The fields in the ACK frame are as follows: 787 o Frame Type: The Frame Type byte is an 8-bit value containing 788 various flags (01ntllmmB). 790 * The first two bits must be set to 01 indicating that this is an 791 ACK frame. 793 * The 'n' bit indicates whether the frame has any NACK ranges. 795 * The 't' bit indicates whether the ACK frame has been truncated. 796 Truncation can happen when the complete ACK frame does not fit 797 within a single QUIC Packet, or when the number of NACK ranges 798 exceeds the maximum number of reportable NACK ranges (255). 800 When truncated, the ACK frame limits the largest observed 801 sequence number to the largest that can be reported, even 802 though the receiver may have received packets with sequence 803 numbers larger than the largest observed. 805 * The two 'll' bits encode the length of the Largest Observed 806 field as 1, 2, 4, or 6 bytes long. 808 * The two 'mm' bits encode the length of the Missing Packet 809 Sequence Number Delta field as 1, 2, 4, or 6 bytes long. 811 o Received Entropy: An 8 bit unsigned value specifying the 812 cumulative hash of entropy in all received packets up to the 813 largest observed packet. Entropy accumulation is described later 814 in this section. 816 o Largest Observed: A variable-sized unsigned value representing the 817 largest sequence number the peer has observed. When an ACK frame 818 is truncated, it indicates a sequence number greater than the 819 specified largest observed has been received, but information 820 about those additional receptions can't fit into this frame 821 (typically due to packet size restrictions). 823 o Largest Observed Delta Time: A 16 bit unsigned float with 11 824 explicit bits of mantissa and 5 bits of explicit exponent, 825 specifying the time elapsed in microseconds from when largest 826 observed was received until this Ack frame was sent. The bit 827 format is loosely modeled after IEEE 754. For example, 1 828 microsecond is represented as 0x1, which has an exponent of zero, 829 presented in the 5 high order bits, and mantissa of 1, presented 830 in the 11 low order bits. When the explicit exponent is greater 831 than zero, an implicit high-order 12th bit of 1 is assumed in the 832 mantissa. For example, a floatingvalue of 0x800 has an explicit 833 exponent of 1, as well as an explicit mantissa of 0, but then has 834 an effective mantissa of 4096 (12th bit is assumed to be 1). 835 Additionally, the actual exponent is one-less than the explicit 836 exponent, and the value represents 4096 microseconds. Any values 837 larger than the representable range are clamped to 0xFFFF. 839 o Num Timestamp: An 8-bit unsigned value specifying the number of 840 TCP timestamps that are included in this frame. There will be 841 this many pairs of following in the 842 timestamps. 844 o Delta Largest Observed: An 8-bit unsigned value specifying the 845 sequence number delta from the first timestamp to the largest 846 observed. 848 o Time Since Largest Observed: A 32-bit unsigned value specifying 849 the first timestamp. This is the time delta in microseconds from 850 the time the receiver's packet framer was created. 852 o Time Since Previous Timestamp: A 16-bit unsigned value specifying 853 the first timestamp. This is the time delta from the previous 854 timestamp. 856 o Num Ranges: An optional 8-bit unsigned value specifying the number 857 of missing packet ranges between largest observed and least 858 unacked. Only present if the 'n' flag bit is 1. 860 o Missing Packet Sequence Number Delta: A variable-sized sequence 861 number delta. For the first missing packet range, it is a delta 862 from the largest observed. For subsequent nack ranges, it is the 863 number of packets received between ranges. In the case of the 864 first nack range, a value of 0 specifies that the packet reported 865 as the largest observed is missing. In the case of the later nack 866 ranges, a value of 0 indicates the missing packet ranges are 867 contiguous (used only when more than 256 packets in a row were 868 lost). 870 o Range Length: An 8-bit unsigned value specifying one less than the 871 number of sequential nacks in the range. 873 o Num Revived: An 8-bit unsigned value specifying the number of 874 revived packets, recovered via FEC. Just like the Num Ranges 875 field, this field is only present if the 'n' flag bit is 1. 877 o Revived Packet Sequence Number: A variable-sized unsigned value 878 representing a packet the peer has revived via FEC. Its length is 879 the same as the length of the Largest Observed field. All 880 sequence numbers in this list are sorted in ascending order 881 (smallest first) and must also be present in the list of NACK 882 ranges. 884 7.3.1. Entropy Accumulation 886 The entropy bits for a subset of packets (known to a receiver or 887 sender) are accumulated into an 8 bit unsigned value, and similarly 888 presented in both a STOP_WAITING frame and an ACK frame. If we 889 defined E(k) to be the FLAG_ENTROPY bit present in packet sequence 890 number k, then the k'th packet's contribution C(k) is defined to be 891 E(k) left shifted by k mod 8 bits. The accumulated entropy is then 892 the bitwise-XOR sum of the contributions C(k), for all packets in the 893 desired subset. 895 7.4. STOP_WAITING Frame 897 The STOP_WAITING frame is sent to inform the peer that it should not 898 continue to wait for packets with sequence numbers lower than a 899 specified value. The sequence number is encoded in 1, 2, 4 or 6 900 bytes, using the same coding length as is specified for the sequence 901 number for the enclosing packet's header (specified in the QUIC Frame 902 Packet's Public Flags field.) The frame is as follows: 904 0 1 2 3 4 5 6 7 905 +--------+--------+--------+--------+--------+--------+-------+-------+ 906 |Type (8)|Sent | Least unacked delta (8, 16, 32, or 48 bits) | 907 | |Entropy | (variable length) | 908 +--------+--------+--------+--------+--------+--------+-------+-------+ 910 The fields in the STOP_WAITING frame are as follows: 912 o Frame Type: The Frame Type byte is an 8-bit value that must be set 913 to 0x06 indicating that this is a STOP_WAITING frame. 915 o Sent Entropy: An 8-bit unsigned value specifying the cumulative 916 hash of entropy in all sent packets up to the packet with sequence 917 number one less than the least unacked packet. [See "Entropy 918 Accumulation" section in the ACK frame section for details of this 919 calculation.] 921 o Least Unacked Delta: A variable length sequence number delta with 922 the same length as the packet header's sequence number. In the 923 case of an FEC revived packet, the same length as the other 924 packets in the FEC group. Subtract it from the header's packet 925 sequence number to determine the least unacked. The resulting 926 least unacked is the smallest sequence number of any packet for 927 which the sender is still awaiting an ack. If the receiver is 928 missing any packets smaller than this value, the receiver should 929 consider those packets to be irrecoverably lost. 931 7.5. WINDOW_UPDATE Frame 933 The WINDOW_UPDATE frame is used to inform the peer of an increase in 934 an endpoint's flow control receive window. The stream ID can be 0, 935 indicating this WINDOW_UPDATE applies to the connection level flow 936 control window, or > 0 indicating that the specified stream should 937 increase its flow control window. The frame is as follows: 939 An absolute byte offset is specified, and the receiver of a 940 WINDOW_UPDATE frame may only send up to that number of bytes on the 941 specified stream. Violating flow control by sending further bytes 942 will result in the receiving endpoint closing the connection. 944 On receipt of multiple WINDOW_UPDATE frames for a specific stream ID, 945 it is only necessary to keep track of the maximum byte offset. 947 Both stream and session windows start with a default value of 16 KB, 948 but this is typically increased during the handshake. To do this, an 949 endpoint should include SFCW (Stream Flow Control Window) and CFCW 950 (Connection/Session Flow Control Window) tags in the CHLO/SHLO (tags 951 are described in the QUIC Crypto document). The value associated 952 with each tag should be the number of bytes for initial stream window 953 and initial connection window respectively. 955 The frame is as follows: 957 0 1 4 5 12 958 +--------+--------+-- ... --+-------+--------+-- ... --+-------+ 959 |Type(8) | Stream ID (32 bits) | Byte offset (64 bits) | 960 +--------+--------+-- ... --+-------+--------+-- ... --+-------+ 962 The fields in the WINDOW_UPDATE frame are as follows: 964 o Frame Type: The Frame Type byte is an 8-bit value that must be set 965 to 0x04 indicating that this is a WINDOW_UPDATE frame. 967 o Stream ID: ID of the stream whose flow control windows is begin 968 updated, or 0 to specify the connection-level flow control window. 970 o Byte offset: A 64-bit unsigned integer indicating the absolute 971 byte offset of data which can be sent on the given stream. In the 972 case of connection level flow control, the cumulative number of 973 bytes which can be sent on all currently open streams. 975 7.6. BLOCKED Frame 977 The BLOCKED frame is used to indicate to the remote endpoint that 978 this endpoint is ready to send data (and has data to send), but is 979 currently flow control blocked. This is a purely informational 980 frame, which is extremely useful for debugging purposes. A receiver 981 of a BLOCKED frame should simply discard it (after possibly printing 982 a helpful log message). The frame is as follows: 984 0 1 2 3 4 985 +--------+--------+--------+--------+--------+ 986 |Type(8) | Stream ID (32 bits) | 987 +--------+--------+--------+--------+--------+ 989 The fields in the BLOCKED frame are as follows: 991 o Frame Type: The Frame Type byte is an 8-bit value that must be set 992 to 0x05 indicating that this is a BLOCKED frame. 994 o Stream ID: A 32-bit unsigned number indicating the stream which is 995 flow control blocked. A non-zero Stream ID field specifies the 996 stream that is flow control blocked. When zero, the Stream ID 997 field indicates that the connection is flow control blocked at the 998 connection level. 1000 7.7. CONGESTION_FEEDBACK Frame 1002 The CONGESTION_FEEDBACK frame is an experimental frame currently not 1003 used. It is intended to provide extra congestion feedback 1004 information outside the scope of the standard ack frame. A 1005 CONGESTION_FEEDBACK frame must have the first three bits of the Frame 1006 Type set to 001. The last 5 bits of the Frame Type field are 1007 reserved for future use. 1009 7.8. PADDING Frame 1011 The PADDING frame pads a packet with 0x00 bytes. When this frame is 1012 encountered, the rest of the packet is expected to be padding bytes. 1013 The frame contains 0x00 bytes and extends to the end of the QUIC 1014 packet. A PADDING frame only has a Frame Type field, and must have 1015 the 8-bit Frame Type field set to 0x00. 1017 7.9. RST_STREAM Frame 1019 The RST_STREAM frame allows for abnormal termination of a stream. 1020 When sent by the creator of a stream, it indicates the creator wishes 1021 to cancel the stream. When sent by the receiver of a stream, it 1022 indicates an error or that the receiver did not want to accept the 1023 stream, so the stream should be closed. The frame is as follows: 1025 0 1 4 5 12 8 16 1026 +-------+--------+-- ... ----+--------+-- ... ------+-------+-- ... ------+ 1027 |Type(8)| StreamID (32 bits) | Byte offset (64 bits)| Error code (32 bits)| 1028 +-------+--------+-- ... ----+--------+-- ... ------+-------+-- ... ------+ 1030 The fields in a RST_STREAM frame are as follows: 1032 o Frame type: The Frame Type is an 8-bit value that must be set to 1033 0x04 specifying that this is a RST_STREAM frame. 1035 o Stream ID: The 32-bit Stream ID of the stream being terminated. 1037 o Byte offset: A 64-bit unsigned integer indicating the absolute 1038 byte offset of the end of data for this stream. 1040 o Error code: A 32-bit QuicErrorCode which indicates why the stream 1041 is being closed. QuicErrorCodes are listed later in this 1042 document. 1044 7.10. PING frame 1046 The PING frame can be used by an endpoint to verify that a peer is 1047 still alive. The PING frame contains no payload. The receiver of a 1048 PING frame simply needs to ACK the packet containing this frame. The 1049 PING frame should be used to keep a connection alive when a stream is 1050 open. The default is to do this after 15 seconds of quiescence, 1051 which is much shorter than most NATs time out. A PING frame only has 1052 a Frame Type field, and must have the 8-bit Frame Type field set to 1053 0x07. 1055 7.11. CONNECTION_CLOSE frame 1057 The CONNECTION_CLOSE frame allows for notification that the 1058 connection is being closed. If there are streams in flight, those 1059 streams are all implicitly closed when the connection is closed. 1060 (Ideally, a GOAWAY frame would be sent with enough time that all 1061 streams are torn down.) The frame is as follows: 1063 0 1 4 5 6 7 1064 +--------+--------+-- ... -----+--------+--------+--------+----- ... 1065 |Type(8) | Error code (32 bits)| Reason phrase | Reason phrase 1066 | | | length (16 bits)|(variable length) 1067 +--------+--------+-- ... -----+--------+--------+--------+----- ... 1069 The fields of a CONNECTION_CLOSE frame are as follows: 1071 o Frame Type: An 8-bit value that must be set to 0x02 specifying 1072 that this is a CONNECTION_CLOSE frame. 1074 o Error Code: A 32-bit field containing the QuicErrorCode which 1075 indicates the reason for closing this connection. 1077 o Reason Phrase Length: A 16-bit unsigned number specifying the 1078 length of the reason phrase. This may be zero if the sender 1079 chooses to not give details beyond the QuicErrorCode. 1081 o Reason Phrase: An optional human-readable explanation for why the 1082 connection was closed. 1084 7.12. GOAWAY Frame 1086 The GOAWAY frame allows for notification that the connection should 1087 stop being used, and will likely be aborted in the future. Any 1088 active streams will continue to be processed, but the sender of the 1089 GOAWAY will not initiate any additional streams, and will not accept 1090 any new streams. The frame is as follows: 1092 0 1 4 5 6 7 8 1093 +--------+--------+-- ... -----+-------+-------+-------+------+ 1094 |Type(8) | Error code (32 bits)| Last Good Stream ID (32 bits)| -> 1095 +--------+--------+-- ... -----+-------+-------+-------+------+ 1097 9 10 11 1098 +--------+--------+--------+----- ... 1099 | Reason phrase | Reason phrase 1100 | length (16 bits)|(variable length) 1101 +--------+--------+--------+----- ... 1103 The fields of a GOAWAY frame are as follows: 1105 o Frame type: An 8-bit value that must be set to 0x06 specifying 1106 that this is a GOAWAY frame. 1108 o Error Code: A 32-bit field containing the QuicErrorCode which 1109 indicates the reason for closing this connection. 1111 o Last Good Stream ID: The last Stream ID which was accepted by the 1112 sender of the GOAWAY message. If no streams were replied to, this 1113 value must be set to 0. 1115 o Reason Phrase Length: A 16-bit unsigned number specifying the 1116 length of the reason phrase. This may be zero if the sender 1117 chooses to not give details beyond the error code. 1119 o Reason Phrase: An optional human-readable explanation for why the 1120 connection was closed. 1122 8. Quic Connection Negotiation Tags 1124 (TODO: List Tags.) 1126 9. QuicErrorCodes 1128 The number to code mappings for QuicErrorCodes are currently defined 1129 in the Chromium source code in src/net/quic/quic_protocol.h. (TODO: 1130 hardcode numbers and add them here) 1131 o QUIC_NO_ERROR: There was no error. This is not valid for 1132 RST_STREAM frames or CONNECTION_CLOSE frames 1134 o QUIC_STREAM_DATA_AFTER_TERMINATION: There were data frames after 1135 the a fin or reset. 1137 o QUIC_SERVER_ERROR_PROCESSING_STREAM: There was some server error 1138 which halted stream processing. 1140 o QUIC_MULTIPLE_TERMINATION_OFFSETS: The sender received two 1141 mismatching fin or reset offsets for a single stream. 1143 o QUIC_BAD_APPLICATION_PAYLOAD: The sender received bad application 1144 data. 1146 o QUIC_INVALID_PACKET_HEADER: The sender received a malformed packet 1147 header. 1149 o QUIC_INVALID_FRAME_DATA: The sender received an frame data. The 1150 more detailed error codes below are prefered where possible. 1152 o QUIC_INVALID_FEC_DATA: FEC data is malformed. 1154 o QUIC_INVALID_RST_STREAM_DATA: Stream rst data is malformed 1156 o QUIC_INVALID_CONNECTION_CLOSE_DATA: Connection close data is 1157 malformed. 1159 o QUIC_INVALID_ACK_DATA: Ack data is malformed. 1161 o QUIC_DECRYPTION_FAILURE: There was an error decrypting. 1163 o QUIC_ENCRYPTION_FAILURE: There was an error encrypting. 1165 o QUIC_PACKET_TOO_LARGE: The packet exceeded MaxPacketSize. 1167 o QUIC_PACKET_FOR_NONEXISTENT_STREAM: Data was sent for a stream 1168 which did not exist. 1170 o QUIC_CLIENT_GOING_AWAY: The client is going away (browser close, 1171 etc.) 1173 o QUIC_SERVER_GOING_AWAY: The server is going away (restart etc.) 1175 o QUIC_INVALID_STREAM_ID: A stream ID was invalid. 1177 o QUIC_TOO_MANY_OPEN_STREAMS: Too many streams already open. 1179 o QUIC_CONNECTION_TIMED_OUT: We hit our pre-negotiated (or default) 1180 timeout 1182 o QUIC_CRYPTO_TAGS_OUT_OF_ORDER: Handshake message contained out of 1183 order tags. 1185 o QUIC_CRYPTO_TOO_MANY_ENTRIES: Handshake message contained too many 1186 entries. 1188 o QUIC_CRYPTO_INVALID_VALUE_LENGTH: Handshake message contained an 1189 invalid value length. 1191 o QUIC_CRYPTO_MESSAGE_AFTER_HANDSHAKE_COMPLETE: A crypto message was 1192 received after the handshake was complete. 1194 o QUIC_INVALID_CRYPTO_MESSAGE_TYPE: A crypto message was received 1195 with an illegal message tag. 1197 o QUIC_SEQUENCE_NUMBER_LIMIT_REACHED: Transmitting an additional 1198 packet would cause a sequence number to be reused. 1200 10. Priority 1202 (TODO: implement) 1204 QUIC will use the HTTP/2 prioritization mechanism. Roughly, a stream 1205 may be dependent on another stream. In this situation, the "parent" 1206 stream should effectively starve the "child" stream. In addition, 1207 parent streams have an explicit priority. Parent streams should not 1208 starve other parent streams, but should make progress proportional to 1209 their relative priority. 1211 11. HTTP/2 Layering over QUIC 1213 Since QUIC integrates various HTTP/2 mechanisms with transport 1214 mechanisms, QUIC implements a number of features that are also 1215 specified in HTTP/2. As a result, QUIC allows HTTP/2 mechanisms to 1216 be replaced by QUIC's implementation, reducing complexity in the 1217 HTTP/2 protocol. This section briefly describes how HTTP/2 semantics 1218 can be offered over a QUIC implementation. 1220 11.1. Stream Management 1222 When HTTP/2 headers and data are sent over QUIC, the QUIC layer 1223 handles most of the stream management. HTTP/2 Stream IDs are 1224 replaced by QUIC Stream IDs. HTTP/2 does not need to do any explicit 1225 stream framing when using QUIC---data sent over a QUIC stream simply 1226 consists of HTTP/2 headers or body. Requests and responses are 1227 considered complete when the QUIC stream is closed in the 1228 corresponding direction. 1230 Stream flow control is handled by QUIC, and does not need to be re- 1231 implemented in HTTP/2. QUIC's flow controller replaces the two 1232 levels of poorly matched flow controllers in current HTTP/2 1233 deployments---one at the HTTP/2 level, and the other at the TCP 1234 level. 1236 11.2. HTTP/2 Header Compression 1238 QUIC implements HPACK header compression [3] for HTTP/2, which 1239 unfortunately introduces some Head-of-Line blocking since HTTP/2 1240 header blocks must be decompressed in the order they were compressed. 1242 Since streams may be processed in arbitrary order at a receiver, 1243 strict ordering across headers is enforced by sending all headers on 1244 a dedicated headers stream, with Stream ID 3. An HTTP/2 receiver 1245 using QUIC would thus process data from a stream only after receiving 1246 the corresponding header on the headers stream. 1248 Future work will tweak the compressor and decompressor in QUIC so 1249 that the compressed output does not depend on unacked previous 1250 compressed state. This could be done, perhaps, by creating 1251 "checkpoints" of HPACK state which are updated when headers have been 1252 acked. When compressing headers QUIC would only compress relative to 1253 the previous "checkpoint". 1255 11.3. Parsing HTTP/2 Headers 1257 HTTP/2 uses a SYN stream to create new streams and to negotiate 1258 various stream parameters, including stream priority. Since stream 1259 creation is implicit in QUIC, there is no equivalent of a SYN stream. 1260 Also, since there is no explicit stream priority in QUIC, the current 1261 HTTP/2 mapping on QUIC communicates HTTP/2 stream priority by 1262 prepending it to the beginning of the HTTP/2 headers in the headers 1263 stream. Each HTTP/2 header sent on the headers stream is as follows: 1265 0 3 4 7 8 11 12 1266 +--------+- ... ---+--------+- ... --+--------+- ... ---+------ ... 1267 | Priority | Stream ID | Headers length | Headers 1268 +--------+- ... ---+--------+- ... --+--------+- ... ---+------ ... 1270 Priority type: A 32-bit unsigned number specifying the stream's 1271 HTTP/2 priority 1273 Stream ID: A 32-bit unsigned number specifying the QUIC Stream ID 1274 associated with this HTTP/2 header 1275 Headers length: A 32-bit unsigned number encoding the length, in 1276 bytes, of the compressed headers to follow 1278 Headers: HTTP/2 compressed headers 1280 11.4. Persistent Connections 1282 Unlike when using TCP, the underlying connection for QUIC is 1283 guaranteed to be persistent. The HTTP "Connection" header is 1284 therefore does not apply. For best performance, it is expected that 1285 clients will not close a QUIC connection until the user navigates 1286 away from all web pages using that connection, or until the server 1287 closes the connection. 1289 11.5. QUIC Negotiation in HTTP 1291 The Alternate-Protocol header is used to negotiate use of QUIC on 1292 future HTTP requests. To specify QUIC as an alternate protocol 1293 available on port 123, a server uses: 1295 "Alternate-Protocol: 123:quic" 1297 When a client receives a Alternate-Protocol header advertising QUIC, 1298 it can then attempt to use QUIC for future secure connections on that 1299 domain. Since middleboxes and/or firewalls can block QUIC and/or UDP 1300 communication, a client should implement a graceful fallback to TCP 1301 when QUIC reachability is broken. 1303 Note that the server may reply with multiple field values or a comma- 1304 separated field value for Alternate-Protocol to indicate the various 1305 transports it supports. 1307 A server can also send a header to notify that QUIC should not be 1308 used on this domain. If it sends the alternate-protocol-required 1309 header, the client should remember to not use QUIC on that domain in 1310 future, and not do any UDP probing to see if QUIC is available. 1312 To mandate HTTPS rather than QUIC for a given domain, one could send: 1314 "Alternate-Protocol-Required: 443:https" 1316 12. Recent Changes By Version 1318 o Q009: added priority as the first 4 bytes on spdy streams. 1320 o Q010: renumber the various frame types 1321 o Q011: shrunk the fnv128 hash on NULL encrypted packets from 16 1322 bytes to 12 bytes. 1324 o Q012: optimize the ack frame format to reduce the size and better 1325 handle ranges of nacks, which should make truncated acks virtually 1326 impossible. Also adding an explicit flag for truncated acks and 1327 moving the ack outside of the connection close frame. 1329 o Q013: Compressed headers for *all* data streams are serialized 1330 into a reserved stream. This ensures serialized handling of 1331 headers, independent of stream cancellation notification. 1333 o Q014: Added WINDOW_UPDATE and BLOCKED frames, no behavioral 1334 change. 1336 o Q015: Removes the accumulated_number_of_lost_packets field from 1337 the TCP and inter arrival congestion feedback frames and adds an 1338 explicit list of recovered packets to the ack frame. 1340 o Q016: Breaks out the sent_info field from the ACK frame into a new 1341 STOP_WAITING frame. 1343 o Changed GUID to Connection ID 1345 o Q017: Adds stream level flow control 1347 o Q018: Added a PING frame 1349 o Q019: Adds session/connection level flow control 1351 o Q020: Allow endpoints to set different stream/session flow control 1352 windows 1354 o Q021: Crypto and headers streams are flow controlled (at stream 1355 level) 1357 o Q023: Ack frames include packet timestamps 1359 o Q024: HTTP/2-style header compression 1361 o Q025: HTTP/2-style header keys. Removal of error_details from the 1362 RST_STREAM frame. 1364 . 1366 13. References 1368 13.1. Normative References 1370 [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate 1371 Requirement Levels", March 1997. 1373 13.2. Informative References 1375 [RFC7540] Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer 1376 Protocol Version 2 (HTTP/2)", May 2015. 1378 [QUIC-CRYPTO] 1379 Langley, A. and W. Chang, "QUIC Crypto", June 2015. 1381 [QUIC-CC] Swett, I. and J. Iyengar, "QUIC Loss Recovery and 1382 Congestion Control", June 2015. 1384 13.3. URIs 1386 [1] https://www.chromium.org/quic 1388 [2] http://goo.gl/jOvOQ5 1390 [3] http://http2.github.io/http2-spec/compression.html 1392 Authors' Addresses 1394 Janardhan Iyengar 1395 Google 1397 Email: jri@google.com 1399 Ian Swett 1400 Google 1402 Email: ianswett@google.com