draft-ietf-quic-recovery-34.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: July 19, 2021 Google		Expires: October 24, 2021 Google
	January 15, 2021		April 22, 2021
	QUIC Loss Detection and Congestion Control		QUIC Loss Detection and Congestion Control
	draft-ietf-quic-recovery-14		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 [1]), which is archived at		mailing list (quic@ietf.org [1]), 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 July 19, 2021.		This Internet-Draft will expire on October 24, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 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 41 ¶		skipping to change at page 2, line 41 ¶
	5.2. Estimating min_rtt . . . . . . . . . . . . . . . . . . . 9		5.2. Estimating min_rtt . . . . . . . . . . . . . . . . . . . 9
	5.3. Estimating smoothed_rtt and rttvar . . . . . . . . . . . 10		5.3. Estimating smoothed_rtt and rttvar . . . . . . . . . . . 10
	6. Loss Detection . . . . . . . . . . . . . . . . . . . . . . . 12		6. Loss Detection . . . . . . . . . . . . . . . . . . . . . . . 12
	6.1. Acknowledgment-Based Detection . . . . . . . . . . . . . 12		6.1. Acknowledgment-Based Detection . . . . . . . . . . . . . 12
	6.1.1. Packet Threshold . . . . . . . . . . . . . . . . . . 13		6.1.1. Packet Threshold . . . . . . . . . . . . . . . . . . 13
	6.1.2. Time Threshold . . . . . . . . . . . . . . . . . . . 13		6.1.2. Time Threshold . . . . . . . . . . . . . . . . . . . 13
	6.2. Probe Timeout . . . . . . . . . . . . . . . . . . . . . . 14		6.2. Probe Timeout . . . . . . . . . . . . . . . . . . . . . . 14
	6.2.1. Computing PTO . . . . . . . . . . . . . . . . . . . . 14		6.2.1. Computing PTO . . . . . . . . . . . . . . . . . . . . 14
	6.2.2. Handshakes and New Paths . . . . . . . . . . . . . . 16		6.2.2. Handshakes and New Paths . . . . . . . . . . . . . . 16
	6.2.3. Speeding Up Handshake Completion . . . . . . . . . . 17		6.2.3. Speeding Up Handshake Completion . . . . . . . . . . 17
	6.2.4. Sending Probe Packets . . . . . . . . . . . . . . . . 17		6.2.4. Sending Probe Packets . . . . . . . . . . . . . . . . 18
	6.3. Handling Retry Packets . . . . . . . . . . . . . . . . . 18		6.3. Handling Retry Packets . . . . . . . . . . . . . . . . . 19
	6.4. Discarding Keys and Packet State . . . . . . . . . . . . 19		6.4. Discarding Keys and Packet State . . . . . . . . . . . . 19
	7. Congestion Control . . . . . . . . . . . . . . . . . . . . . 19		7. Congestion Control . . . . . . . . . . . . . . . . . . . . . 20
	7.1. Explicit Congestion Notification . . . . . . . . . . . . 20		7.1. Explicit Congestion Notification . . . . . . . . . . . . 20
	7.2. Initial and Minimum Congestion Window . . . . . . . . . . 20		7.2. Initial and Minimum Congestion Window . . . . . . . . . . 21
	7.3. Congestion Control States . . . . . . . . . . . . . . . . 21		7.3. Congestion Control States . . . . . . . . . . . . . . . . 21
	7.3.1. Slow Start . . . . . . . . . . . . . . . . . . . . . 21		7.3.1. Slow Start . . . . . . . . . . . . . . . . . . . . . 22
	7.3.2. Recovery . . . . . . . . . . . . . . . . . . . . . . 22		7.3.2. Recovery . . . . . . . . . . . . . . . . . . . . . . 22
	7.3.3. Congestion Avoidance . . . . . . . . . . . . . . . . 22		7.3.3. Congestion Avoidance . . . . . . . . . . . . . . . . 23
	7.4. Ignoring Loss of Undecryptable Packets . . . . . . . . . 23		7.4. Ignoring Loss of Undecryptable Packets . . . . . . . . . 23
	7.5. Probe Timeout . . . . . . . . . . . . . . . . . . . . . . 23		7.5. Probe Timeout . . . . . . . . . . . . . . . . . . . . . . 24
	7.6. Persistent Congestion . . . . . . . . . . . . . . . . . . 23		7.6. Persistent Congestion . . . . . . . . . . . . . . . . . . 24
	7.6.1. Duration . . . . . . . . . . . . . . . . . . . . . . 23		7.6.1. Duration . . . . . . . . . . . . . . . . . . . . . . 24
	7.6.2. Establishing Persistent Congestion . . . . . . . . . 24		7.6.2. Establishing Persistent Congestion . . . . . . . . . 25
	7.6.3. Example . . . . . . . . . . . . . . . . . . . . . . . 25		7.6.3. Example . . . . . . . . . . . . . . . . . . . . . . . 26
	7.7. Pacing . . . . . . . . . . . . . . . . . . . . . . . . . 26		7.7. Pacing . . . . . . . . . . . . . . . . . . . . . . . . . 27
	7.8. Under-utilizing the Congestion Window . . . . . . . . . . 27		7.8. Under-utilizing the Congestion Window . . . . . . . . . . 28
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 28		8. Security Considerations . . . . . . . . . . . . . . . . . . . 28
	8.1. Loss and Congestion Signals . . . . . . . . . . . . . . . 28		8.1. Loss and Congestion Signals . . . . . . . . . . . . . . . 28
	8.2. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 28		8.2. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 28
	8.3. Misreporting ECN Markings . . . . . . . . . . . . . . . . 28		8.3. Misreporting ECN Markings . . . . . . . . . . . . . . . . 28
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 29		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
	10.1. Normative References . . . . . . . . . . . . . . . . . . 29		10.1. Normative References . . . . . . . . . . . . . . . . . . 29
	10.2. Informative References . . . . . . . . . . . . . . . . . 29		10.2. Informative References . . . . . . . . . . . . . . . . . 30
	10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 31		10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 31
	Appendix A. Loss Recovery Pseudocode . . . . . . . . . . . . . . 31		Appendix A. Loss Recovery Pseudocode . . . . . . . . . . . . . . 32
	A.1. Tracking Sent Packets . . . . . . . . . . . . . . . . . . 32		A.1. Tracking Sent Packets . . . . . . . . . . . . . . . . . . 32
	A.1.1. Sent Packet Fields . . . . . . . . . . . . . . . . . 32		A.1.1. Sent Packet Fields . . . . . . . . . . . . . . . . . 32
	A.2. Constants of Interest . . . . . . . . . . . . . . . . . . 32		A.2. Constants of Interest . . . . . . . . . . . . . . . . . . 32
	A.3. Variables of interest . . . . . . . . . . . . . . . . . . 33		A.3. Variables of interest . . . . . . . . . . . . . . . . . . 33
	A.4. Initialization . . . . . . . . . . . . . . . . . . . . . 34		A.4. Initialization . . . . . . . . . . . . . . . . . . . . . 34
	A.5. On Sending a Packet . . . . . . . . . . . . . . . . . . . 34		A.5. On Sending a Packet . . . . . . . . . . . . . . . . . . . 34
	A.6. On Receiving a Datagram . . . . . . . . . . . . . . . . . 35		A.6. On Receiving a Datagram . . . . . . . . . . . . . . . . . 35
	A.7. On Receiving an Acknowledgment . . . . . . . . . . . . . 35		A.7. On Receiving an Acknowledgment . . . . . . . . . . . . . 35
	A.8. Setting the Loss Detection Timer . . . . . . . . . . . . 36		A.8. Setting the Loss Detection Timer . . . . . . . . . . . . 37
	A.9. On Timeout . . . . . . . . . . . . . . . . . . . . . . . 38		A.9. On Timeout . . . . . . . . . . . . . . . . . . . . . . . 39
	A.10. Detecting Lost Packets . . . . . . . . . . . . . . . . . 39		A.10. Detecting Lost Packets . . . . . . . . . . . . . . . . . 39
	A.11. Upon Dropping Initial or Handshake Keys . . . . . . . . . 40		A.11. Upon Dropping Initial or Handshake Keys . . . . . . . . . 40
	Appendix B. Congestion Control Pseudocode . . . . . . . . . . . 41		Appendix B. Congestion Control Pseudocode . . . . . . . . . . . 41
	B.1. Constants of interest . . . . . . . . . . . . . . . . . . 41		B.1. Constants of interest . . . . . . . . . . . . . . . . . . 41
	B.2. Variables of interest . . . . . . . . . . . . . . . . . . 41		B.2. Variables of interest . . . . . . . . . . . . . . . . . . 41
	B.3. Initialization . . . . . . . . . . . . . . . . . . . . . 42		B.3. Initialization . . . . . . . . . . . . . . . . . . . . . 42
	B.4. On Packet Sent . . . . . . . . . . . . . . . . . . . . . 42		B.4. On Packet Sent . . . . . . . . . . . . . . . . . . . . . 42
	B.5. On Packet Acknowledgment . . . . . . . . . . . . . . . . 42		B.5. On Packet Acknowledgment . . . . . . . . . . . . . . . . 42
	B.6. On New Congestion Event . . . . . . . . . . . . . . . . . 43		B.6. On New Congestion Event . . . . . . . . . . . . . . . . . 43
	B.7. Process ECN Information . . . . . . . . . . . . . . . . . 44		B.7. Process ECN Information . . . . . . . . . . . . . . . . . 44
	skipping to change at page 5, line 19 ¶		skipping to change at page 5, line 19 ¶
	In-flight packets: Packets are considered in-flight when they are		In-flight packets: Packets are considered in-flight when they are
	ack-eliciting or contain a PADDING frame, and they have been sent		ack-eliciting or contain a PADDING frame, and they have been sent
	but are not acknowledged, declared lost, or discarded along with		but are not acknowledged, declared lost, or discarded along with
	old keys.		old keys.
	3. Design of the QUIC Transmission Machinery		3. Design of the QUIC Transmission Machinery
	All transmissions in QUIC are sent with a packet-level header, which		All transmissions in QUIC are sent with a packet-level header, which
	indicates the encryption level and includes a packet sequence number		indicates the encryption level and includes a packet sequence number
	(referred to below as a packet number). The encryption level		(referred to below as a packet number). The encryption level
	indicates the packet number space, as described in Section 12.3 in		indicates the packet number space, as described in Section 12.3 of
	[QUIC-TRANSPORT]. Packet numbers never repeat within a packet number		[QUIC-TRANSPORT]. Packet numbers never repeat within a packet number
	space for the lifetime of a connection. Packet numbers are sent in		space for the lifetime of a connection. Packet numbers are sent in
	monotonically increasing order within a space, preventing ambiguity.		monotonically increasing order within a space, preventing ambiguity.
	It is permitted for some packet numbers to never be used, leaving		It is permitted for some packet numbers to never be used, leaving
	intentional gaps.		intentional gaps.
	This design obviates the need for disambiguating between		This design obviates the need for disambiguating between
	transmissions and retransmissions; this eliminates significant		transmissions and retransmissions; this eliminates significant
	complexity from QUIC's interpretation of TCP loss detection		complexity from QUIC's interpretation of TCP loss detection
	mechanisms.		mechanisms.
	skipping to change at page 11, line 46 ¶		skipping to change at page 11, line 46 ¶
	smoothed_rtt and rttvar are initialized as follows, where kInitialRtt		smoothed_rtt and rttvar are initialized as follows, where kInitialRtt
	contains the initial RTT value:		contains the initial RTT value:
	smoothed_rtt = kInitialRtt		smoothed_rtt = kInitialRtt
	rttvar = kInitialRtt / 2		rttvar = kInitialRtt / 2
	RTT samples for the network path are recorded in latest_rtt; see		RTT samples for the network path are recorded in latest_rtt; see
	Section 5.1. On the first RTT sample after initialization, the		Section 5.1. On the first RTT sample after initialization, the
	estimator is reset using that sample. This ensures that the		estimator is reset using that sample. This ensures that the
	estimator retains no history of past samples.		estimator retains no history of past samples. Packets sent on other
			paths do not contribute RTT samples to the current path, as described
			in Section 9.4 of [QUIC-TRANSPORT].
	On the first RTT sample after initialization, smoothed_rtt and rttvar		On the first RTT sample after initialization, smoothed_rtt and rttvar
	are set as follows:		are set as follows:
	smoothed_rtt = latest_rtt		smoothed_rtt = latest_rtt
	rttvar = latest_rtt / 2		rttvar = latest_rtt / 2
	On subsequent RTT samples, smoothed_rtt and rttvar evolve as follows:		On subsequent RTT samples, smoothed_rtt and rttvar evolve as follows:
	ack_delay = decoded acknowledgment delay from ACK frame		ack_delay = decoded acknowledgment delay from ACK frame
	if (handshake confirmed):		if (handshake confirmed):
	ack_delay = min(ack_delay, max_ack_delay)		ack_delay = min(ack_delay, max_ack_delay)
	adjusted_rtt = latest_rtt		adjusted_rtt = latest_rtt
	if (min_rtt + ack_delay < latest_rtt):		if (min_rtt + ack_delay < latest_rtt):
	adjusted_rtt = latest_rtt - ack_delay		adjusted_rtt = latest_rtt - ack_delay
	smoothed_rtt = 7/8 * smoothed_rtt + 1/8 * adjusted_rtt		smoothed_rtt = 7/8 * smoothed_rtt + 1/8 * adjusted_rtt
	rttvar_sample = abs(smoothed_rtt - adjusted_rtt)		rttvar_sample = abs(smoothed_rtt - adjusted_rtt)
	skipping to change at page 16, line 48 ¶		skipping to change at page 16, line 51 ¶
	forward progress and the loss detection timer might have been set for		forward progress and the loss detection timer might have been set for
	a now discarded packet number space.		a now discarded packet number space.
	6.2.2.1. Before Address Validation		6.2.2.1. Before Address Validation
	Until the server has validated the client's address on the path, the		Until the server has validated the client's address on the path, the
	amount of data it can send is limited to three times the amount of		amount of data it can send is limited to three times the amount of
	data received, as specified in Section 8.1 of [QUIC-TRANSPORT]. If		data received, as specified in Section 8.1 of [QUIC-TRANSPORT]. If
	no additional data can be sent, the server's PTO timer MUST NOT be		no additional data can be sent, the server's PTO timer MUST NOT be
	armed until datagrams have been received from the client, because		armed until datagrams have been received from the client, because
	packets sent on PTO count against the anti-amplification limit. Note		packets sent on PTO count against the anti-amplification limit.
	that the server could fail to validate the client's address even if
	0-RTT is accepted.		When the server receives a datagram from the client, the
			amplification limit is increased and the server resets the PTO timer.
			If the PTO timer is then set to a time in the past, it is executed
			immediately. Doing so avoids sending new 1-RTT packets prior to
			packets critical to the completion of the handshake. In particular,
			this can happen when 0-RTT is accepted but the server fails to
			validate the client's address.
	Since the server could be blocked until more datagrams are received		Since the server could be blocked until more datagrams are received
	from the client, it is the client's responsibility to send packets to		from the client, it is the client's responsibility to send packets to
	unblock the server until it is certain that the server has finished		unblock the server until it is certain that the server has finished
	its address validation (see Section 8 of [QUIC-TRANSPORT]). That is,		its address validation (see Section 8 of [QUIC-TRANSPORT]). That is,
	the client MUST set the probe timer if the client has not received an		the client MUST set the probe timer if the client has not received an
	acknowledgment for any of its Handshake packets and the handshake is		acknowledgment for any of its Handshake packets and the handshake is
	not confirmed (see Section 4.1.2 of [QUIC-TLS]), even if there are no		not confirmed (see Section 4.1.2 of [QUIC-TLS]), even if there are no
	packets in flight. When the PTO fires, the client MUST send a		packets in flight. When the PTO fires, the client MUST send a
	Handshake packet if it has Handshake keys, otherwise it MUST send an		Handshake packet if it has Handshake keys, otherwise it MUST send an
	skipping to change at page 20, line 18 ¶		skipping to change at page 20, line 28 ¶
	document, the chosen controller MUST conform to the congestion		document, the chosen controller MUST conform to the congestion
	control guidelines specified in Section 3.1 of [RFC8085].		control guidelines specified in Section 3.1 of [RFC8085].
	Similar to TCP, packets containing only ACK frames do not count		Similar to TCP, packets containing only ACK frames do not count
	towards bytes in flight and are not congestion controlled. Unlike		towards bytes in flight and are not congestion controlled. Unlike
	TCP, QUIC can detect the loss of these packets and MAY use that		TCP, QUIC can detect the loss of these packets and MAY use that
	information to adjust the congestion controller or the rate of ACK-		information to adjust the congestion controller or the rate of ACK-
	only packets being sent, but this document does not describe a		only packets being sent, but this document does not describe a
	mechanism for doing so.		mechanism for doing so.
			The congestion controller is per path, so packets sent on other paths
			do not alter the current path's congestion controller, as described
			in Section 9.4 of [QUIC-TRANSPORT].
	The algorithm in this document specifies and uses the controller's		The algorithm in this document specifies and uses the controller's
	congestion window in bytes.		congestion window in bytes.
	An endpoint MUST NOT send a packet if it would cause bytes_in_flight		An endpoint MUST NOT send a packet if it would cause bytes_in_flight
	(see Appendix B.2) to be larger than the congestion window, unless		(see Appendix B.2) to be larger than the congestion window, unless
	the packet is sent on a PTO timer expiration (see Section 6.2) or		the packet is sent on a PTO timer expiration (see Section 6.2) or
	when entering recovery (see Section 7.3.2).		when entering recovery (see Section 7.3.2).
	7.1. Explicit Congestion Notification		7.1. Explicit Congestion Notification
	skipping to change at page 29, line 21 ¶		skipping to change at page 29, line 28 ¶
	9. IANA Considerations		9. IANA Considerations
	This document has no IANA actions.		This document has no IANA actions.
	10. References		10. References
	10.1. Normative References		10.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-34 (work in progress), January		QUIC", draft-ietf-quic-tls-latest (work in progress).
	2021.
	[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-34 (work in progress), January 2021.		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>.
	[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 30, line 10 ¶		skipping to change at page 30, line 16 ¶
	[FACK] Mathis, M. and J. Mahdavi, "Forward Acknowledgement:		[FACK] Mathis, M. and J. Mahdavi, "Forward Acknowledgement:
	Refining TCP Congestion Control", ACM SIGCOMM , August		Refining TCP Congestion Control", ACM SIGCOMM , August
	1996.		1996.
	[PRR] Mathis, M., Dukkipati, N., and Y. Cheng, "Proportional		[PRR] Mathis, M., Dukkipati, N., and Y. Cheng, "Proportional
	Rate Reduction for TCP", RFC 6937, DOI 10.17487/RFC6937,		Rate Reduction for TCP", RFC 6937, DOI 10.17487/RFC6937,
	May 2013, <https://www.rfc-editor.org/info/rfc6937>.		May 2013, <https://www.rfc-editor.org/info/rfc6937>.
	[RACK] Cheng, Y., Cardwell, N., Dukkipati, N., and P. Jha, "The		[RACK] Cheng, Y., Cardwell, N., Dukkipati, N., and P. Jha, "The
	RACK-TLP loss detection algorithm for TCP", draft-ietf-		RACK-TLP Loss Detection Algorithm for TCP", draft-ietf-
	tcpm-rack-15 (work in progress), December 2020.		tcpm-rack-15 (work in progress), December 2020.
	[RETRANSMISSION]		[RETRANSMISSION]
	Karn, P. and C. Partridge, "Improving Round-Trip Time		Karn, P. and C. Partridge, "Improving Round-Trip Time
	Estimates in Reliable Transport Protocols", ACM SIGCOMM		Estimates in Reliable Transport Protocols", ACM SIGCOMM
	CCR , January 1995.		CCR , January 1995.
	[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,
	skipping to change at page 35, line 19 ¶		skipping to change at page 35, line 34 ¶
	successfully processed. In such a case, the PTO timer will need to		successfully processed. In such a case, the PTO timer will need to
	be re-armed.		be re-armed.
	Pseudocode for OnDatagramReceived follows:		Pseudocode for OnDatagramReceived follows:
	OnDatagramReceived(datagram):		OnDatagramReceived(datagram):
	// If this datagram unblocks the server, arm the		// If this datagram unblocks the server, arm the
	// PTO timer to avoid deadlock.		// PTO timer to avoid deadlock.
	if (server was at anti-amplification limit):		if (server was at anti-amplification limit):
	SetLossDetectionTimer()		SetLossDetectionTimer()
			if loss_detection_timer.timeout < now():
			// Execute PTO if it would have expired
			// while the amplification limit applied.
			OnLossDetectionTimeout()
	A.7. On Receiving an Acknowledgment		A.7. On Receiving an Acknowledgment
	When an ACK frame is received, it may newly acknowledge any number of		When an ACK frame is received, it may newly acknowledge any number of
	packets.		packets.
	Pseudocode for OnAckReceived and UpdateRtt follow:		Pseudocode for OnAckReceived and UpdateRtt follow:
	IncludesAckEliciting(packets):		IncludesAckEliciting(packets):
	for packet in packets:		for packet in packets:
	skipping to change at page 37, line 26 ¶		skipping to change at page 37, line 46 ¶
	space = Initial		space = Initial
	for pn_space in [ Handshake, ApplicationData ]:		for pn_space in [ Handshake, ApplicationData ]:
	if (time == 0 || loss_time[pn_space] < time):		if (time == 0 || loss_time[pn_space] < time):
	time = loss_time[pn_space];		time = loss_time[pn_space];
	space = pn_space		space = pn_space
	return time, space		return time, space
	GetPtoTimeAndSpace():		GetPtoTimeAndSpace():
	duration = (smoothed_rtt + max(4 * rttvar, kGranularity))		duration = (smoothed_rtt + max(4 * rttvar, kGranularity))
	* (2 ^ pto_count)		* (2 ^ pto_count)
	// Arm PTO from now when there are no inflight packets.		// Anti-deadlock PTO starts from the current time
	if (no in-flight packets):		if (no ack-eliciting packets in flight):
	assert(!PeerCompletedAddressValidation())		assert(!PeerCompletedAddressValidation())
	if (has handshake keys):		if (has handshake keys):
	return (now() + duration), Handshake		return (now() + duration), Handshake
	else:		else:
	return (now() + duration), Initial		return (now() + duration), Initial
	pto_timeout = infinite		pto_timeout = infinite
	pto_space = Initial		pto_space = Initial
	for space in [ Initial, Handshake, ApplicationData ]:		for space in [ Initial, Handshake, ApplicationData ]:
	if (no in-flight packets in space):		if (no ack-eliciting packets in flight in space):
	continue;		continue;
	if (space == ApplicationData):		if (space == ApplicationData):
	// Skip Application Data until handshake confirmed.		// Skip Application Data until handshake confirmed.
	if (handshake is not confirmed):		if (handshake is not confirmed):
	return pto_timeout, pto_space		return pto_timeout, pto_space
	// Include max_ack_delay and backoff for Application Data.		// Include max_ack_delay and backoff for Application Data.
	duration += max_ack_delay * (2 ^ pto_count)		duration += max_ack_delay * (2 ^ pto_count)
	t = time_of_last_ack_eliciting_packet[space] + duration		t = time_of_last_ack_eliciting_packet[space] + duration
	if (t < pto_timeout):		if (t < pto_timeout):
	skipping to change at page 39, line 15 ¶		skipping to change at page 39, line 23 ¶
	OnLossDetectionTimeout():		OnLossDetectionTimeout():
	earliest_loss_time, pn_space = GetLossTimeAndSpace()		earliest_loss_time, pn_space = GetLossTimeAndSpace()
	if (earliest_loss_time != 0):		if (earliest_loss_time != 0):
	// Time threshold loss Detection		// Time threshold loss Detection
	lost_packets = DetectAndRemoveLostPackets(pn_space)		lost_packets = DetectAndRemoveLostPackets(pn_space)
	assert(!lost_packets.empty())		assert(!lost_packets.empty())
	OnPacketsLost(lost_packets)		OnPacketsLost(lost_packets)
	SetLossDetectionTimer()		SetLossDetectionTimer()
	return		return
	if (bytes_in_flight > 0):		if (no ack-eliciting packets in flight):
	// PTO. Send new data if available, else retransmit old data.
	// If neither is available, send a single PING frame.
	_, pn_space = GetPtoTimeAndSpace()
	SendOneOrTwoAckElicitingPackets(pn_space)
	else:
	assert(!PeerCompletedAddressValidation())		assert(!PeerCompletedAddressValidation())
	// Client sends an anti-deadlock packet: Initial is padded		// Client sends an anti-deadlock packet: Initial is padded
	// to earn more anti-amplification credit,		// to earn more anti-amplification credit,
	// a Handshake packet proves address ownership.		// a Handshake packet proves address ownership.
	if (has Handshake keys):		if (has Handshake keys):
	SendOneAckElicitingHandshakePacket()		SendOneAckElicitingHandshakePacket()
	else:		else:
	SendOneAckElicitingPaddedInitialPacket()		SendOneAckElicitingPaddedInitialPacket()
			else:
			// PTO. Send new data if available, else retransmit old data.
			// If neither is available, send a single PING frame.
			_, pn_space = GetPtoTimeAndSpace()
			SendOneOrTwoAckElicitingPackets(pn_space)
	pto_count++		pto_count++
	SetLossDetectionTimer()		SetLossDetectionTimer()
	A.10. Detecting Lost Packets		A.10. Detecting Lost Packets
	DetectAndRemoveLostPackets is called every time an ACK is received or		DetectAndRemoveLostPackets is called every time an ACK is received or
	the time threshold loss detection timer expires. This function		the time threshold loss detection timer expires. This function
	operates on the sent_packets for that packet number space and returns		operates on the sent_packets for that packet number space and returns
	a list of packets newly detected as lost.		a list of packets newly detected as lost.
End of changes. 26 change blocks.
	39 lines changed or deleted		56 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/