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/