draft-ietf-quic-transport-03.txt   draft-ietf-quic-transport-04.txt 
QUIC J. Iyengar, Ed. QUIC J. Iyengar, Ed.
Internet-Draft Google Internet-Draft Google
Intended status: Standards Track M. Thomson, Ed. Intended status: Standards Track M. Thomson, Ed.
Expires: November 22, 2017 Mozilla Expires: December 15, 2017 Mozilla
May 21, 2017 June 13, 2017
QUIC: A UDP-Based Multiplexed and Secure Transport QUIC: A UDP-Based Multiplexed and Secure Transport
draft-ietf-quic-transport-03 draft-ietf-quic-transport-04
Abstract Abstract
This document defines the core of the QUIC transport protocol. This This document defines the core of the QUIC transport protocol. This
document describes connection establishment, packet format, document describes connection establishment, packet format,
multiplexing and reliability. Accompanying documents describe the multiplexing and reliability. Accompanying documents describe the
cryptographic handshake and loss detection. cryptographic handshake and loss detection.
Note to Readers Note to Readers
Discussion of this draft takes place on the QUIC working group Discussion of this draft takes place on the QUIC working group
mailing list (quic@ietf.org), which is archived at mailing list (quic@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/search/?email_list=quic . https://mailarchive.ietf.org/arch/search/?email_list=quic.
Working Group information can be found at https://github.com/quicwg ; Working Group information can be found at https://github.com/quicwg;
source code and issues list for this draft can be found at source code and issues list for this draft can be found at
https://github.com/quicwg/base-drafts/labels/transport . https://github.com/quicwg/base-drafts/labels/transport.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 November 22, 2017. This Internet-Draft will expire on December 15, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
skipping to change at page 3, line 8 skipping to change at page 3, line 8
5.8. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 18 5.8. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 18
5.8.1. Initial Packet Number . . . . . . . . . . . . . . . . 19 5.8.1. Initial Packet Number . . . . . . . . . . . . . . . . 19
5.9. Handling Packets from Different Versions . . . . . . . . 20 5.9. Handling Packets from Different Versions . . . . . . . . 20
6. Frames and Frame Types . . . . . . . . . . . . . . . . . . . 20 6. Frames and Frame Types . . . . . . . . . . . . . . . . . . . 20
7. Life of a Connection . . . . . . . . . . . . . . . . . . . . 22 7. Life of a Connection . . . . . . . . . . . . . . . . . . . . 22
7.1. Version Negotiation . . . . . . . . . . . . . . . . . . . 23 7.1. Version Negotiation . . . . . . . . . . . . . . . . . . . 23
7.1.1. Using Reserved Versions . . . . . . . . . . . . . . . 24 7.1.1. Using Reserved Versions . . . . . . . . . . . . . . . 24
7.2. Cryptographic and Transport Handshake . . . . . . . . . . 24 7.2. Cryptographic and Transport Handshake . . . . . . . . . . 24
7.3. Transport Parameters . . . . . . . . . . . . . . . . . . 25 7.3. Transport Parameters . . . . . . . . . . . . . . . . . . 25
7.3.1. Transport Parameter Definitions . . . . . . . . . . . 27 7.3.1. Transport Parameter Definitions . . . . . . . . . . . 27
7.3.2. Values of Transport Parameters for 0-RTT . . . . . . 27 7.3.2. Values of Transport Parameters for 0-RTT . . . . . . 28
7.3.3. New Transport Parameters . . . . . . . . . . . . . . 28 7.3.3. New Transport Parameters . . . . . . . . . . . . . . 28
7.3.4. Version Negotiation Validation . . . . . . . . . . . 28 7.3.4. Version Negotiation Validation . . . . . . . . . . . 28
7.4. Stateless Retries . . . . . . . . . . . . . . . . . . . . 29 7.4. Stateless Retries . . . . . . . . . . . . . . . . . . . . 30
7.5. Proof of Source Address Ownership . . . . . . . . . . . . 30 7.5. Proof of Source Address Ownership . . . . . . . . . . . . 30
7.5.1. Client Address Validation Procedure . . . . . . . . . 31 7.5.1. Client Address Validation Procedure . . . . . . . . . 31
7.5.2. Address Validation on Session Resumption . . . . . . 31 7.5.2. Address Validation on Session Resumption . . . . . . 32
7.5.3. Address Validation Token Integrity . . . . . . . . . 32 7.5.3. Address Validation Token Integrity . . . . . . . . . 32
7.6. Connection Migration . . . . . . . . . . . . . . . . . . 32 7.6. Connection Migration . . . . . . . . . . . . . . . . . . 33
7.6.1. Privacy Implications of Connection Migration . . . . 33 7.6.1. Privacy Implications of Connection Migration . . . . 33
7.6.2. Address Validation for Migrated Connections . . . . . 34 7.6.2. Address Validation for Migrated Connections . . . . . 34
7.7. Connection Termination . . . . . . . . . . . . . . . . . 34 7.7. Connection Termination . . . . . . . . . . . . . . . . . 34
8. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 35 8. Frame Types and Formats . . . . . . . . . . . . . . . . . . . 35
8.1. STREAM Frame . . . . . . . . . . . . . . . . . . . . . . 35 8.1. STREAM Frame . . . . . . . . . . . . . . . . . . . . . . 35
8.2. ACK Frame . . . . . . . . . . . . . . . . . . . . . . . . 37 8.2. ACK Frame . . . . . . . . . . . . . . . . . . . . . . . . 37
8.2.1. ACK Block Section . . . . . . . . . . . . . . . . . . 39 8.2.1. ACK Block Section . . . . . . . . . . . . . . . . . . 39
8.2.2. Timestamp Section . . . . . . . . . . . . . . . . . . 40 8.2.2. Timestamp Section . . . . . . . . . . . . . . . . . . 40
8.2.3. ACK Frames and Packet Protection . . . . . . . . . . 41 8.2.3. ACK Frames and Packet Protection . . . . . . . . . . 41
8.3. MAX_DATA Frame . . . . . . . . . . . . . . . . . . . . . 42 8.3. MAX_DATA Frame . . . . . . . . . . . . . . . . . . . . . 42
skipping to change at page 4, line 28 skipping to change at page 4, line 28
13.4. Stream Commitment Attack . . . . . . . . . . . . . . . . 68 13.4. Stream Commitment Attack . . . . . . . . . . . . . . . . 68
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 69 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 69
14.1. QUIC Transport Parameter Registry . . . . . . . . . . . 69 14.1. QUIC Transport Parameter Registry . . . . . . . . . . . 69
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 70 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 70
15.1. Normative References . . . . . . . . . . . . . . . . . . 70 15.1. Normative References . . . . . . . . . . . . . . . . . . 70
15.2. Informative References . . . . . . . . . . . . . . . . . 71 15.2. Informative References . . . . . . . . . . . . . . . . . 71
15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 72 15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 72 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 72
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 72 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 72
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 72 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 72
C.1. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 72 C.1. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 73
C.2. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 73 C.2. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 74
C.3. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 75 C.3. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 76
C.4. Since draft-hamilton-quic-transport-protocol-01 . . . . . 76 C.4. Since draft-hamilton-quic-transport-protocol-01 . . . . . 76
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 76
1. Introduction 1. Introduction
QUIC is a multiplexed and secure transport protocol that runs on top QUIC is a multiplexed and secure transport protocol that runs on top
of UDP. QUIC aims to provide a flexible set of features that allow of UDP. QUIC aims to provide a flexible set of features that allow
it to be a general-purpose transport for multiple applications. it to be a general-purpose transport for multiple applications.
QUIC implements techniques learned from experience with TCP, SCTP and QUIC implements techniques learned from experience with TCP, SCTP and
skipping to change at page 8, line 39 skipping to change at page 8, line 39
described in Section 7.1. described in Section 7.1.
4. Versions 4. Versions
QUIC versions are identified using a 32-bit value. QUIC versions are identified using a 32-bit value.
The version 0x00000000 is reserved to represent an invalid version. The version 0x00000000 is reserved to represent an invalid version.
This version of the specification is identified by the number This version of the specification is identified by the number
0x00000001. 0x00000001.
Version 0x000000001 of QUIC uses TLS as a cryptographic handshake Version 0x00000001 of QUIC uses TLS as a cryptographic handshake
protocol, as described in [QUIC-TLS]. protocol, as described in [QUIC-TLS].
Versions with the most significant 16 bits of the version number Versions with the most significant 16 bits of the version number
cleared are reserved for use in future IETF consensus documents. cleared are reserved for use in future IETF consensus documents.
Versions that follow the pattern 0x?a?a?a?a are reserved for use in Versions that follow the pattern 0x?a?a?a?a are reserved for use in
forcing version negotiation to be exercised. That is, any version forcing version negotiation to be exercised. That is, any version
number where the low four bits of all octets is 1010 (in binary). A number where the low four bits of all octets is 1010 (in binary). A
client or server MAY advertise support for any of these reserved client or server MAY advertise support for any of these reserved
versions. versions.
skipping to change at page 10, line 42 skipping to change at page 10, line 42
set to 1 for long headers and 0 for short headers. set to 1 for long headers and 0 for short headers.
Long Packet Type: The remaining seven bits of first octet of a long Long Packet Type: The remaining seven bits of first octet of a long
packet is the packet type. This field can indicate one of 128 packet is the packet type. This field can indicate one of 128
packet types. The types specified for this version are listed in packet types. The types specified for this version are listed in
Table 1. Table 1.
Connection ID: Octets 1 through 8 contain the connection ID. Connection ID: Octets 1 through 8 contain the connection ID.
Section 5.7 describes the use of this field in more detail. Section 5.7 describes the use of this field in more detail.
Packet Number: Octets 9 to 12 contain the packet number. {{packet- Packet Number: Octets 9 to 12 contain the packet number.
numbers} describes the use of packet numbers. Section 5.8 describes the use of packet numbers.
Version: Octets 13 to 16 contain the selected protocol version. Version: Octets 13 to 16 contain the selected protocol version.
This field indicates which version of QUIC is in use and This field indicates which version of QUIC is in use and
determines how the rest of the protocol fields are interpreted. determines how the rest of the protocol fields are interpreted.
Payload: Octets from 17 onwards (the rest of QUIC packet) are the Payload: Octets from 17 onwards (the rest of QUIC packet) are the
payload of the packet. payload of the packet.
The following packet types are defined: The following packet types are defined:
skipping to change at page 13, line 33 skipping to change at page 13, line 33
specific to the selected QUIC version. See Section 5.9 for details specific to the selected QUIC version. See Section 5.9 for details
on how packets from different versions of QUIC are interpreted. on how packets from different versions of QUIC are interpreted.
5.3. Version Negotiation Packet 5.3. Version Negotiation Packet
A Version Negotiation packet has long headers with a type value of A Version Negotiation packet has long headers with a type value of
0x01 and is sent only by servers. The Version Negotiation packet is 0x01 and is sent only by servers. The Version Negotiation packet is
a response to a client packet that contains a version that is not a response to a client packet that contains a version that is not
supported by the server. supported by the server.
The connection ID field contains a server-selected connection ID that The packet number, connection ID and version fields echo
the client MUST use for subsequent packets, see Section 5.7. corresponding values from the triggering client packet. This allows
clients some assurance that the server received the packet and that
The packet number and version fields echo corresponding values from the Version Negotiation packet was not carried in a packet with a
the triggering client packet. This allows clients some assurance spoofed source address.
that the server received the packet and that the Version Negotiation
packet was not carried in a packet with a spoofed source address.
The payload of the Version Negotiation packet is a list of 32-bit The payload of the Version Negotiation packet is a list of 32-bit
versions which the server supports, as shown below. versions which the server supports, as shown below.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Supported Version 1 (32) ... | Supported Version 1 (32) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [Supported Version 2 (32)] ... | [Supported Version 2 (32)] ...
skipping to change at page 14, line 51 skipping to change at page 14, line 51
uses the value provided by the server. uses the value provided by the server.
The packet number used for Client Initial packets is initialized with The packet number used for Client Initial packets is initialized with
a random value each time the new contents are created for the packet. a random value each time the new contents are created for the packet.
Retransmissions of the packet contents increment the packet number by Retransmissions of the packet contents increment the packet number by
one, see (Section 5.8). one, see (Section 5.8).
The payload of a Client Initial packet consists of a STREAM frame (or The payload of a Client Initial packet consists of a STREAM frame (or
frames) for stream 0 containing a cryptographic handshake message, frames) for stream 0 containing a cryptographic handshake message,
plus any PADDING frames necessary to ensure that the packet is at plus any PADDING frames necessary to ensure that the packet is at
least the minimum size (see Section 9). This stream frame always least the minimum PMTU size (see Section 9). The stream in this
starts at an offset of 0 (see Section 7.4). packet always starts at an offset of 0 (see Section 7.4) and the
complete cyptographic handshake message MUST fit in a single packet
(see Section 7.2).
The client uses the Client Initial Packet type for any packet that The client uses the Client Initial Packet type for any packet that
contains an initial cryptographic handshake message. This includes contains an initial cryptographic handshake message. This includes
all cases where a new packet containing the initial cryptographic all cases where a new packet containing the initial cryptographic
message needs to be created, this includes the packets sent after message needs to be created, this includes the packets sent after
receiving a Version Negotiation (Section 5.3) or Server Stateless receiving a Version Negotiation (Section 5.3) or Server Stateless
Retry packet (Section 5.4.2). Retry packet (Section 5.4.2).
5.4.2. Server Stateless Retry Packet 5.4.2. Server Stateless Retry Packet
A Server Stateless Retry packet uses long headers with a type value A Server Stateless Retry packet uses long headers with a type value
of 0x03. It carries cryptographic handshake messages and of 0x03. It carries cryptographic handshake messages and
acknowledgments. It is used by a server that wishes to perform a acknowledgments. It is used by a server that wishes to perform a
stateless retry (see Section 7.4). stateless retry (see Section 7.4).
The connection ID field in a Server Stateless Retry packet contains a The packet number and connection ID fields echo the corresponding
server selected value, see Section 5.7. fields from the triggering client packet. This allows a client to
verify that the server received its packet.
The packet number field echoes the packet number of the triggering
client packet. This allows a client to verify that the server
received its packet.
After receiving a Server Stateless Retry packet, the client uses a After receiving a Server Stateless Retry packet, the client uses a
new Client Initial packet containing the next cryptographic handshake new Client Initial packet containing the next cryptographic handshake
message. The client retains the state of its cryptographic message. The client retains the state of its cryptographic
handshake, but discards all transport state. In effect, the next handshake, but discards all transport state. In effect, the next
cryptographic handshake message is sent on a new connection. The new cryptographic handshake message is sent on a new connection. The new
Client Initial packet is sent in a packet with a newly randomized Client Initial packet is sent in a packet with a newly randomized
packet number and starting at a stream offset of 0. packet number and starting at a stream offset of 0.
Continuing the cryptographic handshake is necessary to ensure that an Continuing the cryptographic handshake is necessary to ensure that an
skipping to change at page 18, line 19 skipping to change at page 18, line 19
5.7. Connection ID 5.7. Connection ID
QUIC connections are identified by their 64-bit Connection ID. All QUIC connections are identified by their 64-bit Connection ID. All
long headers contain a Connection ID. Short headers indicate the long headers contain a Connection ID. Short headers indicate the
presence of a Connection ID using the CONNECTION_ID flag. When presence of a Connection ID using the CONNECTION_ID flag. When
present, the Connection ID is in the same location in all packet present, the Connection ID is in the same location in all packet
headers, making it straightforward for middleboxes, such as load headers, making it straightforward for middleboxes, such as load
balancers, to locate and use it. balancers, to locate and use it.
The client MUST choose a random connection ID and use it in Client The client MUST choose a random connection ID and use it in Client
Initial packets (Section 5.4.1). If the client has received any Initial packets (Section 5.4.1) and 0-RTT packets (Section 5.5). If
packet from the server, it uses the connection ID it received from the client has received any packet from the server, it uses the
the server. connection ID it received from the server for all packets other than
0-RTT packets.
When the server receives a Client Initial packet, it chooses a new When the server receives a Client Initial packet and decides to
value for the connection ID and sends that in its response. The proceed with the handshake, it chooses a new value for the connection
server MUST send a new connection ID in any packet that is sent in ID and sends that in a Server Cleartext packet. The server MAY
response to a Client Initial packet. This includes Version choose to use the value that the client initially selects.
Negotiation (Section 5.3), Server Stateless Retry (Section 5.4.2),
and the first Server Cleartext packet (Section 5.4.3). The server
MAY choose to use the value that the client initially selects.
A server MUST NOT propose a different connection ID in response to a Once the client receives the connection ID that the server has
Client Cleartext packet (Section 5.4.4). A Client Cleartext packet chosen, it uses this for all subsequent packets that it sends, except
is only sent after the server has committed to maintaining connection for any 0-RTT packets, which all have the same connection ID.
state.
5.8. Packet Numbers 5.8. Packet Numbers
The packet number is a 64-bit unsigned number and is used as part of The packet number is a 64-bit unsigned number and is used as part of
a cryptographic nonce for packet encryption. Each endpoint maintains a cryptographic nonce for packet encryption. Each endpoint maintains
a separate packet number for sending and receiving. The packet a separate packet number for sending and receiving. The packet
number for sending MUST increase by at least one after sending any number for sending MUST increase by at least one after sending any
packet, unless otherwise specified (see Section 5.8.1). packet, unless otherwise specified (see Section 5.8.1).
A QUIC endpoint MUST NOT reuse a packet number within the same A QUIC endpoint MUST NOT reuse a packet number within the same
skipping to change at page 26, line 17 skipping to change at page 26, line 17
language from Section 3 of [I-D.ietf-tls-tls13]. language from Section 3 of [I-D.ietf-tls-tls13].
uint32 QuicVersion; uint32 QuicVersion;
enum { enum {
initial_max_stream_data(0), initial_max_stream_data(0),
initial_max_data(1), initial_max_data(1),
initial_max_stream_id(2), initial_max_stream_id(2),
idle_timeout(3), idle_timeout(3),
truncate_connection_id(4), truncate_connection_id(4),
max_packet_size(5),
(65535) (65535)
} TransportParameterId; } TransportParameterId;
struct { struct {
TransportParameterId parameter; TransportParameterId parameter;
opaque value<0..2^16-1>; opaque value<0..2^16-1>;
} TransportParameter; } TransportParameter;
struct { struct {
select (Handshake.msg_type) { select (Handshake.msg_type) {
skipping to change at page 27, line 44 skipping to change at page 27, line 47
An endpoint MAY use the following transport parameters: An endpoint MAY use the following transport parameters:
truncate_connection_id (0x0004): The truncated connection identifier truncate_connection_id (0x0004): The truncated connection identifier
parameter indicates that packets sent to the peer can omit the parameter indicates that packets sent to the peer can omit the
connection ID. This can be used by an endpoint where the 5-tuple connection ID. This can be used by an endpoint where the 5-tuple
is sufficient to identify a connection. This parameter is zero is sufficient to identify a connection. This parameter is zero
length. Omitting the parameter indicates that the endpoint relies length. Omitting the parameter indicates that the endpoint relies
on the connection ID being present in every packet. on the connection ID being present in every packet.
max_packet_size (0x0005): The maximum packet size parameter places a
limit on the size of packets that the endpoint is willing to
receive, encoded as an unsigned 16-bit integer. This indicates
that packets larger than this limit will be dropped. The default
for this parameter is the maximum permitted UDP payload of 65527.
Values below 1252 are invalid. This limit only applies to
protected packets (Section 5.5).
7.3.2. Values of Transport Parameters for 0-RTT 7.3.2. Values of Transport Parameters for 0-RTT
Transport parameters from the server MUST be remembered by the client Transport parameters from the server MUST be remembered by the client
for use with 0-RTT data. If the TLS NewSessionTicket message for use with 0-RTT data. If the TLS NewSessionTicket message
includes the quic_transport_parameters extension, then those values includes the quic_transport_parameters extension, then those values
are used for the server values when establishing a new connection are used for the server values when establishing a new connection
using that ticket. Otherwise, the transport parameters that the using that ticket. Otherwise, the transport parameters that the
server advertises during connection establishment are used. server advertises during connection establishment are used.
A server can remember the transport parameters that it advertised, or A server can remember the transport parameters that it advertised, or
skipping to change at page 35, line 20 skipping to change at page 35, line 32
As described in Section 6, Regular packets contain one or more As described in Section 6, Regular packets contain one or more
frames. We now describe the various QUIC frame types that can be frames. We now describe the various QUIC frame types that can be
present in a Regular packet. The use of these frames and various present in a Regular packet. The use of these frames and various
frame header bits are described in subsequent sections. frame header bits are described in subsequent sections.
8.1. STREAM Frame 8.1. STREAM Frame
STREAM frames implicitly create a stream and carry stream data. The STREAM frames implicitly create a stream and carry stream data. The
type byte for a STREAM frame contains embedded flags, and is type byte for a STREAM frame contains embedded flags, and is
formatted as "11FDOOSS". These bits are parsed as follows: formatted as "11FSSOOD". These bits are parsed as follows:
o The first two bits must be set to 11, indicating that this is a o The first two bits must be set to 11, indicating that this is a
STREAM frame. STREAM frame.
o "F" is the FIN bit, which is used for stream termination. o "F" is the FIN bit, which is used for stream termination.
o The "SS" bits encode the length of the Stream ID header field.
The values 00, 01, 02, and 03 indicate lengths of 8, 16, 24, and
32 bits long respectively.
o The "OO" bits encode the length of the Offset header field. The
values 00, 01, 02, and 03 indicate lengths of 0, 16, 32, and 64
bits long respectively.
o The "D" bit indicates whether a Data Length field is present in o The "D" bit indicates whether a Data Length field is present in
the STREAM header. When set to 0, this field indicates that the the STREAM header. When set to 0, this field indicates that the
Stream Data field extends to the end of the packet. When set to Stream Data field extends to the end of the packet. When set to
1, this field indicates that Data Length field contains the length 1, this field indicates that Data Length field contains the length
(in bytes) of the Stream Data field. The option to omit the (in bytes) of the Stream Data field. The option to omit the
length should only be used when the packet is a "full-sized" length should only be used when the packet is a "full-sized"
packet, to avoid the risk of corruption via padding. packet, to avoid the risk of corruption via padding.
o The "OO" bits encode the length of the Offset header field as 0,
16, 32, or 64 bits long.
o The "SS" bits encode the length of the Stream ID header field as
8, 16, 24, or 32 bits.
A STREAM frame is shown below. A STREAM frame is shown below.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [Data Length (16)] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream ID (8/16/24/32) ... | Stream ID (8/16/24/32) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset (0/16/32/64) ... | Offset (0/16/32/64) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Data (*) ... | [Data Length (16)] | Stream Data (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: STREAM Frame Format Figure 7: STREAM Frame Format
The STREAM frame contains the following fields: The STREAM frame contains the following fields:
Data Length: An optional 16-bit unsigned number specifying the
length of the Stream Data field in this STREAM frame. This field
is present when the "D" bit is set to 1.
Stream ID: The stream ID of the stream (see Section 10.1). Stream ID: The stream ID of the stream (see Section 10.1).
Offset: A variable-sized unsigned number specifying the byte offset Offset: A variable-sized unsigned number specifying the byte offset
in the stream for the data in this STREAM frame. When the offset in the stream for the data in this STREAM frame. When the offset
length is 0, the offset is 0. The first byte in the stream has an length is 0, the offset is 0. The first byte in the stream has an
offset of 0. The largest offset delivered on a stream - the sum offset of 0. The largest offset delivered on a stream - the sum
of the re-constructed offset and data length - MUST be less than of the re-constructed offset and data length - MUST be less than
2^64. 2^64.
Stream Data: The bytes from the designated stream to be delivered. Stream Data: The bytes from the designated stream to be delivered.
Data Length: An optional 16-bit unsigned number specifying the
length of the Stream Data field in this STREAM frame. This field
is present when the "D" bit is set to 1.
A STREAM frame MUST have either non-zero data length or the FIN bit A STREAM frame MUST have either non-zero data length or the FIN bit
set. When the FIN flag is sent on an empty STREAM frame, the offset set. When the FIN flag is sent on an empty STREAM frame, the offset
in the STREAM frame MUST be one greater than the last data byte sent in the STREAM frame MUST be one greater than the last data byte sent
on this stream. on this stream.
Stream multiplexing is achieved by interleaving STREAM frames from Stream multiplexing is achieved by interleaving STREAM frames from
multiple streams into one or more QUIC packets. A single QUIC packet multiple streams into one or more QUIC packets. A single QUIC packet
MAY bundle STREAM frames from multiple streams. can include multiple STREAM frames from one or more streams.
Implementation note: One of the benefits of QUIC is avoidance of Implementation note: One of the benefits of QUIC is avoidance of
head-of-line blocking across multiple streams. When a packet loss head-of-line blocking across multiple streams. When a packet loss
occurs, only streams with data in that packet are blocked waiting for occurs, only streams with data in that packet are blocked waiting for
a retransmission to be received, while other streams can continue a retransmission to be received, while other streams can continue
making progress. Note that when data from multiple streams is making progress. Note that when data from multiple streams is
bundled into a single QUIC packet, loss of that packet blocks all bundled into a single QUIC packet, loss of that packet blocks all
those streams from making progress. An implementation is therefore those streams from making progress. An implementation is therefore
advised to bundle as few streams as necessary in outgoing packets advised to bundle as few streams as necessary in outgoing packets
without losing transmission efficiency to underfilled packets. without losing transmission efficiency to underfilled packets.
skipping to change at page 37, line 48 skipping to change at page 37, line 50
timestamps. Timestamps enable better congestion control, but are not timestamps. Timestamps enable better congestion control, but are not
required for correct loss recovery, and old timestamps are less required for correct loss recovery, and old timestamps are less
valuable, so it is not guaranteed every timestamp will be received by valuable, so it is not guaranteed every timestamp will be received by
the sender. A receiver SHOULD send a timestamp exactly once for each the sender. A receiver SHOULD send a timestamp exactly once for each
received packet containing retransmittable frames. A receiver MAY received packet containing retransmittable frames. A receiver MAY
send timestamps for non-retransmittable packets. A receiver MUST not send timestamps for non-retransmittable packets. A receiver MUST not
send timestamps in unprotected packets. send timestamps in unprotected packets.
A sender MAY intentionally skip packet numbers to introduce entropy A sender MAY intentionally skip packet numbers to introduce entropy
into the connection, to avoid opportunistic acknowledgement attacks. into the connection, to avoid opportunistic acknowledgement attacks.
The sender MUST close the connection if an unsent packet number is The sender SHOULD close the connection if an unsent packet number is
acknowledged. The format of the ACK frame is efficient at expressing acknowledged. The format of the ACK frame is efficient at expressing
blocks of missing packets; skipping packet numbers between 1 and 255 blocks of missing packets; skipping packet numbers between 1 and 255
effectively provides up to 8 bits of efficient entropy on demand, effectively provides up to 8 bits of efficient entropy on demand,
which should be adequate protection against most opportunistic which should be adequate protection against most opportunistic
acknowledgement attacks. acknowledgement attacks.
The type byte for a ACK frame contains embedded flags, and is The type byte for a ACK frame contains embedded flags, and is
formatted as "101NLLMM". These bits are parsed as follows: formatted as "101NLLMM". These bits are parsed as follows:
o The first three bits must be set to 101 indicating that this is an o The first three bits must be set to 101 indicating that this is an
ACK frame. ACK frame.
o The "N" bit indicates whether the frame has more than 1 range of o The "N" bit indicates whether the frame has more than 1 range of
acknowledged packets (i.e., whether the ACK Block Section contains acknowledged packets (i.e., whether the ACK Block Section contains
a Num Blocks field). a Num Blocks field).
o The two "LL" bits encode the length of the Largest Acknowledged o The two "LL" bits encode the length of the Largest Acknowledged
field as 1, 2, 4, or 6 bytes long. field. The values 00, 01, 02, and 03 indicate lengths of 8, 16,
32, and 48 bits respectively.
o The two "MM" bits encode the length of the ACK Block Length fields o The two "MM" bits encode the length of the ACK Block Length
as 1, 2, 4, or 6 bytes long. fields. The values 00, 01, 02, and 03 indicate lengths of 8, 16,
32, and 48 bits respectively.
An ACK frame is shown below. An ACK frame is shown below.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|[Num Blocks(8)]| NumTS (8) | |[Num Blocks(8)]| NumTS (8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Largest Acknowledged (8/16/32/48) ... | Largest Acknowledged (8/16/32/48) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 45, line 44 skipping to change at page 45, line 44
frames on the identified stream. A receiver of RST_STREAM can frames on the identified stream. A receiver of RST_STREAM can
discard any data that it already received on that stream. An discard any data that it already received on that stream. An
endpoint sends a RST_STREAM in response to a RST_STREAM unless the endpoint sends a RST_STREAM in response to a RST_STREAM unless the
stream is already closed. stream is already closed.
The RST_STREAM frame is as follows: The RST_STREAM frame is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream ID (32) | | Stream ID (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ Final Offset (64) + + Final Offset (64) +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields are: The fields are:
Error code: A 32-bit error code which indicates why the stream is Error code: A 32-bit error code which indicates why the stream is
being closed. being closed.
Stream ID: The 32-bit Stream ID of the stream being terminated. Stream ID: The 32-bit Stream ID of the stream being terminated.
skipping to change at page 49, line 7 skipping to change at page 49, line 7
streams could be in transit; using a larger stream number allows streams could be in transit; using a larger stream number allows
those streams to complete. those streams to complete.
In addition to initiating a graceful shutdown of a connection, GOAWAY In addition to initiating a graceful shutdown of a connection, GOAWAY
MAY be sent immediately prior to sending a CONNECTION_CLOSE frame MAY be sent immediately prior to sending a CONNECTION_CLOSE frame
that is sent as a result of detecting a fatal error. Higher-numbered that is sent as a result of detecting a fatal error. Higher-numbered
streams than those indicated in the GOAWAY frame can then be retried. streams than those indicated in the GOAWAY frame can then be retried.
9. Packetization and Reliability 9. Packetization and Reliability
The Path Maximum Transmission Unit (PTMU) is the maximum size of the The Path Maximum Transmission Unit (PMTU) is the maximum size of the
entire IP header, UDP header, and UDP payload. The UDP payload entire IP header, UDP header, and UDP payload. The UDP payload
includes the QUIC public header, protected payload, and any includes the QUIC public header, protected payload, and any
authentication fields. authentication fields.
All QUIC packets SHOULD be sized to fit within the estimated PMTU to All QUIC packets SHOULD be sized to fit within the estimated PMTU to
avoid IP fragmentation or packet drops. To optimize bandwidth avoid IP fragmentation or packet drops. To optimize bandwidth
efficiency, endpoints SHOULD use Packetization Layer PMTU Discovery efficiency, endpoints SHOULD use Packetization Layer PMTU Discovery
([RFC4821]) and MAY use PMTU Discovery ([RFC1191], [RFC1981]) for ([RFC4821]) and MAY use PMTU Discovery ([RFC1191], [RFC1981]) for
detecting the PMTU, setting the PMTU appropriately, and storing the detecting the PMTU, setting the PMTU appropriately, and storing the
result of previous PMTU determinations. result of previous PMTU determinations.
skipping to change at page 53, line 6 skipping to change at page 53, line 6
10.2. Life of a Stream 10.2. Life of a Stream
The semantics of QUIC streams is based on HTTP/2 streams, and the The semantics of QUIC streams is based on HTTP/2 streams, and the
lifecycle of a QUIC stream therefore closely follows that of an lifecycle of a QUIC stream therefore closely follows that of an
HTTP/2 stream [RFC7540], with some differences to accommodate the HTTP/2 stream [RFC7540], with some differences to accommodate the
possibility of out-of-order delivery due to the use of multiple possibility of out-of-order delivery due to the use of multiple
streams in QUIC. The lifecycle of a QUIC stream is shown in the streams in QUIC. The lifecycle of a QUIC stream is shown in the
following figure and described below. following figure and described below.
+--------+ +--------+
| |
| idle |
| |
+--------+
|
send/recv STREAM/RST
recv MSD/SB
|
v
recv FIN/ +--------+ send FIN/
recv RST | | send RST recv RST | | send RST
,-------------| idle |---------------. ,---------| open |-----------.
/ | | \ / | | \
| +--------+ | v +--------+ v
| | |
| send STREAM / recv STREAM |
| | |
| v |
| recv FIN/ +--------+ send FIN/ |
| recv RST | | send RST |
| ,---------| open |-----------. |
| / | | \ |
v v +--------+ v v
+----------+ +----------+ +----------+ +----------+
| half | | half | | half | | half |
| closed | | closed | | closed | | closed |
| (remote) | | (local) | | (remote) | | (local) |
+----------+ +----------+ +----------+ +----------+
| | | |
| send FIN/ +--------+ recv FIN/ | | send FIN/ +--------+ recv FIN/ |
\ send RST | | recv RST / \ send RST | | recv RST /
`----------->| closed |<-------------' `----------->| closed |<-------------'
| | | |
+--------+ +--------+
send: endpoint sends this frame send: endpoint sends this frame
recv: endpoint receives this frame recv: endpoint receives this frame
STREAM: a STREAM frame STREAM: a STREAM frame
FIN: FIN flag in a STREAM frame FIN: FIN flag in a STREAM frame
RST: RST_STREAM frame RST: RST_STREAM frame
MSD: MAX_STREAM_DATA frame
SB: STREAM_BLOCKED frame
Figure 11: Lifecycle of a stream Figure 11: Lifecycle of a stream
Note that this diagram shows stream state transitions and the frames Note that this diagram shows stream state transitions and the frames
and flags that affect those transitions only. For the purpose of and flags that affect those transitions only. It is possible for a
state transitions, the FIN flag is processed as a separate event to single frame to cause two transitions: receiving a RST_STREAM frame,
the frame that bears it; a STREAM frame with the FIN flag set can or a STREAM frame with the FIN flag cause the stream state to move
cause two state transitions. from "idle" to "open" and then immediately to one of the "half-
closed" states.
The recipient of a frame which changes stream state will have a The recipient of a frame that changes stream state will have a
delayed view of the state of a stream while the frame is in transit. delayed view of the state of a stream while the frame is in transit.
Endpoints do not coordinate the creation of streams; they are created Endpoints do not coordinate the creation of streams; they are created
unilaterally by either endpoint. Endpoints can use acknowledgments unilaterally by either endpoint. Endpoints can use acknowledgments
to understand the peer's subjective view of stream state at any given to understand the peer's subjective view of stream state at any given
time. time.
In the absence of more specific guidance elsewhere in this document, In the absence of more specific guidance elsewhere in this document,
implementations SHOULD treat the receipt of a frame that is not implementations SHOULD treat the receipt of a frame that is not
expressly permitted in the description of a state as a connection expressly permitted in the description of a state as a connection
error (see Section 12). error (see Section 12).
10.2.1. idle 10.2.1. idle
All streams start in the "idle" state. All streams start in the "idle" state.
The following transitions are valid from this state: The following transitions are valid from this state:
Sending or receiving a STREAM frame causes the identified stream to Sending or receiving a STREAM or RST_STREAM frame causes the
become "open". The stream identifier for a new stream is selected as identified stream to become "open". The stream identifier for a new
described in Section 10.1. The same STREAM frame can also cause a stream is selected as described in Section 10.1. A RST_STREAM frame,
stream to immediately become "half-closed" if the FIN flag is set. or a STREAM frame with the FIN flag set also causes a stream to
become "half-closed".
Receiving a STREAM frame on a peer-initiated stream (that is, a
packet sent by a server on an even-numbered stream or a client packet
on an odd-numbered stream) also causes all lower-numbered "idle"
streams in the same direction to become "open". This could occur if
a peer begins sending on streams in a different order to their
creation, or it could happen if packets are lost or reordered in
transit.
A RST_STREAM frame on an "idle" stream causes the stream to become
"half-closed". Sending a RST_STREAM frame causes the stream to
become "half-closed (local)"; receiving RST_STREAM causes the stream
to become "half-closed (remote)".
An endpoint might receive MAX_STREAM_DATA frames on peer-initiated
streams that are "idle" if there is loss or reordering of packets.
Receiving any frame other than STREAM, MAX_STREAM_DATA, An endpoint might receive MAX_STREAM_DATA or STREAM_BLOCKED frames on
STREAM_BLOCKED, or RST_STREAM on a stream in this state MUST be peer-initiated streams that are "idle" if there is loss or reordering
treated as a connection error (Section 12) of type YYYY. of packets. Receiving these frames also causes the stream to become
"open".
An endpoint MUST NOT send a STREAM or RST_STREAM frame for a stream An endpoint MUST NOT send a STREAM or RST_STREAM frame for a stream
ID that is higher than the peers advertised maximum stream ID (see ID that is higher than the peers advertised maximum stream ID (see
Section 8.5). Section 8.5).
10.2.2. open 10.2.2. open
A stream in the "open" state may be used by both peers to send frames A stream in the "open" state may be used by both peers to send frames
of any type. In this state, endpoints can send MAX_STREAM_DATA and of any type. In this state, endpoints can send MAX_STREAM_DATA and
MUST observe the value advertised by its receiving peer (see MUST observe the value advertised by its receiving peer (see
Section 11). Section 11).
From this state, either endpoint can send a frame with the FIN flag Opening a stream causes all lower-numbered streams in the same
set, which causes the stream to transition into one of the "half- direction to become open. Thus, opening an odd-numbered stream
closed" states. An endpoint sending an FIN flag causes the stream causes all "idle", odd-numbered streams with a lower identifier to
state to become "half-closed (local)". An endpoint receiving a FIN become open and the same applies to even numbered streams. Endpoints
flag causes the stream state to become "half-closed (remote)" once open streams in increasing numeric order, but loss or reordering can
all preceding data has arrived. The receiving endpoint MUST NOT cause packets that open streams to arrive out of order.
consider the stream state to have changed until all data has arrived.
From the "open" state, either endpoint can send a frame with the FIN
flag set, which causes the stream to transition into one of the
"half-closed" states. This flag can be set on the frame that opens
the stream, which causes the stream to immediately become "half-
closed". Once an endpoint has completed sending all stream data and
a STREAM frame with a FIN flag, the stream state becomes "half-closed
(local)". When an endpoint receives all stream data a FIN flag the
stream state becomes "half-closed (remote)". An endpoint MUST NOT
consider the stream state to have changed until all data has been
sent, received or discarded.
A RST_STREAM frame on an "open" stream causes the stream to become A RST_STREAM frame on an "open" stream causes the stream to become
"half-closed". Sending a RST_STREAM frame causes the stream to "half-closed". A stream that becomes "open" as a result of sending
become "half-closed (local)"; receiving RST_STREAM causes the stream or receiving RST_STREAM immediately becomes "half-closed". Sending a
to become "half-closed (remote)". RST_STREAM frame causes the stream to become "half-closed (local)";
receiving RST_STREAM causes the stream to become "half-closed
(remote)".
Any frame type that mentions a stream ID can be sent in this state. Any frame type that mentions a stream ID can be sent in this state.
10.2.3. half-closed (local) 10.2.3. half-closed (local)
A stream that is in the "half-closed (local)" state MUST NOT be used A stream that is in the "half-closed (local)" state MUST NOT be used
for sending on new STREAM frames. Retransmission of data that has for sending on new STREAM frames. Retransmission of data that has
already been sent on STREAM frames is permitted. An endpoint MAY already been sent on STREAM frames is permitted. An endpoint MAY
also send MAX_STREAM_DATA and RST_STREAM in this state. also send MAX_STREAM_DATA and RST_STREAM in this state.
skipping to change at page 56, line 23 skipping to change at page 56, line 23
and treat frames that arrive after this time as being in error. and treat frames that arrive after this time as being in error.
An endpoint will know the final offset of the data it receives on a An endpoint will know the final offset of the data it receives on a
stream when it reaches the "half-closed (remote)" state, see stream when it reaches the "half-closed (remote)" state, see
Section 11.3 for details. Section 11.3 for details.
A stream in this state can be used by the endpoint to send any frame A stream in this state can be used by the endpoint to send any frame
that mentions a stream ID. In this state, the endpoint MUST observe that mentions a stream ID. In this state, the endpoint MUST observe
advertised stream and connection data limits (see Section 11). advertised stream and connection data limits (see Section 11).
A stream can transition from this state to "closed" by completing A stream transitions from this state to "closed" by completing
transmission of all data. This includes sending all data carried in transmission of all data. This includes sending all data carried in
STREAM frames up including the terminal STREAM frame that contains a STREAM frames up including the terminal STREAM frame that contains a
FIN flag and receiving acknowledgment from the peer for all data. FIN flag.
A stream becomes "closed" when the endpoint sends and receives A stream becomes "closed" when the endpoint sends and receives
acknowledgment of a RST_STREAM frame. acknowledgment of a RST_STREAM frame.
10.2.5. closed 10.2.5. closed
The "closed" state is the terminal state for a stream. The "closed" state is the terminal state for a stream.
Once a stream reaches this state, no frames can be sent that mention Once a stream reaches this state, no frames can be sent that mention
the stream. Reordering might cause frames to be received after the stream. Reordering might cause frames to be received after
skipping to change at page 63, line 15 skipping to change at page 63, line 15
terminated connections. terminated connections.
An endpoint that chooses not to retransmit packets containing An endpoint that chooses not to retransmit packets containing
CONNECTION_CLOSE risks a peer missing the first such packet. The CONNECTION_CLOSE risks a peer missing the first such packet. The
only mechanism available to an endpoint that continues to receive only mechanism available to an endpoint that continues to receive
data for a terminated connection is to send a Public Reset packet. data for a terminated connection is to send a Public Reset packet.
12.2. Stream Errors 12.2. Stream Errors
If the error affects a single stream, but otherwise leaves the If the error affects a single stream, but otherwise leaves the
connection in a recoverable state, the endpoint can sent a RST_STREAM connection in a recoverable state, the endpoint can send a RST_STREAM
frame (Section 8.9) with an appropriate error code to terminate just frame (Section 8.9) with an appropriate error code to terminate just
the affected stream. the affected stream.
Stream 0 is critical to the functioning of the entire connection. If Stream 0 is critical to the functioning of the entire connection. If
stream 0 is closed with either a RST_STREAM or STREAM frame bearing stream 0 is closed with either a RST_STREAM or STREAM frame bearing
the FIN flag, an endpoint MUST generate a connection error of type the FIN flag, an endpoint MUST generate a connection error of type
QUIC_CLOSED_CRITICAL_STREAM. QUIC_CLOSED_CRITICAL_STREAM.
Some application protocols make other streams critical to that Some application protocols make other streams critical to that
protocol. An application protocol does not need to inform the protocol. An application protocol does not need to inform the
skipping to change at page 70, line 17 skipping to change at page 70, line 17
+--------+-------------------------+---------------+ +--------+-------------------------+---------------+
| 0x0000 | initial_max_stream_data | Section 7.3.1 | | 0x0000 | initial_max_stream_data | Section 7.3.1 |
| | | | | | | |
| 0x0001 | initial_max_data | Section 7.3.1 | | 0x0001 | initial_max_data | Section 7.3.1 |
| | | | | | | |
| 0x0002 | initial_max_stream_id | Section 7.3.1 | | 0x0002 | initial_max_stream_id | Section 7.3.1 |
| | | | | | | |
| 0x0003 | idle_timeout | Section 7.3.1 | | 0x0003 | idle_timeout | Section 7.3.1 |
| | | | | | | |
| 0x0004 | truncate_connection_id | Section 7.3.1 | | 0x0004 | truncate_connection_id | Section 7.3.1 |
| | | |
| 0x0005 | max_packet_size | Section 7.3.1 |
+--------+-------------------------+---------------+ +--------+-------------------------+---------------+
Table 4: Initial QUIC Transport Parameters Entries Table 4: Initial QUIC Transport Parameters Entries
15. References 15. References
15.1. Normative References 15.1. Normative References
[I-D.ietf-tls-tls13] [I-D.ietf-tls-tls13]
Rescorla, E., "The Transport Layer Security (TLS) Protocol Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", draft-ietf-tls-tls13-20 (work in progress), Version 1.3", draft-ietf-tls-tls13-20 (work in progress),
April 2017. April 2017.
[QUIC-RECOVERY] [QUIC-RECOVERY]
Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
and Congestion Control", draft-ietf-quic-recovery (work in and Congestion Control", draft-ietf-quic-recovery (work in
progress), May 2017. progress), June 2017.
[QUIC-TLS] [QUIC-TLS]
Thomson, M., Ed. and S. Turner, Ed., "Using Transport Thomson, M., Ed. and S. Turner, Ed., "Using Transport
Layer Security (TLS) to Secure QUIC", draft-ietf-quic-tls Layer Security (TLS) to Secure QUIC", draft-ietf-quic-tls
(work in progress), May 2017. (work in progress), June 2017.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
DOI 10.17487/RFC1191, November 1990, DOI 10.17487/RFC1191, November 1990,
<http://www.rfc-editor.org/info/rfc1191>. <http://www.rfc-editor.org/info/rfc1191>.
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August
1996, <http://www.rfc-editor.org/info/rfc1981>. 1996, <http://www.rfc-editor.org/info/rfc1981>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
 End of changes. 50 change blocks. 
123 lines changed or deleted 133 lines changed or added

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