draft-ietf-tcpm-rto-consider-01.txt		draft-ietf-tcpm-rto-consider-02.txt
	Internet Engineering Task Force M. Allman		Internet Engineering Task Force M. Allman
	INTERNET-DRAFT ICSI		INTERNET-DRAFT ICSI
	File: draft-ietf-tcpm-rto-consider-01.txt February 29, 2016		File: draft-ietf-tcpm-rto-consider-02.txt April 5, 2016
	Intended Status: Best Current Practice		Intended Status: Best Current Practice
	Expires: August 29, 2016		Expires: October 5, 2016
	Retransmission Timeout Considerations		Retransmission Timeout Considerations
	Status of this Memo		Status of this Memo
	This document may not be modified, and derivative works of it may		This document may not be modified, and derivative works of it may
	not be created, except to format it for publication as an RFC or to		not be created, except to format it for publication as an RFC or to
	translate it into languages other than English.		translate it into languages other than English.
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	skipping to change at page 1, line 34 ¶		skipping to change at page 1, line 34 ¶
	months and may be updated, replaced, or obsoleted by other documents		months and may be updated, replaced, or obsoleted by other documents
	at any time. It is inappropriate to use Internet-Drafts as		at any time. It is inappropriate to use Internet-Drafts as
	reference material or to cite them other than as "work in progress."		reference material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/1id-abstracts.html		http://www.ietf.org/1id-abstracts.html
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html		http://www.ietf.org/shadow.html
	This Internet-Draft will expire on May 2, 2016.		This Internet-Draft will expire on October 5, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2016 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with		carefully, as they describe your rights and restrictions with
	respect to this document. Code Components extracted from this		respect to this document. Code Components extracted from this
	document must include Simplified BSD License text as described in		document must include Simplified BSD License text as described in
	Section 4.e of the Trust Legal Provisions and are provided without		Section 4.e of the Trust Legal Provisions and are provided without
	skipping to change at page 3, line 12 ¶		skipping to change at page 3, line 12 ¶
	own subtle imprint on the specifics of the process to tilt the		own subtle imprint on the specifics of the process to tilt the
	tradeoff between correctness and responsiveness in some particular		tradeoff between correctness and responsiveness in some particular
	way.		way.
	At this point we recognize that often these specific tweaks are not		At this point we recognize that often these specific tweaks are not
	crucial for network safety. Hence, in this document we outline the		crucial for network safety. Hence, in this document we outline the
	high-level principles that are crucial for any retransmission		high-level principles that are crucial for any retransmission
	timeout scheme to follow. The intent is to then allow		timeout scheme to follow. The intent is to then allow
	implementations of protocols and applications to instantiate		implementations of protocols and applications to instantiate
	mechanisms that best realize their specific goals within this		mechanisms that best realize their specific goals within this
	framework. These specific mechanisms could be standardized or		framework. These specific mechanisms could be standardized by the
	ad-hoc, but as long as they adhere to the guidelines given in this		IETF or ad-hoc, but as long as they adhere to the guidelines given
	document they would be considered consistent with the standards.		in this document they would be considered consistent with the
			standards.
	A non-goal of this document is to in any way specify individual		A non-goal of this document is to in any way specify individual
	deviations from standard RTO specifications that any particular		deviations from current IETF standardized RTO specifications that
	implementation may exhibit. Rather, we provide a set of		any particular implementation may exhibit. Rather, we provide a set
	over-arching guidelines that all RTO mechanisms should follow.		of over-arching guidelines that all RTO mechanisms should follow.
	Finally, we note the guidelines in this document are applicable to		Finally, we note the guidelines in this document are applicable to
	any protocol that uses an RTO mechanism. The examples and		any protocol that uses an RTO mechanism. The examples and
	discussion are framed in terms of TCP, however, that is an artifact		discussion are framed in terms of TCP, however, that is an artifact
	of where much of our experience with RTOs comes from and should not		of where much of our experience with RTOs comes from and should not
	be read as narrowing the scope of the guidelines.		be read as narrowing the scope of the guidelines.
	2 Guidelines		2 Guidelines
	We now list the four guidelines that apply when utilizing a		We now list the four guidelines that apply when utilizing a
	skipping to change at page 4, line 21 ¶		skipping to change at page 4, line 21 ¶
	data.		data.
	(b) FT observations MUST be taken regularly.		(b) FT observations MUST be taken regularly.
	The exact definition of "regularly" is deliberately left		The exact definition of "regularly" is deliberately left
	vague. TCP takes a FT sample roughly once per RTT, or if		vague. TCP takes a FT sample roughly once per RTT, or if
	using the timestamp option [RFC7323] on each acknowledgment		using the timestamp option [RFC7323] on each acknowledgment
	arrival. [AP99] shows that both these approaches result in		arrival. [AP99] shows that both these approaches result in
	roughly equivalent performance for the RTO estimator.		roughly equivalent performance for the RTO estimator.
	Additionally, [AP99] shows that taking only a single FT		Additionally, [AP99] shows that taking only a single FT
	sample per TCP connection is suboptimal. Therefore, for the		sample per TCP connection is suboptimal and hence the
	purpose of this guideline we state that FT samples SHOULD be		requirement that the FT be sampled continuously throughout
	taken at least once per RTT or as frequently as data is		the lifetime of a connection. For the purpose of this
	exchanged and ACKed if that happens less frequently than		guideline, we state that FT samples SHOULD be taken at least
	every RTT. However, we also recognize that it may not		once per RTT or as frequently as data is exchanged and ACKed
	always be practical to take a FT sample this often in all		if that happens less frequently than every RTT. However, we
	cases and hence this requirement is explicitly a "SHOULD"		also recognize that it may not always be practical to take a
	and not a "MUST".		FT sample this often in all cases and hence this requirement
			is explicitly a "SHOULD" and not a "MUST".
	(c) FT samples used in the computation of the RTO MUST NOT be		(c) FT samples used in the computation of the RTO MUST NOT be
	ambiguous.		ambiguous.
	Assume two copies of some segment X are transmitted at times		Assume two copies of some segment X are transmitted at times
	t0 and t1 and then segment X is acknowledged at time t2. In		t0 and t1 and then segment X is acknowledged at time t2. In
	some cases, it is not clear which copy of X triggered the		some cases, it is not clear which copy of X triggered the
	ACK and hence the actual FT is either t2-t1 or t2-t0, but		ACK and hence the actual FT is either t2-t1 or t2-t0, but
	which is a mystery. Therefore, in this situation an		which is a mystery. Therefore, in this situation an
	implementation MUST use Karn's algorithm [KP87,RFC6298] and		implementation MUST use Karn's algorithm [KP87,RFC6298] and
	skipping to change at page 5, line 12 ¶		skipping to change at page 5, line 14 ¶
	This ensures network safety.		This ensures network safety.
	(4) Retransmission timeouts MUST be taken as indications of		(4) Retransmission timeouts MUST be taken as indications of
	congestion in the network and the sending rate adapted using a		congestion in the network and the sending rate adapted using a
	standard mechanism (e.g., TCP collapses the congestion window to		standard mechanism (e.g., TCP collapses the congestion window to
	one segment [RFC5681]).		one segment [RFC5681]).
	This ensures network safety.		This ensures network safety.
	An exception is made to this rule if a standard mechanism is		An exception is made to this rule if an IETF standardized
	used to determine that a particular loss is due to a		mechanism is used to determine that a particular loss is due to
	non-congestion event (e.g., packet corruption). In such a case		a non-congestion event (e.g., packet corruption). In such a
	a congestion control action is not required. Additionally,		case a congestion control action is not required. Additionally,
	RTO-triggered congestion control actions may be reversed when a		RTO-triggered congestion control actions may be reversed when a
	standard mechanism determines that the cause of the loss was not		standard mechanism determines that the cause of the loss was not
	congestion after all.		congestion after all.
	3 Discussion		3 Discussion
	We note that research has shown the tension between responsiveness		We note that research has shown the tension between responsiveness
	and correctness of TCP's RTO seems to be a fundamental tradeoff		and correctness of TCP's RTO seems to be a fundamental tradeoff
	[AP99]. That is, making TCP's RTO more aggressive (via the EWMA		[AP99]. That is, making TCP's RTO more aggressive (via the EWMA
	gains, lowering the minimum RTO, etc.) can reduce the time spent		gains, lowering the minimum RTO, etc.) can reduce the time spent
	skipping to change at page 5, line 44 ¶		skipping to change at page 5, line 46 ¶
	fundamental, the tradeoff can be made less relevant if the sender		fundamental, the tradeoff can be made less relevant if the sender
	can detect and recover from spurious RTOs. Several mechanisms have		can detect and recover from spurious RTOs. Several mechanisms have
	been proposed for this purpose, such as Eifel [RFC3522], F-RTO		been proposed for this purpose, such as Eifel [RFC3522], F-RTO
	[RFC5682] and DSACK [RFC2883,RFC3708]. Using such mechanisms may		[RFC5682] and DSACK [RFC2883,RFC3708]. Using such mechanisms may
	allow a data originator to tip towards being more responsive without		allow a data originator to tip towards being more responsive without
	incurring (as much of) the attendant costs of needless retransmits.		incurring (as much of) the attendant costs of needless retransmits.
	Also, note, that in addition to the experiments discussed in [AP99],		Also, note, that in addition to the experiments discussed in [AP99],
	the Linux TCP implementation has been using various non-standard RTO		the Linux TCP implementation has been using various non-standard RTO
	mechanisms for many years seemingly without large scale problems		mechanisms for many years seemingly without large scale problems
	(e.g., using different EWMA gains). Also, a number of		(e.g., using different EWMA gains). Further, a number of
	implementations use minimum RTOs that are less than the 1 second		implementations use minimum RTOs that are less than the 1 second
	specified in [RFC6298]. While the precise implications of this may		specified in [RFC6298]. While the implication of these deviations
	show more spurious retransmits (per [AP99]) we are aware of no large		from the standard may be more spurious retransmits (per [AP99]), we
	scale problems caused by this change to the minimum RTO.		are aware of no large scale problems caused by this change to the
			minimum RTO.
	Finally, we note that while allowing implementations to be more		Finally, we note that while allowing implementations to be more
	aggressive may in fact increase the number of needless		aggressive may in fact increase the number of needless
	retransmissions the above guidelines fail safe in that they insist		retransmissions the above guidelines fail safe in that they insist
	on exponential backoff of the RTO and a transmission rate reduction.		on exponential backoff of the RTO and a transmission rate reduction.
	Therefore, allowing implementers latitude in their instantiations of		Therefore, allowing implementers latitude in their instantiations of
	an RTO mechanism does not somehow open the flood gates to aggressive		an RTO mechanism does not somehow open the flood gates to aggressive
	behavior. Since there is a downside to being aggressive the		behavior. Since there is a downside to being aggressive the
	incentives for proper behavior are retained in the mechanism.		incentives for proper behavior are retained in the mechanism.
	4 Security Considerations		4 Security Considerations
	This document does not alter the security properties of		This document does not alter the security properties of
	retransmission timeout mechanisms. See [RFC6298] for a discussion		retransmission timeout mechanisms. See [RFC6298] for a discussion
	of these within the context of TCP.		of these within the context of TCP.
	Acknowledgments		Acknowledgments
	This document benefits from years of discussions with Ethan Blanton,		This document benefits from years of discussions with Ethan Blanton,
	Sally Floyd, Shawn Ostermann, Vern Paxson and the members of the		Sally Floyd, Jana Iyengar, Shawn Ostermann, Vern Paxson and the
	TCPM and TCP-IMPL working groups. Ran Atkinson, Yuchung Cheng,		members of the TCPM and TCP-IMPL working groups. Ran Atkinson,
	Jonathan Looney and Michael Scharf provided useful comments on a		Yuchung Cheng, Jonathan Looney and Michael Scharf provided useful
	previous version of this draft.		comments on a previous version of this draft.
	Normative References		Normative References
	[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, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	Informative References		Informative References
	[AP99] Allman, M., V. Paxson, "On Estimating End-to-End Network Path		[AP99] Allman, M., V. Paxson, "On Estimating End-to-End Network Path
	Properties", Proceedings of the ACM SIGCOMM Technical Symposium,		Properties", Proceedings of the ACM SIGCOMM Technical Symposium,
End of changes. 11 change blocks.
	30 lines changed or deleted		33 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/