draft-ietf-quic-recovery-23.txt		draft-ietf-quic-recovery-latest.txt
	QUIC Working Group J. Iyengar, Ed.		QUIC Working Group J. Iyengar, Ed.
	Internet-Draft Fastly		Internet-Draft Fastly
	Intended status: Standards Track I. Swett, Ed.		Intended status: Standards Track I. Swett, Ed.
	Expires: March 15, 2020 Google		Expires: April 20, 2020 Google
	September 12, 2019		October 18, 2019
	QUIC Loss Detection and Congestion Control		QUIC Loss Detection and Congestion Control
	draft-ietf-quic-recovery-23		draft-ietf-quic-recovery-latest
	Abstract		Abstract
	This document describes loss detection and congestion control		This document describes loss detection and congestion control
	mechanisms for QUIC.		mechanisms for QUIC.
	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
	skipping to change at page 1, line 42 ¶		skipping to change at page 1, line 42 ¶
	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 March 15, 2020.		This Internet-Draft will expire on April 20, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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 2, line 44 ¶		skipping to change at page 2, line 44 ¶
	5.1.2. Time Threshold . . . . . . . . . . . . . . . . . . . 10		5.1.2. Time Threshold . . . . . . . . . . . . . . . . . . . 10
	5.2. Probe Timeout . . . . . . . . . . . . . . . . . . . . . . 11		5.2. Probe Timeout . . . . . . . . . . . . . . . . . . . . . . 11
	5.2.1. Computing PTO . . . . . . . . . . . . . . . . . . . . 11		5.2.1. Computing PTO . . . . . . . . . . . . . . . . . . . . 11
	5.3. Handshakes and New Paths . . . . . . . . . . . . . . . . 12		5.3. Handshakes and New Paths . . . . . . . . . . . . . . . . 12
	5.3.1. Sending Probe Packets . . . . . . . . . . . . . . . . 13		5.3.1. Sending Probe Packets . . . . . . . . . . . . . . . . 13
	5.3.2. Loss Detection . . . . . . . . . . . . . . . . . . . 14		5.3.2. Loss Detection . . . . . . . . . . . . . . . . . . . 14
	5.4. Retry and Version Negotiation . . . . . . . . . . . . . . 14		5.4. Retry and Version Negotiation . . . . . . . . . . . . . . 14
	5.5. Discarding Keys and Packet State . . . . . . . . . . . . 14		5.5. Discarding Keys and Packet State . . . . . . . . . . . . 14
	5.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . 15		5.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . 15
	6. Congestion Control . . . . . . . . . . . . . . . . . . . . . 15		6. Congestion Control . . . . . . . . . . . . . . . . . . . . . 15
	6.1. Explicit Congestion Notification . . . . . . . . . . . . 15		6.1. Explicit Congestion Notification . . . . . . . . . . . . 16
	6.2. Slow Start . . . . . . . . . . . . . . . . . . . . . . . 16		6.2. Slow Start . . . . . . . . . . . . . . . . . . . . . . . 16
	6.3. Congestion Avoidance . . . . . . . . . . . . . . . . . . 16		6.3. Congestion Avoidance . . . . . . . . . . . . . . . . . . 16
	6.4. Recovery Period . . . . . . . . . . . . . . . . . . . . . 16		6.4. Recovery Period . . . . . . . . . . . . . . . . . . . . . 16
	6.5. Ignoring Loss of Undecryptable Packets . . . . . . . . . 16		6.5. Ignoring Loss of Undecryptable Packets . . . . . . . . . 16
	6.6. Probe Timeout . . . . . . . . . . . . . . . . . . . . . . 17		6.6. Probe Timeout . . . . . . . . . . . . . . . . . . . . . . 17
	6.7. Persistent Congestion . . . . . . . . . . . . . . . . . . 17		6.7. Persistent Congestion . . . . . . . . . . . . . . . . . . 17
	6.8. Pacing . . . . . . . . . . . . . . . . . . . . . . . . . 18		6.8. Pacing . . . . . . . . . . . . . . . . . . . . . . . . . 18
	6.9. Under-utilizing the Congestion Window . . . . . . . . . . 18		6.9. Under-utilizing the Congestion Window . . . . . . . . . . 18
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 19		7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
	7.1. Congestion Signals . . . . . . . . . . . . . . . . . . . 19		7.1. Congestion Signals . . . . . . . . . . . . . . . . . . . 19
	7.2. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 19		7.2. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 19
	7.3. Misreporting ECN Markings . . . . . . . . . . . . . . . . 19		7.3. Misreporting ECN Markings . . . . . . . . . . . . . . . . 19
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
	9.1. Normative References . . . . . . . . . . . . . . . . . . 20		9.1. Normative References . . . . . . . . . . . . . . . . . . 20
	9.2. Informative References . . . . . . . . . . . . . . . . . 20		9.2. Informative References . . . . . . . . . . . . . . . . . 20
	9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 22		9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 22
	Appendix A. Loss Recovery Pseudocode . . . . . . . . . . . . . . 22		Appendix A. Loss Recovery Pseudocode . . . . . . . . . . . . . . 22
	A.1. Tracking Sent Packets . . . . . . . . . . . . . . . . . . 22		A.1. Tracking Sent Packets . . . . . . . . . . . . . . . . . . 22
	A.1.1. Sent Packet Fields . . . . . . . . . . . . . . . . . 22		A.1.1. Sent Packet Fields . . . . . . . . . . . . . . . . . 23
	A.2. Constants of interest . . . . . . . . . . . . . . . . . . 23		A.2. Constants of interest . . . . . . . . . . . . . . . . . . 23
	A.3. Variables of interest . . . . . . . . . . . . . . . . . . 23		A.3. Variables of interest . . . . . . . . . . . . . . . . . . 24
	A.4. Initialization . . . . . . . . . . . . . . . . . . . . . 24		A.4. Initialization . . . . . . . . . . . . . . . . . . . . . 24
	A.5. On Sending a Packet . . . . . . . . . . . . . . . . . . . 25		A.5. On Sending a Packet . . . . . . . . . . . . . . . . . . . 25
	A.6. On Receiving an Acknowledgment . . . . . . . . . . . . . 25		A.6. On Receiving an Acknowledgment . . . . . . . . . . . . . 25
	A.7. On Packet Acknowledgment . . . . . . . . . . . . . . . . 26		A.7. On Packet Acknowledgment . . . . . . . . . . . . . . . . 27
	A.8. Setting the Loss Detection Timer . . . . . . . . . . . . 27		A.8. Setting the Loss Detection Timer . . . . . . . . . . . . 27
	A.9. On Timeout . . . . . . . . . . . . . . . . . . . . . . . 29		A.9. On Timeout . . . . . . . . . . . . . . . . . . . . . . . 29
	A.10. Detecting Lost Packets . . . . . . . . . . . . . . . . . 29		A.10. Detecting Lost Packets . . . . . . . . . . . . . . . . . 29
	Appendix B. Congestion Control Pseudocode . . . . . . . . . . . 30		Appendix B. Congestion Control Pseudocode . . . . . . . . . . . 30
	B.1. Constants of interest . . . . . . . . . . . . . . . . . . 30		B.1. Constants of interest . . . . . . . . . . . . . . . . . . 30
	B.2. Variables of interest . . . . . . . . . . . . . . . . . . 31		B.2. Variables of interest . . . . . . . . . . . . . . . . . . 31
	B.3. Initialization . . . . . . . . . . . . . . . . . . . . . 32		B.3. Initialization . . . . . . . . . . . . . . . . . . . . . 32
	B.4. On Packet Sent . . . . . . . . . . . . . . . . . . . . . 32		B.4. On Packet Sent . . . . . . . . . . . . . . . . . . . . . 32
	B.5. On Packet Acknowledgement . . . . . . . . . . . . . . . . 32		B.5. On Packet Acknowledgement . . . . . . . . . . . . . . . . 32
	B.6. On New Congestion Event . . . . . . . . . . . . . . . . . 33		B.6. On New Congestion Event . . . . . . . . . . . . . . . . . 33
	skipping to change at page 10, line 51 ¶		skipping to change at page 10, line 51 ¶
	reordering resilience.		reordering resilience.
	5.1.2. Time Threshold		5.1.2. Time Threshold
	Once a later packet packet within the same packet number space has		Once a later packet packet within the same packet number space has
	been acknowledged, an endpoint SHOULD declare an earlier packet lost		been acknowledged, an endpoint SHOULD declare an earlier packet lost
	if it was sent a threshold amount of time in the past. To avoid		if it was sent a threshold amount of time in the past. To avoid
	declaring packets as lost too early, this time threshold MUST be set		declaring packets as lost too early, this time threshold MUST be set
	to at least kGranularity. The time threshold is:		to at least kGranularity. The time threshold is:
	kTimeThreshold * max(SRTT, latest_RTT, kGranularity)		kTimeThreshold * max(smoothed_rtt, latest_rtt, kGranularity)
	If packets sent prior to the largest acknowledged packet cannot yet		If packets sent prior to the largest acknowledged packet cannot yet
	be declared lost, then a timer SHOULD be set for the remaining time.		be declared lost, then a timer SHOULD be set for the remaining time.
	Using max(SRTT, latest_RTT) protects from the two following cases:		Using max(smoothed_rtt, latest_rtt) protects from the two following
			cases:
	o the latest RTT sample is lower than the SRTT, perhaps due to		o the latest RTT sample is lower than the smoothed RTT, perhaps due
	reordering where the acknowledgement encountered a shorter path;		to reordering where the acknowledgement encountered a shorter
			path;
	o the latest RTT sample is higher than the SRTT, perhaps due to a		o the latest RTT sample is higher than the smoothed RTT, perhaps due
	sustained increase in the actual RTT, but the smoothed SRTT has		to a sustained increase in the actual RTT, but the smoothed RTT
	not yet caught up.		has not yet caught up.
	The RECOMMENDED time threshold (kTimeThreshold), expressed as a		The RECOMMENDED time threshold (kTimeThreshold), expressed as a
	round-trip time multiplier, is 9/8.		round-trip time multiplier, is 9/8.
	Implementations MAY experiment with absolute thresholds, thresholds		Implementations MAY experiment with absolute thresholds, thresholds
	from previous connections, adaptive thresholds, or including RTT		from previous connections, adaptive thresholds, or including RTT
	variance. Smaller thresholds reduce reordering resilience and		variance. Smaller thresholds reduce reordering resilience and
	increase spurious retransmissions, and larger thresholds increase		increase spurious retransmissions, and larger thresholds increase
	loss detection delay.		loss detection delay.
	skipping to change at page 14, line 4 ¶		skipping to change at page 14, line 7 ¶
	connection recovery latency increases exponentially as packets		connection recovery latency increases exponentially as packets
	continue to be dropped in the network. Sending two packets on PTO		continue to be dropped in the network. Sending two packets on PTO
	expiration increases resilience to packet drops, thus reducing the		expiration increases resilience to packet drops, thus reducing the
	probability of consecutive PTO events.		probability of consecutive PTO events.
	Probe packets sent on a PTO MUST be ack-eliciting. A probe packet		Probe packets sent on a PTO MUST be ack-eliciting. A probe packet
	SHOULD carry new data when possible. A probe packet MAY carry		SHOULD carry new data when possible. A probe packet MAY carry
	retransmitted unacknowledged data when new data is unavailable, when		retransmitted unacknowledged data when new data is unavailable, when
	flow control does not permit new data to be sent, or to		flow control does not permit new data to be sent, or to
	opportunistically reduce loss recovery delay. Implementations MAY		opportunistically reduce loss recovery delay. Implementations MAY
	use alternate strategies for determining the content of probe		use alternative strategies for determining the content of probe
	packets, including sending new or retransmitted data based on the		packets, including sending new or retransmitted data based on the
	application's priorities.		application's priorities.
	When the PTO timer expires multiple times and new data cannot be		When the PTO timer expires multiple times and new data cannot be
	sent, implementations must choose between sending the same payload		sent, implementations must choose between sending the same payload
	every time or sending different payloads. Sending the same payload		every time or sending different payloads. Sending the same payload
	may be simpler and ensures the highest priority frames arrive first.		may be simpler and ensures the highest priority frames arrive first.
	Sending different payloads each time reduces the chances of spurious		Sending different payloads each time reduces the chances of spurious
	retransmission.		retransmission.
	skipping to change at page 17, line 33 ¶		skipping to change at page 17, line 35 ¶
	are substantially delayed. This duration is computed as follows:		are substantially delayed. This duration is computed as follows:
	(smoothed_rtt + 4 * rttvar + max_ack_delay) *		(smoothed_rtt + 4 * rttvar + max_ack_delay) *
	kPersistentCongestionThreshold		kPersistentCongestionThreshold
	For example, assume:		For example, assume:
	smoothed_rtt = 1 rttvar = 0 max_ack_delay = 0		smoothed_rtt = 1 rttvar = 0 max_ack_delay = 0
	kPersistentCongestionThreshold = 3		kPersistentCongestionThreshold = 3
	If an eck-eliciting packet is sent at time = 0, the following		If an ack-eliciting packet is sent at time = 0, the following
	scenario would illustrate persistent congestion:		scenario would illustrate persistent congestion:
	+-----+------------------------+		+-----+------------------------+
	| t=0 | Send Pkt #1 (App Data) |		| t=0 | Send Pkt #1 (App Data) |
	+-----+------------------------+		+-----+------------------------+
	| t=1 | Send Pkt #2 (PTO 1) |		| t=1 | Send Pkt #2 (PTO 1) |
	| | |		| | |
	| t=3 | Send Pkt #3 (PTO 2) |		| t=3 | Send Pkt #3 (PTO 2) |
	| | |		| | |
	| t=7 | Send Pkt #4 (PTO 3) |		| t=7 | Send Pkt #4 (PTO 3) |
	skipping to change at page 18, line 20 ¶		skipping to change at page 18, line 23 ¶
	(kMinimumWindow). This response of collapsing the congestion window		(kMinimumWindow). This response of collapsing the congestion window
	on persistent congestion is functionally similar to a sender's		on persistent congestion is functionally similar to a sender's
	response on a Retransmission Timeout (RTO) in TCP [RFC5681] after		response on a Retransmission Timeout (RTO) in TCP [RFC5681] after
	Tail Loss Probes (TLP) [TLP].		Tail Loss Probes (TLP) [TLP].
	6.8. Pacing		6.8. Pacing
	This document does not specify a pacer, but it is RECOMMENDED that a		This document does not specify a pacer, but it is RECOMMENDED that a
	sender pace sending of all in-flight packets based on input from the		sender pace sending of all in-flight packets based on input from the
	congestion controller. For example, a pacer might distribute the		congestion controller. For example, a pacer might distribute the
	congestion window over the SRTT when used with a window-based		congestion window over the smoothed RTT when used with a window-based
	controller, and a pacer might use the rate estimate of a rate-based		controller, and a pacer might use the rate estimate of a rate-based
	controller.		controller.
	An implementation should take care to architect its congestion		An implementation should take care to architect its congestion
	controller to work well with a pacer. For instance, a pacer might		controller to work well with a pacer. For instance, a pacer might
	wrap the congestion controller and control the availability of the		wrap the congestion controller and control the availability of the
	congestion window, or a pacer might pace out packets handed to it by		congestion window, or a pacer might pace out packets handed to it by
	the congestion controller. Timely delivery of ACK frames is		the congestion controller. Timely delivery of ACK frames is
	important for efficient loss recovery. Packets containing only ACK		important for efficient loss recovery. Packets containing only ACK
	frames should therefore not be paced, to avoid delaying their		frames should therefore not be paced, to avoid delaying their
	delivery to the peer.		delivery to the peer.
			Sending multiple packets into the network without any delay between
			them creates a packet burst that might cause short-term congestion
			and losses. Implementations MUST either use pacing or limit such
			bursts to minimum of 10 * kMaxDatagramSize and max(2*
			kMaxDatagramSize, 14720)), the same as the recommended initial
			congestion window.
	As an example of a well-known and publicly available implementation		As an example of a well-known and publicly available implementation
	of a flow pacer, implementers are referred to the Fair Queue packet		of a flow pacer, implementers are referred to the Fair Queue packet
	scheduler (fq qdisc) in Linux (3.11 onwards).		scheduler (fq qdisc) in Linux (3.11 onwards).
	6.9. Under-utilizing the Congestion Window		6.9. Under-utilizing the Congestion Window
	A congestion window that is under-utilized SHOULD NOT be increased in		When bytes in flight is smaller than the congestion window and
	either slow start or congestion avoidance. This can happen due to		sending is not pacing limited, the congestion window is under-
	insufficient application data or flow control credit.		utilized. When this occurs, the congestion window SHOULD NOT be
			increased in either slow start or congestion avoidance. This can
			happen due to insufficient application data or flow control credit.
	A sender MAY use the pipeACK method described in section 4.3 of		A sender MAY use the pipeACK method described in section 4.3 of
	[RFC7661] to determine if the congestion window is sufficiently		[RFC7661] to determine if the congestion window is sufficiently
	utilized.		utilized.
	A sender that paces packets (see Section 6.8) might delay sending		A sender that paces packets (see Section 6.8) might delay sending
	packets and not fully utilize the congestion window due to this		packets and not fully utilize the congestion window due to this
	delay. A sender should not consider itself application limited if it		delay. A sender should not consider itself application limited if it
	would have fully utilized the congestion window without pacing delay.		would have fully utilized the congestion window without pacing delay.
	Bursting more than an initial window's worth of data into the network		A sender MAY implement alternative mechanisms to update its
	might cause short-term congestion and losses. Implemementations		congestion window after periods of under-utilization, such as those
	SHOULD either use pacing or reduce their congestion window to limit		proposed for TCP in [RFC7661].
	such bursts.
	A sender MAY implement alternate mechanisms to update its congestion
	window after periods of under-utilization, such as those proposed for
	TCP in [RFC7661].
	7. Security Considerations		7. Security Considerations
	7.1. Congestion Signals		7.1. Congestion Signals
	Congestion control fundamentally involves the consumption of signals		Congestion control fundamentally involves the consumption of signals
	- both loss and ECN codepoints - from unauthenticated entities. On-		- both loss and ECN codepoints - from unauthenticated entities. On-
	path attackers can spoof or alter these signals. An attacker can		path attackers can spoof or alter these signals. An attacker can
	cause endpoints to reduce their sending rate by dropping packets, or		cause endpoints to reduce their sending rate by dropping packets, or
	alter send rate by changing ECN codepoints.		alter send rate by changing ECN codepoints.
	skipping to change at page 20, line 17 ¶		skipping to change at page 20, line 23 ¶
	8. IANA Considerations		8. IANA Considerations
	This document has no IANA actions. Yet.		This document has no IANA actions. Yet.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[QUIC-TLS]		[QUIC-TLS]
	Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure		Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure
	QUIC", draft-ietf-quic-tls-23 (work in progress).		QUIC", draft-ietf-quic-tls-latest (work in progress).
	[QUIC-TRANSPORT]		[QUIC-TRANSPORT]
	Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based		Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
	Multiplexed and Secure Transport", draft-ietf-quic-		Multiplexed and Secure Transport", draft-ietf-quic-
	transport-23 (work in progress).		transport-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>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
End of changes. 19 change blocks.
	31 lines changed or deleted		37 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/