draft-tsvwg-quic-protocol-01.txt   draft-tsvwg-quic-protocol-02.txt 
Network Working Group R. Hamilton Network Working Group R. Hamilton
Internet-Draft J. Iyengar Internet-Draft J. Iyengar
Intended status: Informational I. Swett Intended status: Informational I. Swett
Expires: January 9, 2016 A. Wilk Expires: July 16, 2016 A. Wilk
Google Google
July 8, 2015 January 13, 2016
QUIC: A UDP-Based Secure and Reliable Transport for HTTP/2 QUIC: A UDP-Based Secure and Reliable Transport for HTTP/2
draft-tsvwg-quic-protocol-01 draft-tsvwg-quic-protocol-02
Abstract Abstract
QUIC (Quick UDP Internet Connection) is a new multiplexed and secure QUIC (Quick UDP Internet Connection) is a new multiplexed and secure
transport atop UDP, designed from the ground up and optimized for transport atop UDP, designed from the ground up and optimized for
HTTP/2 semantics. While built with HTTP/2 as the primary application HTTP/2 semantics. While built with HTTP/2 as the primary application
protocol, QUIC builds on decades of transport and security protocol, QUIC builds on decades of transport and security
experience, and implements mechanisms that make it attractive as a experience, and implements mechanisms that make it attractive as a
modern general-purpose transport. QUIC provides multiplexing and modern general-purpose transport. QUIC provides multiplexing and
flow control equivalent to HTTP/2, security equivalent to TLS, and flow control equivalent to HTTP/2, security equivalent to TLS, and
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 9, 2016. This Internet-Draft will expire on July 16, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents
1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 3
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
5. A QUIC Overview . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Connection Establishment Latency . . . . . . . . . . . . 5
5.2. Flexible Congestion Control . . . . . . . . . . . . . . . 6
5.3. Stream and Connection Flow Control . . . . . . . . . . . 6
5.4. Multiplexing . . . . . . . . . . . . . . . . . . . . . . 7
5.5. Authenticated and Encrypted Header and Payload . . . . . 7
5.6. Forward Error Correction . . . . . . . . . . . . . . . . 7
5.7. Connection Migration . . . . . . . . . . . . . . . . . . 8
6. Packet Types and Formats . . . . . . . . . . . . . . . . . . 8
6.1. QUIC Public Packet Header . . . . . . . . . . . . . . . . 8
6.2. Special Packets . . . . . . . . . . . . . . . . . . . . . 12
6.2.1. Version Negotiation Packet . . . . . . . . . . . . . 12
6.2.2. Public Reset Packet . . . . . . . . . . . . . . . . . 13
6.3. Regular Packets . . . . . . . . . . . . . . . . . . . . . 13
6.3.1. Frame Packet . . . . . . . . . . . . . . . . . . . . 14
6.3.2. FEC Packet . . . . . . . . . . . . . . . . . . . . . 15
7. Life of a QUIC Connection . . . . . . . . . . . . . . . . . . 15
7.1. Connection Establishment . . . . . . . . . . . . . . . . 15
7.2. Data Transfer . . . . . . . . . . . . . . . . . . . . . . 16
7.2.1. Life of a QUIC Stream . . . . . . . . . . . . . . . . 16
7.3. Connection Termination . . . . . . . . . . . . . . . . . 18
8. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 19
8.1. Frame Types . . . . . . . . . . . . . . . . . . . . . . . 19
8.2. STREAM Frame . . . . . . . . . . . . . . . . . . . . . . 19
8.3. ACK Frame . . . . . . . . . . . . . . . . . . . . . . . . 21
8.3.1. Entropy Accumulation . . . . . . . . . . . . . . . . 25
8.4. STOP_WAITING Frame . . . . . . . . . . . . . . . . . . . 25
8.5. WINDOW_UPDATE Frame . . . . . . . . . . . . . . . . . . . 26
8.6. BLOCKED Frame . . . . . . . . . . . . . . . . . . . . . . 27
8.7. CONGESTION_FEEDBACK Frame . . . . . . . . . . . . . . . . 27
8.8. PADDING Frame . . . . . . . . . . . . . . . . . . . . . . 27
8.9. RST_STREAM Frame . . . . . . . . . . . . . . . . . . . . 27
8.10. PING frame . . . . . . . . . . . . . . . . . . . . . . . 28
8.11. CONNECTION_CLOSE frame . . . . . . . . . . . . . . . . . 28
8.12. GOAWAY Frame . . . . . . . . . . . . . . . . . . . . . . 29
9. QUIC Transport Parameters . . . . . . . . . . . . . . . . . . 30
9.1. Required Parameters . . . . . . . . . . . . . . . . . . . 30
9.2. Optional Parameters . . . . . . . . . . . . . . . . . . . 30
10. QuicErrorCodes . . . . . . . . . . . . . . . . . . . . . . . 30
11. Priority . . . . . . . . . . . . . . . . . . . . . . . . . . 32
12. HTTP/2 Layering over QUIC . . . . . . . . . . . . . . . . . . 32
12.1. Stream Management . . . . . . . . . . . . . . . . . . . 32
12.2. HTTP/2 Header Compression . . . . . . . . . . . . . . . 33
12.3. Parsing HTTP/2 Headers . . . . . . . . . . . . . . . . . 33
12.4. Persistent Connections . . . . . . . . . . . . . . . . . 33
12.5. QUIC Negotiation in HTTP . . . . . . . . . . . . . . . . 33
13. Handshake Protocol Requirements . . . . . . . . . . . . . . . 34
13.1. Connection Establishment in 0-RTT . . . . . . . . . . . 34
13.2. Source Address Spoofing Defense . . . . . . . . . . . . 34
13.3. Opaque Source Address Tokens . . . . . . . . . . . . . . 34
13.4. Transport Parameter Negotiation . . . . . . . . . . . . 35
13.5. Certificate Compression . . . . . . . . . . . . . . . . 35
13.6. Server Config Update . . . . . . . . . . . . . . . . . . 35
14. Recent Changes By Version . . . . . . . . . . . . . . . . . . 35
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
15.1. Normative References . . . . . . . . . . . . . . . . . . 36
15.2. Informative References . . . . . . . . . . . . . . . . . 36
15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
1. Contributors 1. Contributors
This protocol is the outcome of work by many engineers, not just the This protocol is the outcome of work by many engineers, not just the
authors of this document. The design and rationale behind QUIC draw authors of this document. The design and rationale behind QUIC draw
significantly from work by Jim Roskind. In alphabetical order, the significantly from work by Jim Roskind [1]. In alphabetical order,
contributors to the project are: Wan-Teh Chang, Britt Cyr, Ryan the contributors to the project are: Britt Cyr, Ryan Hamilton, Jana
Hamilton, Jana Iyengar, Fedor Kouranov, Jo Kulik, Adam Langley, Jim Iyengar, Fedor Kouranov, Charles Krasic, Jo Kulik, Adam Langley, Jim
Roskind, Robbie Shade, Satyam Shekhar, Ian Swett, Raman Tenneti, Roskind, Robbie Shade, Satyam Shekhar, Cherie Shi, Ian Swett, Raman
Antonio Vicente, Patrik Westin, Alyssa Wilk, Dale Worley, Daniel Tenneti, Antonio Vicente, Patrik Westin, Alyssa Wilk, Dale Worley,
Ziegler. Dan Zhang, Daniel Ziegler.
2. Acknowledgments 2. Acknowledgments
Special thanks are due to the following for helping shape QUIC and Special thanks are due to the following for helping shape QUIC and
its deployment: Chris Bentzel, Misha Efimov, Roberto Peon, Alistair its deployment: Chris Bentzel, Misha Efimov, Roberto Peon, Alistair
Riddoch, Siddharth Vijayakrishnan, and Assar Westerlund. QUIC has Riddoch, Siddharth Vijayakrishnan, and Assar Westerlund. QUIC has
also benefited immensely from discussions with folks in private also benefited immensely from discussions with folks in private
conversations and public ones on the proto-quic@chromium.org mailing conversations and public ones on the proto-quic@chromium.org mailing
list. list.
skipping to change at page 3, line 12 skipping to change at page 4, line 34
An important goal for QUIC is to inform better transport design An important goal for QUIC is to inform better transport design
through rapid experimentation. As a result, we hope to inform and through rapid experimentation. As a result, we hope to inform and
where possible migrate distilled changes into TCP and TLS, which tend where possible migrate distilled changes into TCP and TLS, which tend
to have much longer iteration cycles. to have much longer iteration cycles.
This document describes the conceptual design and the wire This document describes the conceptual design and the wire
specification of the QUIC protocol. Accompanying documents describe specification of the QUIC protocol. Accompanying documents describe
the combined crypto and transport handshake [QUIC-CRYPTO], and loss the combined crypto and transport handshake [QUIC-CRYPTO], and loss
recovery and congestion control [draft-quic-loss-recovery]. recovery and congestion control [draft-quic-loss-recovery].
Additional resources, including a more detailed rationale document, Additional resources, including a more detailed rationale document,
are available on the Chromium QUIC webpage [1]. are available on the Chromium QUIC webpage [2].
4. Conventions and Definitions 4. Conventions and Definitions
All integer values used in QUIC, including length, version, and type, All integer values used in QUIC, including length, version, and type,
are in little-endian byte order, and not in network byte order. QUIC are in little-endian byte order, and not in network byte order. QUIC
does not enforce alignment of types in dynamically sized frames. does not enforce alignment of types in dynamically sized frames.
A few terms that are used throughout this document are defined below. A few terms that are used throughout this document are defined below.
o "Client": The endpoint initiating a QUIC connection. o "Client": The endpoint initiating a QUIC connection.
skipping to change at page 4, line 14 skipping to change at page 5, line 36
o Authenticated and encrypted header and payload o Authenticated and encrypted header and payload
o Stream and connection flow control o Stream and connection flow control
o Forward error correction o Forward error correction
o Connection migration o Connection migration
5.1. Connection Establishment Latency 5.1. Connection Establishment Latency
For a complete description of connection establishment, please see QUIC combines the crypto and transport handshakes, reducing the
the QUIC Crypto design [2] document. Briefly, QUIC handshakes number of roundtrips required for setting up a secure connection.
frequently require zero roundtrips before sending payload, as QUIC connections are commonly 0-RTT, meaning that on most QUIC
compared to 1-3 roundtrips for TCP+TLS. connections, data can be sent immediately without waiting for a reply
from the server, as compared to the 1-3 roundtrips required for
TCP+TLS before application data can be sent.
The first time a QUIC client connects to a server, the client must QUIC provides a dedicated stream (Stream ID 1) to be used for
perform a 1-roundtrip handshake in order to acquire the necessary performing the handshake, but the details of this handshake protocol
information to complete the handshake. The client sends an inchoate are out of this document's scope. For a complete description of the
(empty) client hello (CHLO), the server sends a rejection (REJ) with current handshake protocol, please see the QUIC Crypto Handshake
the information the client needs to make forward progress. This [3]document. QUIC current handshake will be replaced by TLS 1.3 in
information includes a source address token, which is used to verify the future.
the client's IP on a subsequent CHLO, and the server's certificates.
The next time the client sends a CHLO, it can use the cached
credentials from the previous connection to immediately send
encrypted requests to the server.
5.2. Flexible Congestion Control 5.2. Flexible Congestion Control
QUIC has pluggable congestion control and richer signaling than TCP, QUIC has pluggable congestion control and richer signaling than TCP,
which enables QUIC to provide richer information to congestion which enables QUIC to provide richer information to congestion
control algorithms than TCP. Currently, the default congestion control algorithms than TCP. Currently, the default congestion
control is a reimplementation of TCP Cubic; we are currently control is a reimplementation of TCP Cubic; we are currently
experimenting with alternative approaches. experimenting with alternative approaches.
One example of richer information is that each packet, both original One example of richer information is that each packet, both original
and retransmitted, carries a new sequence number. This allows a QUIC and retransmitted, carries a new packet sequence number. This allows
sender to distinguish ACKs for retransmissions from ACKs for original a QUIC sender to distinguish ACKs for retransmissions from ACKs for
transmissions, thus avoiding TCP's retransmission ambiguity problem. original transmissions, thus avoiding TCP's retransmission ambiguity
QUIC ACKs also explicitly carry the delay between the receipt of a problem. QUIC ACKs also explicitly carry the delay between the
packet and its acknowledgment being sent, and together with the receipt of a packet and its acknowledgment being sent, and together
monotonically-increasing sequence numbers, this allows for precise with the monotonically-increasing packet numbers, this allows for
roundtrip-time (RTT) calculation. precise roundtrip-time (RTT) calculation.
Finally, QUIC's ACK frames support up to 256 NACK ranges, so QUIC is Finally, QUIC's ACK frames support up to 256 NACK ranges, so QUIC is
more resilient to reordering than TCP (with SACK), as well as able to more resilient to reordering than TCP (with SACK), as well as able to
keep more bytes on the wire when there is reordering or loss. Both keep more bytes on the wire when there is reordering or loss. Both
client and server have a more accurate picture of which packets the client and server have a more accurate picture of which packets the
peer has received. peer has received.
5.3. Stream and Connection Flow Control 5.3. Stream and Connection Flow Control
QUIC implements stream- and connection-level flow control, closely QUIC implements stream- and connection-level flow control, closely
skipping to change at page 7, line 7 skipping to change at page 8, line 27
QUIC connections are identified by a 64-bit Connection ID, randomly QUIC connections are identified by a 64-bit Connection ID, randomly
generated by the client. QUIC can survive IP address changes and NAT generated by the client. QUIC can survive IP address changes and NAT
re-bindings since the Connection ID remains the same across these re-bindings since the Connection ID remains the same across these
migrations. QUIC also provides automatic cryptographic verification migrations. QUIC also provides automatic cryptographic verification
of a migrating client, since a migrating client continues to use the of a migrating client, since a migrating client continues to use the
same session key for encrypting and decrypting packets. same session key for encrypting and decrypting packets.
6. Packet Types and Formats 6. Packet Types and Formats
QUIC has four packet types: Version Negotiation Packets, Frame QUIC has Special Packets and Regular Packets. There are two types of
Packets, FEC Packets, and Public Reset Packets. All QUIC packets Special Packets: Version Negotiation Packets and Public Reset
should be sized to fit within the path's MTU to avoid IP Packets, and two types of Regular Packets: Frame Packets, and FEC
fragmentation. Path MTU discovery is a work in progress, and the Packets. All QUIC packets should be sized to fit within the path's
current QUIC implementation uses a 1350-byte maximum QUIC packet size MTU to avoid IP fragmentation. Path MTU discovery is a work in
for IPv6, 1370 for IPv4. progress, and the current QUIC implementation uses a 1350-byte
maximum QUIC packet size for IPv6, 1370 for IPv4.
6.1. QUIC Common Packet Header
All QUIC packets on the wire begin with a common header sized between 6.1. QUIC Public Packet Header
2 and 21 bytes. The wire format for the common header is as follows:
0 1 2 3 4 8 All QUIC packets on the wire begin with a public header sized between
+--------+--------+--------+--------+--------+--- ---+ 2 and 19 bytes. The wire format for the public header is as follows:
| Public | Connection ID (0, 8, 32, or 64) ... | ->
|Flags(8)| (variable length) |
+--------+--------+--------+--------+--------+--- ---+
9 10 11 12 0 1 2 3 4 8
+--------+--------+--------+--------+ +--------+--------+--------+--------+--------+--- ---+
| QUIC Version (32) | -> | Public | Connection ID (0, 8, 32, or 64) ... | ->
| (optional) | |Flags(8)| (variable length) |
+--------+--------+--------+--------+ +--------+--------+--------+--------+--------+--- ---+
13 14 15 16 17 18 19 20 9 10 11 12
+--------+--------+--------+--------+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Sequence Number (8, 16, 32, or 48) |Private | FEC (8)| | QUIC Version (32) | ->
| (variable length) |Flags(8)| (opt) | | (optional) |
+--------+--------+--------+--------+--------+--------+--------+--------+ +--------+--------+--------+--------+
QUIC packets are authenticated and encrypted. The first part of the 13 14 15 16 17 18
common header upto and including the Sequence Number field is +--------+--------+--------+--------+--------+--------+
authenticated but not encrypted, and the rest of the packet starting | Packet Number (8, 16, 32, or 48) |
with the Private Flags field is encrypted. | (variable length) |
+--------+--------+--------+--------+--------+--------+
The unencrypted payload may include various type-dependent header The payload may include various type-dependent header bytes as
bytes as described below. described below.
The fields in the common header are the following: The fields in the public header are the following:
o Public Flags: o Public Flags:
* Bit at 0x01 is set to indicate that the packet contains a QUIC * 0x01 = PUBLIC_FLAG_VERSION. Interpretation of this flag
Version. This bit must be set by a client in all packets until depends on whether the packet is sent by the server or the
confirmation from the server arrives agreeing to the proposed client. When sent by the client, setting it indicates that the
version is received by the client. A server indicates header contains a QUIC Version (see below). This bit must be
agreement on a version by sending packets without setting this set by a client in all packets until confirmation from the
bit. Version Negotiation is described in more detail later. server arrives agreeing to the proposed version is received by
the client. A server indicates agreement on a version by
sending packets without setting this bit. When this bit is set
by the server, the packet is a Version Negotiation Packet.
Version Negotiation is described in more detail later.
* Bit at 0x02 is set to indicate that the packet is a Public * 0x02 = PUBLIC_FLAG_RESET. Set to indicate that the packet is a
Reset packet. Public Reset packet.
* Two bits at 0x0C indicate the size of the Connection ID that is * Two bits at 0x0C indicate the size of the Connection ID that is
present in the packet. These bits must be set to 0x0C in all present in the packet. These bits must be set to 0x0C in all
packets until negotiated to a different value for a given packets until negotiated to a different value for a given
direction (e.g., client may request fewer bytes of the direction (e.g., client may request fewer bytes of the
Connection ID be presented). Connection ID be presented).
+ 0x0C indicates an 8-byte Connection ID is present + 0x0C indicates an 8-byte Connection ID is present
+ 0x08 indicates that a 4-byte Connection ID is present + 0x08 indicates that a 4-byte Connection ID is present
+ 0x04 indicates that a 1-byte Connection ID is used + 0x04 indicates that a 1-byte Connection ID is used
+ 0x00 indicates that the Connection ID is omitted + 0x00 indicates that the Connection ID is omitted
* Two bits at 0x30 indicate the number of low-order-bytes of the * Two bits at 0x30 indicate the number of low-order-bytes of the
packet sequence number that are present in each packet. The packet number that are present in each packet. The bits are
bits are only used for Frame Packets. For Public Reset and only used for Frame Packets. For Public Reset and Version
Version Negotiation Packets (sent by the server) which don't Negotiation Packets (sent by the server) which don't have a
have a sequence number, these bits are not used and must be set packet number, these bits are not used and must be set to 0.
to 0. Within this 2 bit mask: Within this 2 bit mask:
+ 0x30 indicates that 6 bytes of the sequence number is + 0x30 indicates that 6 bytes of the packet number is present
present
+ 0x20 indicates that 4 bytes of the sequence number is + 0x20 indicates that 4 bytes of the packet number is present
present
+ 0x10 indicates that 2 bytes of the sequence number is + 0x10 indicates that 2 bytes of the packet number is present
present
+ 0x00 indicates that 1 byte of the sequence number is present + 0x00 indicates that 1 byte of the packet number is present
* Two bits at 0xC0 are currently unused, and must be set to 0. * 0x40 is reserved for multipath use.
* 0x80 is currently unused, and must be set to 0.
o Connection ID: This is an unsigned 64 bit statistically random o Connection ID: This is an unsigned 64 bit statistically random
number selected by the client that is the identifier of the number selected by the client that is the identifier of the
connection. Because QUIC connections are designed to remain connection. Because QUIC connections are designed to remain
established even if the client roams, the IP 4-tuple (source IP, established even if the client roams, the IP 4-tuple (source IP,
source port, destination IP, destination port) may be insufficient source port, destination IP, destination port) may be insufficient
to identify the connection. For each transmission direction, when to identify the connection. For each transmission direction, when
less uniqueness is sufficient to identify the connection, a less uniqueness is sufficient to identify the connection, a
truncated transmitted Connection ID length is negotiable. truncated transmitted Connection ID length is negotiable.
skipping to change at page 9, line 20 skipping to change at page 11, line 5
set this flag, and include EXACTLY one proposed version, as well set this flag, and include EXACTLY one proposed version, as well
as including arbitrary data (conforming to that version). A as including arbitrary data (conforming to that version). A
server may set this flag when the client-proposed version was server may set this flag when the client-proposed version was
unsupported, and may then provide a list (0 or more) of acceptable unsupported, and may then provide a list (0 or more) of acceptable
versions, but MUST not include any data after the version(s). versions, but MUST not include any data after the version(s).
Examples of version values in recent experimental versions include Examples of version values in recent experimental versions include
"Q025" which corresponds to byte 9 containing 'Q", byte 10 "Q025" which corresponds to byte 9 containing 'Q", byte 10
containing '0", etc. [See list of changes in various versions containing '0", etc. [See list of changes in various versions
listed at the end of this document.] listed at the end of this document.]
o Sequence Number: The lower 8, 16, 32, or 48 bits of the sequence o Packet Number: The lower 8, 16, 32, or 48 bits of the packet
number, based on which FLAG_?BYTE_SEQUENCE_NUMBER flag is set in number, based on which FLAG_?BYTE_SEQUENCE_NUMBER flag is set in
the public flags. See "Sequence numbers" below. the public flags. Each Regular Packet (as opposed to the Special
public reset and version negotiation packets) is assigned a packet
o Private Flags:
* 0x01 = FLAG_ENTROPY - for data packets, signifies that this
packet contains the 1 bit of entropy, for fec packets, contains
the xor of the entropy of protected packets.
* 0x02 = FLAG_FEC_GROUP - indicates whether the fec byte is
present.
* 0x04 = FLAG_FEC - signifies that this packet represents an FEC
packet.
o FEC (FEC Group Number Offset): An FEC Group Number is the Packet
Sequence Number of the first packet in the FEC group. The FEC
Group Number Offset is an 8 bit unsigned value which should be
subtracted from the current packet's Packet Sequence Number to
yield the FEC Group Number for this packet. This is only present
if the private flags contain FLAG_FEC_GROUP. All packets within a
single FEC group must have Sequence Numbers encoded into an
identical number of bytes (i.e., the Sequence Number coding must
not change during a group)
o Sequence Number: Each QUIC Frame Packet (as opposed to public
reset and version negotiation packets) is assigned a sequence
number by the sender. The first packet sent by an endpoint shall number by the sender. The first packet sent by an endpoint shall
have a sequence number of 1, and each subsequent packet shall have have a packet number of 1, and each subsequent packet shall have a
a sequence number one larger than that of the previous packet. packet number one larger than that of the previous packet. The
The lower 64 bits of the sequence number may be used as part of a lower 64 bits of the packet number is used as part of a
cryptographic nonce; therefore, a QUIC endpoint must not send a cryptographic nonce; therefore, a QUIC endpoint must not send a
packet with a sequence number that cannot be represented in 64 packet with a packet number that cannot be represented in 64 bits.
bits. If a QUIC endpoint transmits a packet with a sequence If a QUIC endpoint transmits a packet with a packet number of
number of (2^64-1), that packet must include a CONNECTION_CLOSE (2^64-1), that packet must include a CONNECTION_CLOSE frame with
frame with an error code of QUIC_SEQUENCE_NUMBER_LIMIT_REACHED, an error code of QUIC_SEQUENCE_NUMBER_LIMIT_REACHED, and the
and the endpoint must not transmit any additional packets. At endpoint must not transmit any additional packets. At most the
most the lower 48 bits of a sequence number are transmitted. To lower 48 bits of a packet number are transmitted. To enable
enable unambiguous reconstruction of the sequence number by the unambiguous reconstruction of the packet number by the receiver, a
receiver, a QUIC endpoint must not transmit a packet whose QUIC endpoint must not transmit a packet whose packet number is
sequence number is larger by (2^(bitlength-2)) than the largest larger by (2^(bitlength-2)) than the largest packet number for
sequence number for which an acknowledgement is known to have been which an acknowledgement is known to have been transmitted by the
transmitted by the receiver. Therefore, there must never be more receiver. Therefore, there must never be more than (2^46) packets
than (2^46) packets in flight. Any truncated sequence number in flight. Any truncated packet number shall be inferred to have
shall be inferred to have the value closest to the one more than the value closest to the one more than the largest known packet
the largest known sequence number of the endpoint which number of the endpoint which transmitted the packet that
transmitted the packet that originally contained the truncated originally contained the truncated packet number. The transmitted
sequence number. The transmitted portion of the sequence number portion of the packet number matches the lowest bits of the
matches the lowest bits of the inferred value. inferred value.
6.2. Version Negotiation Packet
(Describe version negotiation packet.)
6.3. Frame Packet A Public Flags processing flowchart follows:
Beyond the Common Header, Frame Packets have a payload that is a Check the public flags in public header
series of type-prefixed frames. The format of frame types is defined |
later in this document, but the general format of a Frame Packet is |
as follows: V
+--------------+
| Public Reset | YES
| flag set? |---------------> Public Reset Packet
+--------------+
|
| NO
V
+------------+ +-------------+
| Version | YES | Packet sent | YES
| flag set? |--------->| by server? |--------> Version Negotiation
+------------+ +-------------+ Packet
| |
| NO | NO
V V
Regular Packet Regular Packet with
QUIC Version present in header
+--------+---...---+--------+---...---+ 6.2. Special Packets
| Type | Payload | Type | Payload |
+--------+---...---+--------+---...---+
6.4. FEC Packet 6.2.1. Version Negotiation Packet
FEC packets (those packets with FLAG_FEC set) have a payload that A version negotiation packet is only sent by the server. Version
simply contains an XOR of the null-padded payload of each Data Packet Negotiation packets begin with an 8-bit public flags and 64-bit
in the FEC group. Connection ID. The public flags must set PUBLIC_FLAG_VERSION and
indicate the 64-bit Connection ID. The rest of the Version
Negotiation packet is a list of 4-byte versions which the server
supports:
+-----...----+ 0 1 2 3 4 5 6 7 8
| Redundancy | +--------+--------+--------+--------+--------+--------+--------+--------+--------+
+-----...----+ | Public | Connection ID (64) | ->
|Flags(8)| |
+--------+--------+--------+--------+--------+--------+--------+--------+--------+
6.5. Public Reset Packet 9 10 11 12 13 14 15 16 17
+--------+--------+--------+--------+--------+--------+--------+--------+---...--+
| 1st QUIC version supported | 2nd QUIC version supported | ...
| by server (32) | by server (32) |
+--------+--------+--------+--------+--------+--------+--------+--------+---...--+
6.2.2. Public Reset Packet
Public reset packets begin with an 8-bit public flags and 64-bit A Public Reset packet begins with an 8-bit public flags and 64-bit
Connection ID. The rest of the public reset packets is encoded as if Connection ID. The public flags must set PUBLIC_FLAG_RESET and
it were a crypto handshake message of the tag PRST (see accompanying indicate the 64-bit Connection ID. The rest of the Public Reset
crypto document for more about QUIC Tags): packet is encoded as if it were a crypto handshake message of the tag
PRST (see [QUIC-CRYPTO]):
0 1 2 3 4 8 0 1 2 3 4 8
+--------+--------+--------+--------+--------+-- --+ +--------+--------+--------+--------+--------+-- --+
| Public | Connection ID (64) ... | -> | Public | Connection ID (64) ... | ->
|Flags(8)| | |Flags(8)| |
+--------+--------+--------+--------+--------+-- --+ +--------+--------+--------+--------+--------+-- --+
9 10 11 12 13 14 9 10 11 12 13 14
+--------+--------+--------+--------+--------+--------+--- +--------+--------+--------+--------+--------+--------+---
| Quic Tag (32) | Tag value map ... -> | Quic Tag (32) | Tag value map ... ->
| (PRST) | (variable length) | (PRST) | (variable length)
+--------+--------+--------+--------+--------+--------+--- +--------+--------+--------+--------+--------+--------+---
Tag value map: The tag value map contains the following tag-values: Tag value map: The tag value map contains the following tag-values:
o RNON (public reset nonce proof) - a 64-bit unsigned integer. o RNON (public reset nonce proof) - a 64-bit unsigned integer.
Mandatory. Mandatory.
o RSEQ (rejected sequence number) - a 64-bit sequence number. o RSEQ (rejected packet number) - a 64-bit packet number.
Mandatory. Mandatory.
o CADR (client address) - the observed client IP address and port o CADR (client address) - the observed client IP address and port
number. Optional. number. This is currently for debugging purposes only and hence
is optional.
(TODO: Public Reset packet should include authenticated (destination) (TODO: Public Reset packet should include authenticated (destination)
server IP/port.) server IP/port.)
6.3. Regular Packets
Regular Packets are authenticated and encrypted. The Public Header
is authenticated but not encrypted, and the rest of the packet
starting with the Private Flags field is encrypted. Immediately
following the Public Header, Regular Packets contain AEAD
(authenticated encryption and associated data) data. This data must
be decrypted in order for the contents to be interpreted. After
decryption, the plaintext starts with a Private Header.
0 1
+--------+--------+
|Private | FEC (8)|
|Flags(8)| (opt) |
+--------+--------+
The fields in the private header are the following:
o Private Flags:
* 0x01 = FLAG_ENTROPY - for data packets, signifies that this
packet contains the 1 bit of entropy, for fec packets, contains
the xor of the entropy of protected packets.
* 0x02 = FLAG_FEC_GROUP - indicates whether the fec byte is
present.
* 0x04 = FLAG_FEC - signifies that this packet represents an FEC
packet.
o FEC (FEC Group Number Offset): An FEC Group Number is the Packet
Number of the first packet in the FEC group. The FEC Group Number
Offset is an 8 bit unsigned value which should be subtracted from
the current packet's Packet Number to yield the FEC Group Number
for this packet. This is only present if the private flags
contain FLAG_FEC_GROUP. All packets within a single FEC group
must have Packet Numbers encoded into an identical number of bytes
(i.e., the Packet Number coding must not change during a group)
(TODO: Document the inputs to encryption and decryption and describe
trial decryption.)
6.3.1. Frame Packet
Beyond the Private Header, Frame Packets have a payload that is a
series of type-prefixed frames. The format of frame types is defined
later in this document, but the general format of a Frame Packet is
as follows:
+--------+---...---+--------+---...---+
| Type | Payload | Type | Payload |
+--------+---...---+--------+---...---+
6.3.2. FEC Packet
FEC packets (those packets with FLAG_FEC set) have a payload that
simply contains an XOR of the null-padded payload of each Data Packet
in the FEC group. FEC packets must also have FLAG_FEC_GROUP set.
+-----...----+
| Redundancy |
+-----...----+
7. Life of a QUIC Connection 7. Life of a QUIC Connection
7.1. Connection Establishment 7.1. Connection Establishment
A QUIC client is the endpoint that initiates a connection. QUIC's A QUIC client is the endpoint that initiates a connection. QUIC's
connection establishment intertwines version negotiation with the connection establishment intertwines version negotiation with the
crypto and transport handshakes to reduce connection establishment crypto and transport handshakes to reduce connection establishment
latency. We first describe version negotiation below. latency. We first describe version negotiation below.
(Describe Version Negotiation.) Each of the initial packets sent from the client to the server must
set the version flag, and must specify the version of the protocol
being used. Every packet sent by the client must have the version
flag on, until it receives a packet from the server with the version
flag off. After the server receives the first packet from the client
with the version flag off, it must ignore any (possibly delayed)
packets with the version flag on.
The rest of the connection establishment is described in the crypto When the server receives a packet with a Connection ID for a new
handshake document [QUIC-CRYPTO]. The crypto handshake is connection, it will compare the client's version to the versions it
encapsulated within Frame Packets, as stream data on the crypto supports. If the client's version is acceptable to the server, the
stream (described later in this section). server will use this protocol version for the lifetime of the
connection. In this case, all packets sent by the server will have
the version flag off.
During connection establishment, QUIC sends various "Tags" inside the If the client's version is not acceptable to the server, a 1-RTT
handshake packets for negotiating transport parameters. The delay will be incurred. The server will send a Version Negotiation
currently used Tags are described later in the document. Packet to the client. This packet will have the version flag set and
will include the server's set of supported versions.
When the client receives a Version Negotiation Packet from the
server, it will select an acceptable protocol version and resend all
packets using this version. These packet must continue to have the
version flag set and must include the new negotiated protocol
version. Eventually, the client receives the first Regular Packet
(i.e. not a Version Negotiation Packet) from the server indicating
the end of version negotiation, and the client now sends all
subsequent packets with the version flag off.
In order to avoid downgrade attacks, the version of the protocol that
the client specified in the first packet and the set of versions
supported by the server must be included in the crypto handshake
data. The client needs to verify that the server's version list from
the handshake matches the list of versions in the Version Negotiation
Packet. The server needs to verify that the client's version from
the handshake represents a version of the protocol that it does not
actually support.
The rest of the connection establishment is described in the
handshake document [QUIC-CRYPTO]. The crypto handshake is performed
over the dedicated crypto stream (Stream ID 1).
During connection establishment, the handshake must negotiate various
transport parameters. The currently defined transport parameters are
described later in the document.
7.2. Data Transfer 7.2. Data Transfer
QUIC implements connection reliability, congestion control, and flow QUIC implements connection reliability, congestion control, and flow
control. QUIC flow control closely follows HTTP/2's flow control. control. QUIC flow control closely follows HTTP/2's flow control.
QUIC reliability and congestion control are described in an QUIC reliability and congestion control are described in an
accompanying document. A QUIC connection uses a single packet accompanying document. A QUIC connection uses a single packet
sequence number space for shared congestion control and loss recovery sequence number space for shared congestion control and loss recovery
across the connection. across the connection.
skipping to change at page 17, line 19 skipping to change at page 21, line 19
A stream frame must always have either non-zero data length or the A stream frame must always have either non-zero data length or the
FIN bit set. FIN bit set.
8.3. ACK Frame 8.3. ACK Frame
The ACK frame is sent to inform the peer which packets have been The ACK frame is sent to inform the peer which packets have been
received, as well as which packets are still considered missing by received, as well as which packets are still considered missing by
the receiver (the contents of missing packets may need to be resent). the receiver (the contents of missing packets may need to be resent).
The design of QUIC's ACK frame is different from TCP's and SCTP's The design of QUIC's ACK frame is different from TCP's and SCTP's
SACK representations in that QUIC ACKs indicate the largest sequence SACK representations in that QUIC ACKs indicate the largest packet
number observed thus far followed by a list of missing packet, or number observed thus far followed by a list of missing packet, or
NACK, ranges indicating gaps in packets received below this sequence NACK, ranges indicating gaps in packets received below this packet
number. To limit the NACK ranges to the ones that haven't yet been number. To limit the NACK ranges to the ones that haven't yet been
communicated to the peer, the peer periodically sends STOP_WAITING communicated to the peer, the peer periodically sends STOP_WAITING
frames that signal the receiver to stop waiting for packets below a frames that signal the receiver to stop waiting for packets below a
specified squence number, raising the "least unacked" sequence number specified sequence number, raising the "least unacked" packet number
at the receiver. A sender of an ACK frame thus reports only those at the receiver. A sender of an ACK frame thus reports only those
NACK ranges between the received least unacked and the reported NACK ranges between the received least unacked and the reported
largest observed sequence numbers. The frame is as follows: largest observed packet numbers. The frame is as follows:
0 1 N 0 1 N
+--------+--------+---------------------------------------------------+ +--------+--------+---------------------------------------------------+
|Type (8)|Received| Largest Observed (8, 16, 32, or 48 bits) | | Type |Received| Largest Observed |
| |Entropy | (variable length) | | (8) |Entropy | (8, 16, 32, or 48 bits) |
+--------+--------+---------------------------------------------------+ +--------+--------+---------------------------------------------------+
N+1 N+2 N+3 N+4 N+8 N+1 N+2 N+3 N+4 N+8
+--------+--------+---------+--------+--------------------------------+ +--------+--------+---------+--------+--------------------------------+
|Largest Observed | Num | Delta | Time Since Largest Observed | | Ack Delay | Num | Delta | First Timestamp |
| Delta Time (16) |Timestamp|Largest | | | Time (16) |Timestamp|Largest | (32 bits) |
| | | (8) |Observed| | | | (8) |Observed| |
+--------+--------+---------+--------+--------------------------------+ +--------+--------+---------+--------+--------------------------------+
N+9 N+11 - X N+9 N+11 - X
+--------+------------------+ +--------+-------------------+
| Delta | Time | | Delta | Time Since |
|Largest | Since Previous | |Largest | Previous Timestamp| <-- Repeat (NumTimestamp - 1) times
|Observed|Timestamp (Repeat)| |Observed| (16 bits) |
+--------+------------------+ +--------+-------------------+
X X+1 - Y Y+1 X X+1 - Y Y+1
+--------+-------------------------------------------------+--------+ +--------+-------------------------------------------------+--------+
| Number | Missing Packet Sequence Number Delta | Range | | Number | Missing Packet Sequence Number Delta | Range |
| Ranges | (repeats Number Ranges times with Range Length) | Length | | Ranges | (8, 16, 32, or 48 bits) | Length |
| (opt) | |(Repeat)| | (opt) | (repeats Number Ranges times) |(Repeat)|
+--------+-------------------------------------------------+--------+ +--------+-------------------------------------------------+--------+
Y+2 Y+3 - Z Y+2 Y+3 - Z
+--------+-----------------------------------------------------+ +--------+-----------------------------------------------------+
| Number | Revived Packet (8, 16, 32, or 48 bits) | | Number | Revived Packet Number |
| Revived| Sequence Number (variable length) | | Revived| (8, 16, 32, or 48 bits, same as Largest Observed) |
| (opt) | (repeats Number Revied times) | | (opt) | (repeats Number Revived times) |
+--------+-----------------------------------------------------+ +--------+-----------------------------------------------------+
The fields in the ACK frame are as follows: The fields in the ACK frame are as follows:
o Frame Type: The Frame Type byte is an 8-bit value containing o Frame Type: The Frame Type byte is an 8-bit value containing
various flags (01ntllmmB). various flags (01ntllmmB).
* The first two bits must be set to 01 indicating that this is an * The first two bits must be set to 01 indicating that this is an
ACK frame. ACK frame.
* The 'n' bit indicates whether the frame has any NACK ranges. * The 'n' bit indicates whether the frame has any NACK ranges.
* The 't' bit indicates whether the ACK frame has been truncated. * The 't' bit indicates whether the ACK frame has been truncated.
Truncation can happen when the complete ACK frame does not fit Truncation can happen when the complete ACK frame does not fit
within a single QUIC Packet, or when the number of NACK ranges within a single QUIC Packet, or when the number of NACK ranges
exceeds the maximum number of reportable NACK ranges (255). exceeds the maximum number of reportable NACK ranges (255).
When truncated, the ACK frame limits the largest observed When truncated, the ACK frame limits the largest observed
sequence number to the largest that can be reported, even packet number to the largest that can be reported, even though
though the receiver may have received packets with sequence the receiver may have received packets with packet numbers
numbers larger than the largest observed. larger than the largest observed.
* The two 'll' bits encode the length of the Largest Observed * The two 'll' bits encode the length of the Largest Observed
field as 1, 2, 4, or 6 bytes long. field as 1, 2, 4, or 6 bytes long.
* The two 'mm' bits encode the length of the Missing Packet * The two 'mm' bits encode the length of the Missing Packet
Sequence Number Delta field as 1, 2, 4, or 6 bytes long. Sequence Number Delta field as 1, 2, 4, or 6 bytes long.
o Received Entropy: An 8 bit unsigned value specifying the o Received Entropy: An 8 bit unsigned value specifying the
cumulative hash of entropy in all received packets up to the cumulative hash of entropy in all received packets up to the
largest observed packet. Entropy accumulation is described later largest observed packet. Entropy accumulation is described later
in this section. in this section.
o Largest Observed: A variable-sized unsigned value representing the o Largest Observed: A variable-sized unsigned value representing the
largest sequence number the peer has observed. When an ACK frame largest packet number the peer has observed. When an ACK frame is
is truncated, it indicates a sequence number greater than the truncated, it indicates a packet number greater than the specified
specified largest observed has been received, but information largest observed has been received, but information about those
about those additional receptions can't fit into this frame additional receptions can't fit into this frame (typically due to
(typically due to packet size restrictions). packet size restrictions).
o Largest Observed Delta Time: A 16 bit unsigned float with 11 o Ack Delay Time: A 16-bit unsigned float with 11 explicit bits of
explicit bits of mantissa and 5 bits of explicit exponent, mantissa and 5 bits of explicit exponent, specifying the time
specifying the time elapsed in microseconds from when largest elapsed in microseconds from when largest observed was received
observed was received until this Ack frame was sent. The bit until this Ack frame was sent. The bit format is loosely modeled
format is loosely modeled after IEEE 754. For example, 1 after IEEE 754. For example, 1 microsecond is represented as 0x1,
microsecond is represented as 0x1, which has an exponent of zero, which has an exponent of zero, presented in the 5 high order bits,
presented in the 5 high order bits, and mantissa of 1, presented and mantissa of 1, presented in the 11 low order bits. When the
in the 11 low order bits. When the explicit exponent is greater explicit exponent is greater than zero, an implicit high-order
than zero, an implicit high-order 12th bit of 1 is assumed in the 12th bit of 1 is assumed in the mantissa. For example, a floating
mantissa. For example, a floatingvalue of 0x800 has an explicit value of 0x800 has an explicit exponent of 1, as well as an
exponent of 1, as well as an explicit mantissa of 0, but then has explicit mantissa of 0, but then has an effective mantissa of 4096
an effective mantissa of 4096 (12th bit is assumed to be 1). (12th bit is assumed to be 1). Additionally, the actual exponent
Additionally, the actual exponent is one-less than the explicit is one-less than the explicit exponent, and the value represents
exponent, and the value represents 4096 microseconds. Any values 4096 microseconds. Any values larger than the representable range
larger than the representable range are clamped to 0xFFFF. are clamped to 0xFFFF.
o Num Timestamp: An 8-bit unsigned value specifying the number of o Timestamp Section:
TCP timestamps that are included in this frame. There will be
this many pairs of <sequence number, timestamp> following in the
timestamps.
o Delta Largest Observed: An 8-bit unsigned value specifying the * Num Timestamp: An 8-bit unsigned value specifying the number of
sequence number delta from the first timestamp to the largest timestamps that are included in this ack frame. There will be
observed. this many pairs of <packet number, timestamp> following in the
timestamps.
o Time Since Largest Observed: A 32-bit unsigned value specifying * Delta Largest Observed: An 8-bit unsigned value specifying the
the first timestamp. This is the time delta in microseconds from packet number delta from the first timestamp to the largest
the time the receiver's packet framer was created. observed. Therefore, the packet number is the largest observed
minus the delta largest observed.
o Time Since Previous Timestamp: A 16-bit unsigned value specifying * First Timestamp: A 32-bit unsigned value specifying the time
the first timestamp. This is the time delta from the previous delta in microseconds, from the beginning of the connection of
timestamp. the arrival of the packet specified by Largest Observed minus
Delta Largest Observed.
o Num Ranges: An optional 8-bit unsigned value specifying the number * Delta Largest Observed (Repeated): (Same as above.)
of missing packet ranges between largest observed and least
unacked. Only present if the 'n' flag bit is 1.
o Missing Packet Sequence Number Delta: A variable-sized sequence * Time Since Previous Timestamp (Repeated): A 16-bit unsigned
number delta. For the first missing packet range, it is a delta value specifying delta from the previous timestamp. It is
from the largest observed. For subsequent nack ranges, it is the encoded in the same format as the Ack Delay Time.
number of packets received between ranges. In the case of the
first nack range, a value of 0 specifies that the packet reported
as the largest observed is missing. In the case of the later nack
ranges, a value of 0 indicates the missing packet ranges are
contiguous (used only when more than 256 packets in a row were
lost).
o Range Length: An 8-bit unsigned value specifying one less than the o Missing Packet Section:
number of sequential nacks in the range.
o Num Revived: An 8-bit unsigned value specifying the number of * Num Ranges: An optional 8-bit unsigned value specifying the
revived packets, recovered via FEC. Just like the Num Ranges number of missing packet ranges between largest observed and
field, this field is only present if the 'n' flag bit is 1. least unacked. Only present if the 'n' flag bit is 1.
o Revived Packet Sequence Number: A variable-sized unsigned value * Missing Packet Sequence Number Delta: A variable-sized packet
representing a packet the peer has revived via FEC. Its length is number delta. For the first missing packet range, it is a
the same as the length of the Largest Observed field. All delta from the largest observed. For subsequent nack ranges,
sequence numbers in this list are sorted in ascending order it is the number of packets received between ranges. In the
(smallest first) and must also be present in the list of NACK case of the first nack range, a value of 0 specifies that the
ranges. packet reported as the largest observed is missing. In the
case of the later nack ranges, a value of 0 indicates the
missing packet ranges are contiguous (used only when more than
256 packets in a row were lost).
* Range Length: An 8-bit unsigned value specifying one less than
the number of sequential nacks in the range.
o Revived Packet Section:
* Num Revived: An 8-bit unsigned value specifying the number of
revived packets, recovered via FEC. Just like the Num Ranges
field, this field is only present if the 'n' flag bit is 1.
* Revived Packet Sequence Number: A variable-sized unsigned value
representing a packet the peer has revived via FEC. Its length
is the same as the length of the Largest Observed field. All
packet numbers in this list are sorted in ascending order
(smallest first) and must also be present in the list of NACK
ranges.
8.3.1. Entropy Accumulation 8.3.1. Entropy Accumulation
The entropy bits for a subset of packets (known to a receiver or The entropy bits for a subset of packets (known to a receiver or
sender) are accumulated into an 8 bit unsigned value, and similarly sender) are accumulated into an 8 bit unsigned value, and similarly
presented in both a STOP_WAITING frame and an ACK frame. If we presented in both a STOP_WAITING frame and an ACK frame. If we
defined E(k) to be the FLAG_ENTROPY bit present in packet sequence defined E(k) to be the FLAG_ENTROPY bit present in packet number k,
number k, then the k'th packet's contribution C(k) is defined to be then the k'th packet's contribution C(k) is defined to be E(k) left
E(k) left shifted by k mod 8 bits. The accumulated entropy is then shifted by k mod 8 bits. The accumulated entropy is then the
the bitwise-XOR sum of the contributions C(k), for all packets in the bitwise-XOR sum of the contributions C(k), for all packets in the
desired subset. desired subset.
8.4. STOP_WAITING Frame 8.4. STOP_WAITING Frame
The STOP_WAITING frame is sent to inform the peer that it should not The STOP_WAITING frame is sent to inform the peer that it should not
continue to wait for packets with sequence numbers lower than a continue to wait for packets with packet numbers lower than a
specified value. The sequence number is encoded in 1, 2, 4 or 6 specified value. The packet number is encoded in 1, 2, 4 or 6 bytes,
bytes, using the same coding length as is specified for the sequence using the same coding length as is specified for the packet number
number for the enclosing packet's header (specified in the QUIC Frame for the enclosing packet's header (specified in the QUIC Frame
Packet's Public Flags field.) The frame is as follows: Packet's Public Flags field.) The frame is as follows:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+--------+--------+--------+--------+--------+--------+-------+-------+ +--------+--------+--------+--------+--------+--------+-------+-------+
|Type (8)|Sent | Least unacked delta (8, 16, 32, or 48 bits) | |Type (8)|Sent | Least unacked delta (8, 16, 32, or 48 bits) |
| |Entropy | (variable length) | | |Entropy | (variable length) |
+--------+--------+--------+--------+--------+--------+-------+-------+ +--------+--------+--------+--------+--------+--------+-------+-------+
The fields in the STOP_WAITING frame are as follows: The fields in the STOP_WAITING frame are as follows:
o Frame Type: The Frame Type byte is an 8-bit value that must be set o Frame Type: The Frame Type byte is an 8-bit value that must be set
to 0x06 indicating that this is a STOP_WAITING frame. to 0x06 indicating that this is a STOP_WAITING frame.
o Sent Entropy: An 8-bit unsigned value specifying the cumulative o Sent Entropy: An 8-bit unsigned value specifying the cumulative
hash of entropy in all sent packets up to the packet with sequence hash of entropy in all sent packets up to the packet with packet
number one less than the least unacked packet. [See "Entropy number one less than the least unacked packet. [See "Entropy
Accumulation" section in the ACK frame section for details of this Accumulation" section in the ACK frame section for details of this
calculation.] calculation.]
o Least Unacked Delta: A variable length sequence number delta with o Least Unacked Delta: A variable length packet number delta with
the same length as the packet header's sequence number. In the the same length as the packet header's packet number. In the case
case of an FEC revived packet, the same length as the other of an FEC revived packet, the same length as the other packets in
packets in the FEC group. Subtract it from the header's packet the FEC group. Subtract it from the header's packet number to
sequence number to determine the least unacked. The resulting determine the least unacked. The resulting least unacked is the
least unacked is the smallest sequence number of any packet for smallest packet number of any packet for which the sender is still
which the sender is still awaiting an ack. If the receiver is awaiting an ack. If the receiver is missing any packets smaller
missing any packets smaller than this value, the receiver should than this value, the receiver should consider those packets to be
consider those packets to be irrecoverably lost. irrecoverably lost.
8.5. WINDOW_UPDATE Frame 8.5. WINDOW_UPDATE Frame
The WINDOW_UPDATE frame is used to inform the peer of an increase in The WINDOW_UPDATE frame is used to inform the peer of an increase in
an endpoint's flow control receive window. The stream ID can be 0, an endpoint's flow control receive window. The stream ID can be 0,
indicating this WINDOW_UPDATE applies to the connection level flow indicating this WINDOW_UPDATE applies to the connection level flow
control window, or > 0 indicating that the specified stream should control window, or > 0 indicating that the specified stream should
increase its flow control window. The frame is as follows: increase its flow control window. The frame is as follows:
An absolute byte offset is specified, and the receiver of a An absolute byte offset is specified, and the receiver of a
WINDOW_UPDATE frame may only send up to that number of bytes on the WINDOW_UPDATE frame may only send up to that number of bytes on the
specified stream. Violating flow control by sending further bytes specified stream. Violating flow control by sending further bytes
will result in the receiving endpoint closing the connection. will result in the receiving endpoint closing the connection.
On receipt of multiple WINDOW_UPDATE frames for a specific stream ID, On receipt of multiple WINDOW_UPDATE frames for a specific stream ID,
it is only necessary to keep track of the maximum byte offset. it is only necessary to keep track of the maximum byte offset.
Both stream and session windows start with a default value of 16 KB, Both stream and session windows start with a default value of 16 KB,
but this is typically increased during the handshake. To do this, an but this is typically increased during the handshake. To do this, an
endpoint should include SFCW (Stream Flow Control Window) and CFCW endpoint should negotiate the SFCW (Stream Flow Control Window) and
(Connection/Session Flow Control Window) tags in the CHLO/SHLO (tags CFCW (Connection/Session Flow Control Window) parameters in the
are described in the QUIC Crypto document). The value associated handshake. The value associated with each tag should be the number
with each tag should be the number of bytes for initial stream window of bytes for initial stream window and initial connection window
and initial connection window respectively. respectively.
The frame is as follows: The frame is as follows:
0 1 4 5 12 0 1 4 5 12
+--------+--------+-- ... --+-------+--------+-- ... --+-------+ +--------+--------+-- ... --+-------+--------+-- ... --+-------+
|Type(8) | Stream ID (32 bits) | Byte offset (64 bits) | |Type(8) | Stream ID (32 bits) | Byte offset (64 bits) |
+--------+--------+-- ... --+-------+--------+-- ... --+-------+ +--------+--------+-- ... --+-------+--------+-- ... --+-------+
The fields in the WINDOW_UPDATE frame are as follows: The fields in the WINDOW_UPDATE frame are as follows:
o Frame Type: The Frame Type byte is an 8-bit value that must be set o Frame Type: The Frame Type byte is an 8-bit value that must be set
to 0x04 indicating that this is a WINDOW_UPDATE frame. to 0x04 indicating that this is a WINDOW_UPDATE frame.
o Stream ID: ID of the stream whose flow control windows is begin o Stream ID: ID of the stream whose flow control windows is being
updated, or 0 to specify the connection-level flow control window. updated, or 0 to specify the connection-level flow control window.
o Byte offset: A 64-bit unsigned integer indicating the absolute o Byte offset: A 64-bit unsigned integer indicating the absolute
byte offset of data which can be sent on the given stream. In the byte offset of data which can be sent on the given stream. In the
case of connection level flow control, the cumulative number of case of connection level flow control, the cumulative number of
bytes which can be sent on all currently open streams. bytes which can be sent on all currently open streams.
8.6. BLOCKED Frame 8.6. BLOCKED Frame
The BLOCKED frame is used to indicate to the remote endpoint that The BLOCKED frame is used to indicate to the remote endpoint that
skipping to change at page 23, line 47 skipping to change at page 28, line 15
stream, so the stream should be closed. The frame is as follows: stream, so the stream should be closed. The frame is as follows:
0 1 4 5 12 8 16 0 1 4 5 12 8 16
+-------+--------+-- ... ----+--------+-- ... ------+-------+-- ... ------+ +-------+--------+-- ... ----+--------+-- ... ------+-------+-- ... ------+
|Type(8)| StreamID (32 bits) | Byte offset (64 bits)| Error code (32 bits)| |Type(8)| StreamID (32 bits) | Byte offset (64 bits)| Error code (32 bits)|
+-------+--------+-- ... ----+--------+-- ... ------+-------+-- ... ------+ +-------+--------+-- ... ----+--------+-- ... ------+-------+-- ... ------+
The fields in a RST_STREAM frame are as follows: The fields in a RST_STREAM frame are as follows:
o Frame type: The Frame Type is an 8-bit value that must be set to o Frame type: The Frame Type is an 8-bit value that must be set to
0x04 specifying that this is a RST_STREAM frame. 0x01 specifying that this is a RST_STREAM frame.
o Stream ID: The 32-bit Stream ID of the stream being terminated. o Stream ID: The 32-bit Stream ID of the stream being terminated.
o Byte offset: A 64-bit unsigned integer indicating the absolute o Byte offset: A 64-bit unsigned integer indicating the absolute
byte offset of the end of data for this stream. byte offset of the end of data for this stream.
o Error code: A 32-bit QuicErrorCode which indicates why the stream o Error code: A 32-bit QuicErrorCode which indicates why the stream
is being closed. QuicErrorCodes are listed later in this is being closed. QuicErrorCodes are listed later in this
document. document.
skipping to change at page 25, line 43 skipping to change at page 30, line 8
sender of the GOAWAY message. If no streams were replied to, this sender of the GOAWAY message. If no streams were replied to, this
value must be set to 0. value must be set to 0.
o Reason Phrase Length: A 16-bit unsigned number specifying the o Reason Phrase Length: A 16-bit unsigned number specifying the
length of the reason phrase. This may be zero if the sender length of the reason phrase. This may be zero if the sender
chooses to not give details beyond the error code. chooses to not give details beyond the error code.
o Reason Phrase: An optional human-readable explanation for why the o Reason Phrase: An optional human-readable explanation for why the
connection was closed. connection was closed.
9. Quic Connection Negotiation Tags 9. QUIC Transport Parameters
(TODO: List Tags.) The handshake is responsible for negotiating a variety of transport
parameters for a QUIC connection.
9.1. Required Parameters
o SFCW - Stream Flow Control Window. The size in bytes of the
stream level flow control window.
o CFCW - Connection Flow Control Window. The size in bytes of the
connection level flow control window.
9.2. Optional Parameters
o SRBF - Socket receive buffer size in bytes. The peer may want to
limit their max CWND to something similar to the socket receive
buffer if they fear the peer may sometimes be delayed in reading
packets from kernel's socket buffer. Defaults to 256kbytes and
has a minimum value of 16kbytes.
o TCID - Connection ID truncation. Indicates support for truncated
Connection IDs. If sent by a peer, indicates the connection IDs
sent to the peer should be truncated to 0 bytes. Useful for cases
when a client ephemeral port is only used for a single connection.
o COPT - Connection Options are a repeated tag field. The field
contains any connection options being requested by the client or
server. These are typically used for experimentation and will
evolve over time. Example use cases include changing congestion
control algorithms and parameters such as initial window.
10. QuicErrorCodes 10. QuicErrorCodes
The number to code mappings for QuicErrorCodes are currently defined The number to code mappings for QuicErrorCodes are currently defined
in the Chromium source code in src/net/quic/quic_protocol.h. (TODO: in the Chromium source code in src/net/quic/quic_protocol.h. (TODO:
hardcode numbers and add them here) hardcode numbers and add them here)
o QUIC_NO_ERROR: There was no error. This is not valid for o QUIC_NO_ERROR: There was no error. This is not valid for
RST_STREAM frames or CONNECTION_CLOSE frames RST_STREAM frames or CONNECTION_CLOSE frames
o QUIC_STREAM_DATA_AFTER_TERMINATION: There were data frames after o QUIC_STREAM_DATA_AFTER_TERMINATION: There were data frames after
the a fin or reset. the a fin or reset.
o QUIC_SERVER_ERROR_PROCESSING_STREAM: There was some server error o QUIC_SERVER_ERROR_PROCESSING_STREAM: There was some server error
which halted stream processing. which halted stream processing.
o QUIC_MULTIPLE_TERMINATION_OFFSETS: The sender received two o QUIC_MULTIPLE_TERMINATION_OFFSETS: The sender received two
skipping to change at page 27, line 24 skipping to change at page 32, line 18
o QUIC_CRYPTO_INVALID_VALUE_LENGTH: Handshake message contained an o QUIC_CRYPTO_INVALID_VALUE_LENGTH: Handshake message contained an
invalid value length. invalid value length.
o QUIC_CRYPTO_MESSAGE_AFTER_HANDSHAKE_COMPLETE: A crypto message was o QUIC_CRYPTO_MESSAGE_AFTER_HANDSHAKE_COMPLETE: A crypto message was
received after the handshake was complete. received after the handshake was complete.
o QUIC_INVALID_CRYPTO_MESSAGE_TYPE: A crypto message was received o QUIC_INVALID_CRYPTO_MESSAGE_TYPE: A crypto message was received
with an illegal message tag. with an illegal message tag.
o QUIC_SEQUENCE_NUMBER_LIMIT_REACHED: Transmitting an additional o QUIC_SEQUENCE_NUMBER_LIMIT_REACHED: Transmitting an additional
packet would cause a sequence number to be reused. packet would cause a packet number to be reused.
11. Priority 11. Priority
(TODO: implement) (TODO: implement)
QUIC will use the HTTP/2 prioritization mechanism. Roughly, a stream QUIC will use the HTTP/2 prioritization mechanism. Roughly, a stream
may be dependent on another stream. In this situation, the "parent" may be dependent on another stream. In this situation, the "parent"
stream should effectively starve the "child" stream. In addition, stream should effectively starve the "child" stream. In addition,
parent streams have an explicit priority. Parent streams should not parent streams have an explicit priority. Parent streams should not
starve other parent streams, but should make progress proportional to starve other parent streams, but should make progress proportional to
skipping to change at page 28, line 15 skipping to change at page 33, line 9
corresponding direction. corresponding direction.
Stream flow control is handled by QUIC, and does not need to be re- Stream flow control is handled by QUIC, and does not need to be re-
implemented in HTTP/2. QUIC's flow controller replaces the two implemented in HTTP/2. QUIC's flow controller replaces the two
levels of poorly matched flow controllers in current HTTP/2 levels of poorly matched flow controllers in current HTTP/2
deployments---one at the HTTP/2 level, and the other at the TCP deployments---one at the HTTP/2 level, and the other at the TCP
level. level.
12.2. HTTP/2 Header Compression 12.2. HTTP/2 Header Compression
QUIC implements HPACK header compression [3] for HTTP/2, which QUIC implements HPACK header compression [4] for HTTP/2, which
unfortunately introduces some Head-of-Line blocking since HTTP/2 unfortunately introduces some Head-of-Line blocking since HTTP/2
header blocks must be decompressed in the order they were compressed. header blocks must be decompressed in the order they were compressed.
Since streams may be processed in arbitrary order at a receiver, Since streams may be processed in arbitrary order at a receiver,
strict ordering across headers is enforced by sending all headers on strict ordering across headers is enforced by sending all headers on
a dedicated headers stream, with Stream ID 3. An HTTP/2 receiver a dedicated headers stream, with Stream ID 3. An HTTP/2 receiver
using QUIC would thus process data from a stream only after receiving using QUIC would thus process data from a stream only after receiving
the corresponding header on the headers stream. the corresponding header on the headers stream.
Future work will tweak the compressor and decompressor in QUIC so Future work will tweak the compressor and decompressor in QUIC so
that the compressed output does not depend on unacked previous that the compressed output does not depend on unacked previous
compressed state. This could be done, perhaps, by creating compressed state. This could be done, perhaps, by creating
"checkpoints" of HPACK state which are updated when headers have been "checkpoints" of HPACK state which are updated when headers have been
acked. When compressing headers QUIC would only compress relative to acked. When compressing headers QUIC would only compress relative to
the previous "checkpoint". the previous "checkpoint".
12.3. Parsing HTTP/2 Headers 12.3. Parsing HTTP/2 Headers
HTTP/2 uses a SYN stream to create new streams and to negotiate Bytes sent on the dedicated headers stream are simply HTTP/2 HEADERS
various stream parameters, including stream priority. Since stream frames. The exact layout of these frames is described in RFC 7540
creation is implicit in QUIC, there is no equivalent of a SYN stream. [5].
Also, since there is no explicit stream priority in QUIC, the current
HTTP/2 mapping on QUIC communicates HTTP/2 stream priority by
prepending it to the beginning of the HTTP/2 headers in the headers
stream. Each HTTP/2 header sent on the headers stream is as follows:
0 3 4 7 8 11 12
+--------+- ... ---+--------+- ... --+--------+- ... ---+------ ...
| Priority | Stream ID | Headers length | Headers
+--------+- ... ---+--------+- ... --+--------+- ... ---+------ ...
Priority type: A 32-bit unsigned number specifying the stream's
HTTP/2 priority
Stream ID: A 32-bit unsigned number specifying the QUIC Stream ID
associated with this HTTP/2 header
Headers length: A 32-bit unsigned number encoding the length, in
bytes, of the compressed headers to follow
Headers: HTTP/2 compressed headers
12.4. Persistent Connections 12.4. Persistent Connections
Unlike when using TCP, the underlying connection for QUIC is Unlike when using TCP, the underlying connection for QUIC is
guaranteed to be persistent. The HTTP "Connection" header is guaranteed to be persistent. The HTTP "Connection" header is
therefore does not apply. For best performance, it is expected that therefore does not apply. For best performance, it is expected that
clients will not close a QUIC connection until the user navigates clients will not close a QUIC connection until the user navigates
away from all web pages using that connection, or until the server away from all web pages using that connection, or until the server
closes the connection. closes the connection.
skipping to change at page 29, line 41 skipping to change at page 34, line 16
Note that the server may reply with multiple field values or a comma- Note that the server may reply with multiple field values or a comma-
separated field value for Alternate-Protocol to indicate the various separated field value for Alternate-Protocol to indicate the various
transports it supports. transports it supports.
A server can also send a header to notify that QUIC should not be A server can also send a header to notify that QUIC should not be
used on this domain. If it sends the alternate-protocol-required used on this domain. If it sends the alternate-protocol-required
header, the client should remember to not use QUIC on that domain in header, the client should remember to not use QUIC on that domain in
future, and not do any UDP probing to see if QUIC is available. future, and not do any UDP probing to see if QUIC is available.
13. Recent Changes By Version 13. Handshake Protocol Requirements
QUIC provides a dedicated stream (Stream ID 1) to be used for
performing a combined connection and security handshake, but the
details of this handshake protocol are out of this document's scope.
However, QUIC does impose a number of requirements on any such
handshake protocol. The following list of requirements documents
properties of the current prototype handshake which should be
provided by any future handshake protocol.
13.1. Connection Establishment in 0-RTT
The QUIC handshake protocol manages to successfully achieve 0-RTT for
most connections, and is critical to QUIC's latency improvements.
13.2. Source Address Spoofing Defense
TCP verifies the client's address by burning a round trip on the SYN,
SYN_ACK exchange. QUIC uses a source address token delivered by the
server in a previous connection.
13.3. Opaque Source Address Tokens
QUIC servers store a number of pieces of data in the source address
token, for use on a subsequent connection from the same client. This
includes recently used source addresses, measured bandwidth to the
client, and server-designated connection IDs (for Stateless REJs).
An alternative handshake protocol's analog of a source address token
needs to be (i) opaque at the client, and (ii) large enough to permit
these bits of information to be stored. Alternatively, the handshake
protocol should have a different method to store this information at
the client.
13.4. Transport Parameter Negotiation
In addition to negotiating crypto parameters, the QUIC handshake also
negotiates QUIC and HTTP/2 level parameters, including max open QUIC
streams and other QUIC connection options.
13.5. Certificate Compression
The QUIC handshake compresses certificates so that an REJ, including
the common Google certificate chain, is able to fit into two 1350
byte packets. This helps to reduce the amplification attack
footprint of QUIC without reducing 0-RTT rate.
13.6. Server Config Update
QUIC uses a Server Config Update (SCUP) message to refresh the
source-address token (STK) and server config mid-connection,
extending the period over which 0-RTT connections can be established
by the client.
14. Recent Changes By Version
o Q009: added priority as the first 4 bytes on spdy streams. o Q009: added priority as the first 4 bytes on spdy streams.
o Q010: renumber the various frame types o Q010: renumber the various frame types
o Q011: shrunk the fnv128 hash on NULL encrypted packets from 16 o Q011: shrunk the fnv128 hash on NULL encrypted packets from 16
bytes to 12 bytes. bytes to 12 bytes.
o Q012: optimize the ack frame format to reduce the size and better o Q012: optimize the ack frame format to reduce the size and better
handle ranges of nacks, which should make truncated acks virtually handle ranges of nacks, which should make truncated acks virtually
skipping to change at page 30, line 42 skipping to change at page 36, line 26
o Q021: Crypto and headers streams are flow controlled (at stream o Q021: Crypto and headers streams are flow controlled (at stream
level) level)
o Q023: Ack frames include packet timestamps o Q023: Ack frames include packet timestamps
o Q024: HTTP/2-style header compression o Q024: HTTP/2-style header compression
o Q025: HTTP/2-style header keys. Removal of error_details from the o Q025: HTTP/2-style header keys. Removal of error_details from the
RST_STREAM frame. RST_STREAM frame.
o Q026: Token binding, adds expected leaf cert (XLCT) tag to client
hello
o Q027: Adds a nonce to the server hello
o Q029: Server and client honor QUIC_STREAM_NO_ERROR on early
response
. .
14. References 15. References
14.1. Normative References 15.1. Normative References
[RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
Requirement Levels", March 1997. Requirement Levels", March 1997.
14.2. Informative References 15.2. Informative References
[RFC7540] Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer [RFC7540] Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer
Protocol Version 2 (HTTP/2)", May 2015. Protocol Version 2 (HTTP/2)", May 2015.
[QUIC-CRYPTO] [QUIC-CRYPTO]
Langley, A. and W. Chang, "QUIC Crypto", June 2015. Langley, A. and W. Chang, "QUIC Crypto", June 2015.
[QUIC-CC] Swett, I. and J. Iyengar, "QUIC Loss Recovery and [QUIC-CC] Iyengar, J. and I. Swett, "QUIC Loss Recovery and
Congestion Control", June 2015. Congestion Control", December 2015.
14.3. URIs 15.3. URIs
[1] https://www.chromium.org/quic [1] https://goo.gl/dMVtFi
[2] http://goo.gl/jOvOQ5 [2] https://www.chromium.org/quic
[3] http://http2.github.io/http2-spec/compression.html [3] http://goo.gl/jOvOQ5
[4] http://http2.github.io/http2-spec/compression.html
[5] https://httpwg.github.io/specs/rfc7540.html#HEADERS
Authors' Addresses Authors' Addresses
Ryan Hamilton Ryan Hamilton
Google Google
Email: rch@google.com Email: rch@google.com
Janardhan Iyengar Janardhan Iyengar
Google Google
 End of changes. 91 change blocks. 
309 lines changed or deleted 553 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/