draft-ietf-quic-transport-15.txt   draft-ietf-quic-transport-latest.txt 
QUIC Working Group J. Iyengar, Ed. QUIC Working Group J. Iyengar, Ed.
Internet-Draft Fastly Internet-Draft Fastly
Intended status: Standards Track M. Thomson, Ed. Intended status: Standards Track M. Thomson, Ed.
Expires: April 6, 2019 Mozilla Expires: April 21, 2019 Mozilla
October 3, 2018 October 18, 2018
QUIC: A UDP-Based Multiplexed and Secure Transport QUIC: A UDP-Based Multiplexed and Secure Transport
draft-ietf-quic-transport-15 draft-ietf-quic-transport-latest
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
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 April 6, 2019. This Internet-Draft will expire on April 21, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 4, line 7 skipping to change at page 4, line 7
7.4. CONNECTION_CLOSE frame . . . . . . . . . . . . . . . . . 69 7.4. CONNECTION_CLOSE frame . . . . . . . . . . . . . . . . . 69
7.5. APPLICATION_CLOSE frame . . . . . . . . . . . . . . . . . 70 7.5. APPLICATION_CLOSE frame . . . . . . . . . . . . . . . . . 70
7.6. MAX_DATA Frame . . . . . . . . . . . . . . . . . . . . . 71 7.6. MAX_DATA Frame . . . . . . . . . . . . . . . . . . . . . 71
7.7. MAX_STREAM_DATA Frame . . . . . . . . . . . . . . . . . . 72 7.7. MAX_STREAM_DATA Frame . . . . . . . . . . . . . . . . . . 72
7.8. MAX_STREAM_ID Frame . . . . . . . . . . . . . . . . . . . 73 7.8. MAX_STREAM_ID Frame . . . . . . . . . . . . . . . . . . . 73
7.9. PING Frame . . . . . . . . . . . . . . . . . . . . . . . 73 7.9. PING Frame . . . . . . . . . . . . . . . . . . . . . . . 73
7.10. BLOCKED Frame . . . . . . . . . . . . . . . . . . . . . . 74 7.10. BLOCKED Frame . . . . . . . . . . . . . . . . . . . . . . 74
7.11. STREAM_BLOCKED Frame . . . . . . . . . . . . . . . . . . 74 7.11. STREAM_BLOCKED Frame . . . . . . . . . . . . . . . . . . 74
7.12. STREAM_ID_BLOCKED Frame . . . . . . . . . . . . . . . . . 75 7.12. STREAM_ID_BLOCKED Frame . . . . . . . . . . . . . . . . . 75
7.13. NEW_CONNECTION_ID Frame . . . . . . . . . . . . . . . . . 75 7.13. NEW_CONNECTION_ID Frame . . . . . . . . . . . . . . . . . 75
7.14. RETIRE_CONNECTION_ID Frame . . . . . . . . . . . . . . . 77 7.14. STOP_SENDING Frame . . . . . . . . . . . . . . . . . . . 77
7.15. STOP_SENDING Frame . . . . . . . . . . . . . . . . . . . 77 7.15. RETIRE_CONNECTION_ID Frame . . . . . . . . . . . . . . . 77
7.16. ACK Frame . . . . . . . . . . . . . . . . . . . . . . . . 78 7.16. ACK Frame . . . . . . . . . . . . . . . . . . . . . . . . 78
7.16.1. ACK Block Section . . . . . . . . . . . . . . . . . 79 7.16.1. ACK Block Section . . . . . . . . . . . . . . . . . 79
7.16.2. ECN section . . . . . . . . . . . . . . . . . . . . 81 7.16.2. ECN section . . . . . . . . . . . . . . . . . . . . 81
7.16.3. Sending ACK Frames . . . . . . . . . . . . . . . . . 82 7.16.3. Sending ACK Frames . . . . . . . . . . . . . . . . . 82
7.16.4. ACK Frames and Packet Protection . . . . . . . . . . 83 7.16.4. ACK Frames and Packet Protection . . . . . . . . . . 83
7.17. PATH_CHALLENGE Frame . . . . . . . . . . . . . . . . . . 83 7.17. PATH_CHALLENGE Frame . . . . . . . . . . . . . . . . . . 83
7.18. PATH_RESPONSE Frame . . . . . . . . . . . . . . . . . . . 84 7.18. PATH_RESPONSE Frame . . . . . . . . . . . . . . . . . . . 84
7.19. NEW_TOKEN frame . . . . . . . . . . . . . . . . . . . . . 84 7.19. NEW_TOKEN frame . . . . . . . . . . . . . . . . . . . . . 84
7.20. STREAM Frames . . . . . . . . . . . . . . . . . . . . . . 84 7.20. STREAM Frames . . . . . . . . . . . . . . . . . . . . . . 84
7.21. CRYPTO Frame . . . . . . . . . . . . . . . . . . . . . . 86 7.21. CRYPTO Frame . . . . . . . . . . . . . . . . . . . . . . 86
skipping to change at page 27, line 40 skipping to change at page 27, line 40
| Frame 2 (*) ... | Frame 2 (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame N (*) ... | Frame N (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: QUIC Payload Figure 6: QUIC Payload
QUIC payloads MUST contain at least one frame, and MAY contain QUIC payloads MUST contain at least one frame, and MAY contain
multiple frames and multiple frame types. multiple frames and multiple frame types. Endpoints that receive a
packet containing no frames MAY terminate the connection with error
PROTOCOL_VIOLATION.
Frames MUST fit within a single QUIC packet and MUST NOT span a QUIC Frames MUST fit within a single QUIC packet and MUST NOT span a QUIC
packet boundary. Each frame begins with a Frame Type, indicating its packet boundary. Each frame begins with a Frame Type, indicating its
type, followed by additional type-dependent fields: type, followed by additional type-dependent fields:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame Type (i) ... | Frame Type (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 29, line 32 skipping to change at page 29, line 32
| 0x07 | PING | Section 7.9 | | 0x07 | PING | Section 7.9 |
| | | | | | | |
| 0x08 | BLOCKED | Section 7.10 | | 0x08 | BLOCKED | Section 7.10 |
| | | | | | | |
| 0x09 | STREAM_BLOCKED | Section 7.11 | | 0x09 | STREAM_BLOCKED | Section 7.11 |
| | | | | | | |
| 0x0a | STREAM_ID_BLOCKED | Section 7.12 | | 0x0a | STREAM_ID_BLOCKED | Section 7.12 |
| | | | | | | |
| 0x0b | NEW_CONNECTION_ID | Section 7.13 | | 0x0b | NEW_CONNECTION_ID | Section 7.13 |
| | | | | | | |
| 0x0c | STOP_SENDING | Section 7.15 | | 0x0c | STOP_SENDING | Section 7.14 |
| | | | | | | |
| 0x0d | RETIRE_CONNECTION_ID | Section 7.14 | | 0x0d | RETIRE_CONNECTION_ID | Section 7.15 |
| | | | | | | |
| 0x0e | PATH_CHALLENGE | Section 7.17 | | 0x0e | PATH_CHALLENGE | Section 7.17 |
| | | | | | | |
| 0x0f | PATH_RESPONSE | Section 7.18 | | 0x0f | PATH_RESPONSE | Section 7.18 |
| | | | | | | |
| 0x10 - 0x17 | STREAM | Section 7.20 | | 0x10 - 0x17 | STREAM | Section 7.20 |
| | | | | | | |
| 0x18 | CRYPTO | Section 7.21 | | 0x18 | CRYPTO | Section 7.21 |
| | | | | | | |
| 0x19 | NEW_TOKEN | Section 7.19 | | 0x19 | NEW_TOKEN | Section 7.19 |
skipping to change at page 32, line 8 skipping to change at page 32, line 8
NEW_CONNECTION_ID frames (Section 7.13), and the sequence number on NEW_CONNECTION_ID frames (Section 7.13), and the sequence number on
each newly-issued connection ID MUST increase by 1. The connection each newly-issued connection ID MUST increase by 1. The connection
ID randomly selected by the client in the Initial packet and any ID randomly selected by the client in the Initial packet and any
connection ID provided by a Reset packet are not assigned sequence connection ID provided by a Reset packet are not assigned sequence
numbers unless a server opts to retain them as its initial connection numbers unless a server opts to retain them as its initial connection
ID. ID.
When an endpoint issues a connection ID, it MUST accept packets that When an endpoint issues a connection ID, it MUST accept packets that
carry this connection ID for the duration of the connection or until carry this connection ID for the duration of the connection or until
its peer invalidates the connection ID via a RETIRE_CONNECTION_ID its peer invalidates the connection ID via a RETIRE_CONNECTION_ID
frame (Section 7.14). frame (Section 7.15).
An endpoint SHOULD ensure that its peer has a sufficient number of An endpoint SHOULD ensure that its peer has a sufficient number of
available and unused connection IDs. While each endpoint available and unused connection IDs. While each endpoint
independently chooses how many connection IDs to issue, endpoints independently chooses how many connection IDs to issue, endpoints
SHOULD provide and maintain at least eight connection IDs. The SHOULD provide and maintain at least eight connection IDs. The
endpoint can do this by always supplying a new connection ID when a endpoint can do this by always supplying a new connection ID when a
connection ID is retired by its peer or when the endpoint receives a connection ID is retired by its peer or when the endpoint receives a
packet with a previously unused connection ID. Endpoints that packet with a previously unused connection ID. Endpoints that
initiate migration and require non-zero-length connection IDs SHOULD initiate migration and require non-zero-length connection IDs SHOULD
provide their peers with new connection IDs before migration, or risk provide their peers with new connection IDs before migration, or risk
skipping to change at page 62, line 5 skipping to change at page 62, line 5
is validated (see Section 6.10). A server in the closing state MAY is validated (see Section 6.10). A server in the closing state MAY
instead choose to discard packets received from a new source address. instead choose to discard packets received from a new source address.
6.13.2. Idle Timeout 6.13.2. Idle Timeout
If the idle timeout is enabled, a connection that remains idle for If the idle timeout is enabled, a connection that remains idle for
longer than the advertised idle timeout (see Section 6.6.1) is longer than the advertised idle timeout (see Section 6.6.1) is
closed. A connection enters the draining state when the idle timeout closed. A connection enters the draining state when the idle timeout
expires. expires.
Each endpoint advertises their own idle timeout to their peer. The Each endpoint advertises its own idle timeout to its peer. The idle
idle timeout starts from the last packet received. In order to timeout starts from the last packet received. In order to ensure
ensure that initiating new activity postpones an idle timeout, an that initiating new activity postpones an idle timeout, an endpoint
endpoint restarts this timer when sending a packet. An endpoint does restarts this timer when sending a packet. An endpoint does not
not postpone the idle timeout if another packet has been sent postpone the idle timeout if another packet has been sent containing
containing frames other than ACK or PADDING, and that other packet frames other than ACK or PADDING, and that other packet has not been
has not been acknowledged or declared lost. Packets that contain acknowledged or declared lost. Packets that contain only ACK or
only ACK or PADDING frames are not acknowledged until an endpoint has PADDING frames are not acknowledged until an endpoint has other
other frames to send, so they could prevent the timeout from being frames to send, so they could prevent the timeout from being
refreshed. refreshed.
The value for an idle timeout can be asymmetric. The value The value for an idle timeout can be asymmetric. The value
advertised by an endpoint is only used to determine whether the advertised by an endpoint is only used to determine whether the
connection is live at that endpoint. An endpoint that sends packets connection is live at that endpoint. An endpoint that sends packets
near the end of the idle timeout period of a peer risks having those near the end of the idle timeout period of a peer risks having those
packets discarded if its peer enters the draining state before the packets discarded if its peer enters the draining state before the
packets arrive. If a peer could timeout within an RTO (see packets arrive. If a peer could timeout within an RTO (see
Section 4.3.3 of [QUIC-RECOVERY]), it is advisable to test for Section 4.3.3 of [QUIC-RECOVERY]), it is advisable to test for
liveness before sending any data that cannot be retried safely. liveness before sending any data that cannot be retried safely.
skipping to change at page 63, line 35 skipping to change at page 63, line 35
a closing frame if it has sufficient state to do so. a closing frame if it has sufficient state to do so.
To support this process, a token is sent by endpoints. The token is To support this process, a token is sent by endpoints. The token is
carried in the NEW_CONNECTION_ID frame sent by either peer, and carried in the NEW_CONNECTION_ID frame sent by either peer, and
servers can specify the stateless_reset_token transport parameter servers can specify the stateless_reset_token transport parameter
during the handshake (clients cannot because their transport during the handshake (clients cannot because their transport
parameters don't have confidentiality protection). This value is parameters don't have confidentiality protection). This value is
protected by encryption, so only client and server know this value. protected by encryption, so only client and server know this value.
Tokens sent via NEW_CONNECTION_ID frames are invalidated when their Tokens sent via NEW_CONNECTION_ID frames are invalidated when their
associated connection ID is retired via a RETIRE_CONNECTION_ID frame associated connection ID is retired via a RETIRE_CONNECTION_ID frame
(Section 7.14). (Section 7.15).
An endpoint that receives packets that it cannot process sends a An endpoint that receives packets that it cannot process sends a
packet in the following layout: packet in the following layout:
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
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|0|K|1|1|0|0|0|0| |0|K|1|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Random Octets (160..) ... | Random Octets (160..) ...
skipping to change at page 77, line 7 skipping to change at page 77, line 7
same NEW_CONNECTION_ID frame to be received multiple times. Receipt same NEW_CONNECTION_ID frame to be received multiple times. Receipt
of the same frame multiple times MUST NOT be treated as a connection of the same frame multiple times MUST NOT be treated as a connection
error. A receiver can use the sequence number supplied in the error. A receiver can use the sequence number supplied in the
NEW_CONNECTION_ID frame to identify new connection IDs from old ones. NEW_CONNECTION_ID frame to identify new connection IDs from old ones.
If an endpoint receives a NEW_CONNECTION_ID frame that repeats a If an endpoint receives a NEW_CONNECTION_ID frame that repeats a
previously issued connection ID with a different Stateless Reset previously issued connection ID with a different Stateless Reset
Token or a different sequence number, the endpoint MAY treat that Token or a different sequence number, the endpoint MAY treat that
receipt as a connection error of type PROTOCOL_VIOLATION. receipt as a connection error of type PROTOCOL_VIOLATION.
7.14. RETIRE_CONNECTION_ID Frame 7.14. STOP_SENDING Frame
An endpoint sends a RETIRE_CONNECTION_ID frame (type=0x1b) to An endpoint may use a STOP_SENDING frame (type=0x0c) to communicate
that incoming data is being discarded on receipt at application
request. This signals a peer to abruptly terminate transmission on a
stream.
Receipt of a STOP_SENDING frame is only valid for a send stream that
exists and is not in the "Ready" state (see Section 9.2.1).
Receiving a STOP_SENDING frame for a send stream that is "Ready" or
non-existent MUST be treated as a connection error of type
PROTOCOL_VIOLATION. An endpoint that receives a STOP_SENDING frame
for a receive-only stream MUST terminate the connection with error
PROTOCOL_VIOLATION.
The STOP_SENDING frame is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream ID (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Application Error Code (16) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields are:
Stream ID: A variable-length integer carrying the Stream ID of the
stream being ignored.
Application Error Code: A 16-bit, application-specified reason the
sender is ignoring the stream (see Section 11.4).
7.15. RETIRE_CONNECTION_ID Frame
An endpoint sends a RETIRE_CONNECTION_ID frame (type=0x0d) to
indicate that it will no longer use a connection ID that was issued indicate that it will no longer use a connection ID that was issued
by its peer. This may include the connection ID provided during the by its peer. This may include the connection ID provided during the
handshake. Sending a RETIRE_CONNECTION_ID frame also serves as a handshake. Sending a RETIRE_CONNECTION_ID frame also serves as a
request to the peer to send additional connection IDs for future use request to the peer to send additional connection IDs for future use
(see Section 6.1). New connection IDs can be delivered to a peer (see Section 6.1). New connection IDs can be delivered to a peer
using the NEW_CONNECTION_ID frame (Section 7.13). using the NEW_CONNECTION_ID frame (Section 7.13).
Retiring a connection ID invalidates the stateless reset token Retiring a connection ID invalidates the stateless reset token
associated with that connection ID. associated with that connection ID.
skipping to change at page 77, line 42 skipping to change at page 78, line 27
Receipt of a RETIRE_CONNECTION_ID frame containing a sequence number Receipt of a RETIRE_CONNECTION_ID frame containing a sequence number
greater than any previously sent to the peer MAY be treated as a greater than any previously sent to the peer MAY be treated as a
connection error of type PROTOCOL_VIOLATION. connection error of type PROTOCOL_VIOLATION.
An endpoint cannot send this frame if it was provided with a zero- An endpoint cannot send this frame if it was provided with a zero-
length connection ID by its peer. An endpoint that provides a zero- length connection ID by its peer. An endpoint that provides a zero-
length connection ID MUST treat receipt of a RETIRE_CONNECTION_ID length connection ID MUST treat receipt of a RETIRE_CONNECTION_ID
frame as a connection error of type PROTOCOL_VIOLATION. frame as a connection error of type PROTOCOL_VIOLATION.
7.15. STOP_SENDING Frame
An endpoint may use a STOP_SENDING frame (type=0x0c) to communicate
that incoming data is being discarded on receipt at application
request. This signals a peer to abruptly terminate transmission on a
stream.
Receipt of a STOP_SENDING frame is only valid for a send stream that
exists and is not in the "Ready" state (see Section 9.2.1).
Receiving a STOP_SENDING frame for a send stream that is "Ready" or
non-existent MUST be treated as a connection error of type
PROTOCOL_VIOLATION. An endpoint that receives a STOP_SENDING frame
for a receive-only stream MUST terminate the connection with error
PROTOCOL_VIOLATION.
The STOP_SENDING frame is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream ID (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Application Error Code (16) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields are:
Stream ID: A variable-length integer carrying the Stream ID of the
stream being ignored.
Application Error Code: A 16-bit, application-specified reason the
sender is ignoring the stream (see Section 11.4).
7.16. ACK Frame 7.16. ACK Frame
Receivers send ACK frames (types 0x1a and 0x1b) to inform senders of Receivers send ACK frames (types 0x1a and 0x1b) to inform senders of
packets they have received and processed. The ACK frame contains one packets they have received and processed. The ACK frame contains one
or more ACK Blocks. ACK Blocks are ranges of acknowledged packets. or more ACK Blocks. ACK Blocks are ranges of acknowledged packets.
If the frame type is 0x1b, ACK frames also contain the sum of ECN If the frame type is 0x1b, ACK frames also contain the sum of ECN
marks received on the connection up until this point. marks received on the connection up until this point.
QUIC acknowledgements are irrevocable. Once acknowledged, a packet QUIC acknowledgements are irrevocable. Once acknowledged, a packet
remains acknowledged, even if it does not appear in a future ACK remains acknowledged, even if it does not appear in a future ACK
skipping to change at page 99, line 35 skipping to change at page 99, line 35
(Section 7.3). (Section 7.3).
A sender MUST NOT send any of these frames from a terminal state A sender MUST NOT send any of these frames from a terminal state
("Data Recvd" or "Reset Recvd"). A sender MUST NOT send STREAM or ("Data Recvd" or "Reset Recvd"). A sender MUST NOT send STREAM or
STREAM_BLOCKED after sending a RST_STREAM; that is, in the "Reset STREAM_BLOCKED after sending a RST_STREAM; that is, in the "Reset
Sent" state in addition to the terminal states. A receiver could Sent" state in addition to the terminal states. A receiver could
receive any of these frames in any state, but only due to the receive any of these frames in any state, but only due to the
possibility of delayed delivery of packets carrying them. possibility of delayed delivery of packets carrying them.
The receiver of a stream sends MAX_STREAM_DATA (Section 7.7) and The receiver of a stream sends MAX_STREAM_DATA (Section 7.7) and
STOP_SENDING frames (Section 7.15). STOP_SENDING frames (Section 7.14).
The receiver only sends MAX_STREAM_DATA in the "Recv" state. A The receiver only sends MAX_STREAM_DATA in the "Recv" state. A
receiver can send STOP_SENDING in any state where it has not received receiver can send STOP_SENDING in any state where it has not received
a RST_STREAM frame; that is states other than "Reset Recvd" or "Reset a RST_STREAM frame; that is states other than "Reset Recvd" or "Reset
Read". However there is little value in sending a STOP_SENDING frame Read". However there is little value in sending a STOP_SENDING frame
after all stream data has been received in the "Data Recvd" state. A after all stream data has been received in the "Data Recvd" state. A
sender could receive these frames in any state as a result of delayed sender could receive these frames in any state as a result of delayed
delivery of packets. delivery of packets.
9.2.4. Bidirectional Stream States 9.2.4. Bidirectional Stream States
skipping to change at page 120, line 24 skipping to change at page 120, line 24
DOI 10.17487/RFC1191, November 1990, DOI 10.17487/RFC1191, November 1990,
<https://www.rfc-editor.org/info/rfc1191>. <https://www.rfc-editor.org/info/rfc1191>.
[PMTUDv6] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., [PMTUDv6] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
"Path MTU Discovery for IP version 6", STD 87, RFC 8201, "Path MTU Discovery for IP version 6", STD 87, RFC 8201,
DOI 10.17487/RFC8201, July 2017, DOI 10.17487/RFC8201, July 2017,
<https://www.rfc-editor.org/info/rfc8201>. <https://www.rfc-editor.org/info/rfc8201>.
[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-15 (work and Congestion Control", draft-ietf-quic-recovery-latest
in progress). (work in progress).
[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- Layer Security (TLS) to Secure QUIC", draft-ietf-quic-tls-
tls-15 (work in progress). latest (work in progress).
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001, RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/info/rfc3168>. <https://www.rfc-editor.org/info/rfc3168>.
skipping to change at page 121, line 36 skipping to change at page 121, line 36
Roskind, J., "QUIC: Multiplexed Transport Over UDP", Roskind, J., "QUIC: Multiplexed Transport Over UDP",
December 2013, <https://goo.gl/dMVtFi>. December 2013, <https://goo.gl/dMVtFi>.
[HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext [HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540, Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015, DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/info/rfc7540>. <https://www.rfc-editor.org/info/rfc7540>.
[QUIC-INVARIANTS] [QUIC-INVARIANTS]
Thomson, M., "Version-Independent Properties of QUIC", Thomson, M., "Version-Independent Properties of QUIC",
draft-ietf-quic-invariants-03 (work in progress). draft-ietf-quic-invariants-latest (work in progress).
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018, Selective Acknowledgment Options", RFC 2018,
DOI 10.17487/RFC2018, October 1996, DOI 10.17487/RFC2018, October 1996,
<https://www.rfc-editor.org/info/rfc2018>. <https://www.rfc-editor.org/info/rfc2018>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997, DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>. <https://www.rfc-editor.org/info/rfc2104>.
skipping to change at page 123, line 46 skipping to change at page 123, line 46
B.1. Since draft-ietf-quic-transport-14 B.1. Since draft-ietf-quic-transport-14
o Merge ACK and ACK_ECN (#1778, #1801) o Merge ACK and ACK_ECN (#1778, #1801)
o Explicitly communicate max_ack_delay (#981, #1781) o Explicitly communicate max_ack_delay (#981, #1781)
o Validate original connection ID after Retry packets (#1710, #1486, o Validate original connection ID after Retry packets (#1710, #1486,
#1793) #1793)
o Idle timeout is optional and has no specified maximum (#1520, o Idle timeout is optional and has no specified maximum (#1765)
#1521)
o Update connection ID handling; add RETIRE_CONNECTION_ID type o Update connection ID handling; add RETIRE_CONNECTION_ID type
(#1464, #1468, #1483, #1484, #1486, #1495, #1729, #1742, #1799, (#1464, #1468, #1483, #1484, #1486, #1495, #1729, #1742, #1799,
#1821) #1821)
o Include a Token in all Initial packets (#1649, #1794) o Include a Token in all Initial packets (#1649, #1794)
o Prevent handshake deadlock (#1764, #1824) o Prevent handshake deadlock (#1764, #1824)
B.2. Since draft-ietf-quic-transport-13 B.2. Since draft-ietf-quic-transport-13
o Streams open when higher-numbered streams of the same type open o Streams open when higher-numbered streams of the same type open
(#1342, #1549) (#1342, #1549)
o Split initial stream flow control limit into 3 transport o Split initial stream flow control limit into 3 transport
parameters (#1016, #1542) parameters (#1016, #1542)
 End of changes. 19 change blocks. 
64 lines changed or deleted 64 lines changed or added

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