draft-ietf-tsvwg-tcp-frto-00.txt		draft-ietf-tsvwg-tcp-frto-01.txt
	Internet Engineering Task Force P. Sarolahti		Internet Engineering Task Force P. Sarolahti
	INTERNET DRAFT Nokia Research Center		INTERNET DRAFT Nokia Research Center
	File: draft-ietf-tsvwg-tcp-frto-00.txt M. Kojo		File: draft-ietf-tsvwg-tcp-frto-01.txt M. Kojo
	University of Helsinki		University of Helsinki
	October, 2003		February, 2004
	Expires: April, 2004		Expires: August, 2004
	F-RTO: An Algorithm for Detecting		F-RTO: An Algorithm for Detecting
	Spurious Retransmission Timeouts with TCP and SCTP		Spurious Retransmission Timeouts with TCP and SCTP
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of [RFC2026].		all provisions of Section 10 of [RFC2026].
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	skipping to change at page 2, line 6		skipping to change at page 2, line 6
	a TCP sender only algorithm that does not require any TCP options to		a TCP sender only algorithm that does not require any TCP options to
	operate. After retransmitting the first unacknowledged segment		operate. After retransmitting the first unacknowledged segment
	triggered by an RTO, the F-RTO algorithm at a TCP sender monitors the		triggered by an RTO, the F-RTO algorithm at a TCP sender monitors the
	incoming acknowledgements to determine whether the timeout was		incoming acknowledgements to determine whether the timeout was
	spurious and to decide whether to send new segments or retransmit		spurious and to decide whether to send new segments or retransmit
	unacknowledged segments. The algorithm effectively helps to avoid		unacknowledged segments. The algorithm effectively helps to avoid
	additional unnecessary retransmissions and thereby improves TCP		additional unnecessary retransmissions and thereby improves TCP
	performance in case of a spurious timeout. The F-RTO algorithm can		performance in case of a spurious timeout. The F-RTO algorithm can
	also be applied with the SCTP protocol.		also be applied with the SCTP protocol.
			Terminology
			The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
			SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
			document, are to be interpreted as described in [RFC2119].
	1. Introduction		1. Introduction
	The TCP protocol [Pos81] has two methods for triggering		The TCP protocol [Pos81] has two methods for triggering
	retransmissions. Primarily, the TCP sender relies on incoming		retransmissions. Primarily, the TCP sender relies on incoming
	duplicate ACKs, which indicate that the receiver is missing some of		duplicate ACKs, which indicate that the receiver is missing some of
	the data. After a required amount of successive duplicate ACKs have		the data. After a required number of successive duplicate ACKs have
	arrived at the sender, it retransmits the first unacknowledged		arrived at the sender, it retransmits the first unacknowledged
	segment [APS99]. Secondarily, the TCP sender maintains a		segment [APS99]. Secondarily, the TCP sender maintains a
	retransmission timer which triggers retransmission of segments, if		retransmission timer which triggers retransmission of segments, if
	they have not been acknowledged within the retransmission timer		they have not been acknowledged within the retransmission timer
	expiration period. When the retransmission timer expires, the TCP		expiration period. When the retransmission timer expires, the TCP
	sender enters the RTO recovery where congestion window is initialized		sender enters the RTO recovery where congestion window is initialized
	to one segment and unacknowledged segments are retransmitted using		to one segment and unacknowledged segments are retransmitted using
	the slow-start algorithm. The retransmission timer is adjusted		the slow-start algorithm. The retransmission timer is adjusted
	dynamically based on the measured round-trip times [PA00].		dynamically based on the measured round-trip times [PA00].
	It has been pointed out that the retransmission timer can expire		It has been pointed out that the retransmission timer can expire
	spuriously and trigger unnecessary retransmissions when no segments		spuriously and trigger unnecessary retransmissions when no segments
	have been lost [GL02]. After a spurious RTO the late acknowledgements		have been lost [LK00, GL02, LM03]. After a spurious retransmission
	of original segments arrive at the sender, usually triggering		timeout the late acknowledgements of original segments arrive at the
	unnecessary retransmissions of whole window of segments during the		sender, usually triggering unnecessary retransmissions of whole
	RTO recovery. Furthermore, after a spurious RTO a conventional TCP		window of segments during the RTO recovery. Furthermore, after a
	sender increases the congestion window on each late acknowledgement		spurious retransmission timeout a conventional TCP sender increases
	in slow start, injecting a large number of data segments to the		the congestion window on each late acknowledgement in slow start,
	network within one round-trip time.		injecting a large number of data segments to the network within one
			round-trip time.
	There are a number of potential reasons for spurious RTOs. First,		There are a number of potential reasons for spurious retransmission
	some mobile networking technologies involve sudden delay peaks on		timeouts. First, some mobile networking technologies involve sudden
	transmission because of actions taken during a hand-off. Second,		delay peaks on transmission because of actions taken during a hand-
	arrival of competing traffic, possibly with higher priority, on a		off. Second, arrival of competing traffic, possibly with higher
	low-bandwidth link or some other change in available bandwidth		priority, on a low-bandwidth link or some other change in available
	involves a sudden increase of round-trip time which may trigger a		bandwidth involves a sudden increase of round-trip time which may
	spurious retransmission timeout. A persistently reliable link layer		trigger a spurious retransmission timeout. A persistently reliable
	can also cause a sudden delay when several data frames are lost for		link layer can also cause a sudden delay when several data frames are
	some reason. This document does not distinguish the different causes		lost for some reason. This document does not distinguish the
	of such a delay, but discusses the spurious RTOs caused by a delay in		different causes of such a delay, but discusses the spurious
	general.		retransmission timeouts caused by a delay in general.
	This document describes an alternative RTO recovery algorithm called		This document describes an alternative RTO recovery algorithm called
	"Forward RTO-Recovery" (F-RTO) to be used for detecting spurious RTOs		"Forward RTO-Recovery" (F-RTO) to be used for detecting spurious RTOs
	and thus avoiding unnecessary retransmissions following the RTO. When		and thus avoiding unnecessary retransmissions following the RTO. When
	the RTO is not spurious, the F-RTO algorithm reverts back to the		the RTO is not spurious, the F-RTO algorithm reverts back to the
	conventional RTO recovery algorithm and should have similar behavior		conventional RTO recovery algorithm and should have similar behavior
	and performance. F-RTO does not require any TCP options in its		and performance. F-RTO does not require any TCP options in its
	operation, and it can be implemented by modifying only the TCP		operation, and it can be implemented by modifying only the TCP
	sender. This is different from alternative algorithms (Eifel [LK00],		sender. This is different from alternative algorithms (Eifel [LK00],
	[LM03] and DSACK-based algorithms [BA02]) that have been suggested		[LM03] and DSACK-based algorithms [BA02]) that have been suggested
	for detecting unnecessary retransmissions. The Eifel algorithm uses		for detecting unnecessary retransmissions. The Eifel algorithm uses
	TCP timestamps [BBJ92] for detecting a spurious timeout and the		TCP timestamps [BBJ92] for detecting a spurious timeout upon arrival
	DSACK-based algorithms require that the TCP Selective Acknowledgment		of the first acknowledgement after the retransmission. The DSACK-
	Option [MMFR96] with DSACK extension [FMMP00] is in use. With DSACK,		based algorithms require that the TCP Selective Acknowledgment Option
	the TCP receiver can report if it has received a duplicate segment,		[MMFR96] with DSACK extension [FMMP00] is in use. With DSACK, the TCP
	making it possible for the sender to detect afterwards whether it has		receiver can report if it has received a duplicate segment, making it
	retransmitted segments unnecessarily.		possible for the sender to detect afterwards whether it has
			retransmitted segments unnecessarily. In addition, the F-RTO
			algorithm only attempts to detect and avoid unnecessary
			retransmissions after an RTO. Eifel and DSACK can also be used in
			detecting unnecessary retransmissions in other events, for example
			due to packet reordering.
	When an RTO occurs, the F-RTO sender retransmits the first		When an RTO occurs, the F-RTO sender retransmits the first
	unacknowledged segment normally, but tries to transmit new,		unacknowledged segment as usual. Deviating from the normal operation
	previously unsent data after that. If the next two acknowledgements		after a timeout, it then tries to transmit new, previously unsent
	cover segments that were not retransmitted, the F-RTO sender can		data, for the first acknowledgement that arrives after the timeout
	declare the RTO spurious and exit the RTO recovery. However, if		given that the acknowledgement advances the window. If the second
	either of the next two acknowledgements is a duplicate ACK, there was		acknowledgement that arrives after the timeout also advances the
	no sufficient evidence of spurious RTO; therefore the F-RTO sender		window, i.e., acknowledges data that was not retransmitted, the F-RTO
	retransmits the unacknowledged segments in slow start similarly to		sender declares the RTO spurious and exit the RTO recovery. However,
	the traditional algorithm. With a SACK-enhanced version of the F-RTO		if either of the next two acknowledgements is a duplicate ACK, there
	algorithm, spurious RTOs may be detected even if duplicate ACKs		was no sufficient evidence of spurious RTO; therefore the F-RTO
	arrive after an RTO. The F-RTO algorithm only attempts to detect and		sender retransmits the unacknowledged segments in slow start
	avoid unnecessary retransmissions after an RTO. Eifel and DSACK can		similarly to the traditional algorithm. With a SACK-enhanced version
	also be used in detecting unnecessary retransmissions in other		of the F-RTO algorithm, spurious RTOs may be detected even if
	events, for example due to packet reordering.		duplicate ACKs arrive after an RTO.
	The F-RTO algorithm can also be applied with the SCTP protocol		The F-RTO algorithm can also be applied with the SCTP protocol
	[Ste00], because SCTP has similar acknowledgement and packet		[Ste00], because SCTP has similar acknowledgement and packet
	retransmission concepts as TCP. When a SCTP retransmission timeout		retransmission concepts as TCP. When a SCTP retransmission timeout
	occurs, the SCTP sender is required to retransmit the outstanding		occurs, the SCTP sender is required to retransmit the outstanding
	data similarly to TCP, thus being prone to unnecessary		data similarly to TCP, thus being prone to unnecessary
	retransmissions and congestion control adjustments, if delay spikes		retransmissions and congestion control adjustments, if delay spikes
	occur in the network. The SACK-enhanced version of F-RTO should be		occur in the network. The SACK-enhanced version of F-RTO should be
	directly applicable to SCTP, which has selective acknowledgements as		directly applicable to SCTP, which has selective acknowledgements as
	a built-in feature. For simplicity, this document mostly refers to		a built-in feature. For simplicity, this document mostly refers to
	skipping to change at page 4, line 38		skipping to change at page 5, line 4
	the highest sequence number transmitted so far in variable		the highest sequence number transmitted so far in variable
	"send_high".		"send_high".
	2) When the first acknowledgement after the RTO arrives at the		2) When the first acknowledgement after the RTO arrives at the
	sender, the sender chooses the following actions depending on		sender, the sender chooses the following actions depending on
	whether the ACK advances the window or whether it is a duplicate		whether the ACK advances the window or whether it is a duplicate
	ACK.		ACK.
	a) If the acknowledgement is a duplicate ACK OR it is		a) If the acknowledgement is a duplicate ACK OR it is
	acknowledging a sequence number equal to (or above) the value		acknowledging a sequence number equal to (or above) the value
	of send_high, the TCP sender MUST revert to the conventional		of send_high OR it does not acknowledge all of the data that
	RTO recovery, and continue by retransmitting unacknowledged		was retransmitted in step 1, the TCP sender MUST revert to the
	data in slow start. The TCP sender MUST NOT enter step 3 of		conventional RTO recovery and continue by retransmitting
	this algorithm, and the SpuriousRecovery variable remains as		unacknowledged data in slow start. The TCP sender MUST NOT
	FALSE.		enter step 3 of this algorithm, and the SpuriousRecovery
			variable remains as FALSE.
	b) If the acknowledgement advances the window AND it is below the		b) If the acknowledgement advances the window AND it is below the
	value of send_high, the TCP sender SHOULD transmit up to two		value of send_high, the TCP sender SHOULD transmit up to two
	new (previously unsent) segments and enter step 3 of this		new (previously unsent) segments and enter step 3 of this
	algorithm. If the TCP sender does not have enough unsent data,		algorithm. If the TCP sender does not have enough unsent data,
	it SHOULD send only one segment. In addition, the TCP sender		it SHOULD send only one segment. In addition, the TCP sender
	MAY override the Nagle algorithm and send immediately an		MAY override the Nagle algorithm and send immediately an
	undersized segment if needed. If the TCP sender does not have		undersized segment if needed. If the TCP sender does not have
	any new data to send, the TCP sender SHOULD transmit a segment		any new data to send, the TCP sender SHOULD transmit a segment
	from the retransmission queue. If TCP sender retransmits the		from the retransmission queue. If TCP sender retransmits the
	first unacknowledged segment, it MUST NOT enter step 3 of this		first unacknowledged segment, it MUST NOT enter step 3 of this
	algorithm but continue with the conventional RTO recovery		algorithm but continue with the conventional RTO recovery
	algorithm.		algorithm. In this case acknowledgement of the next segment
			would not unambiguously indicate that the original transmission
			arrived at the receiver.
	3) When the second acknowledgement after the RTO arrives at the		3) When the second acknowledgement after the RTO arrives at the
	sender, either declare the RTO spurious, or start retransmitting		sender, either declare the RTO spurious, or start retransmitting
	the unacknowledged segments.		the unacknowledged segments.
	a) If the acknowledgement is a duplicate ACK, the TCP sender MUST		a) If the acknowledgement is a duplicate ACK, the TCP sender MUST
	set congestion window to no more than 3 * MSS, and continue		set congestion window to no more than 3 * MSS, and continue
	with the slow start algorithm retransmitting unacknowledged		with the slow start algorithm retransmitting unacknowledged
	segments. The sender leaves SpuriousRecovery to FALSE.		segments. The sender leaves SpuriousRecovery set to FALSE.
	b) If the acknowledgement advances the window, i.e. it		b) If the acknowledgement advances the window, i.e. it
	acknowledges data that was not retransmitted after the RTO, the		acknowledges data that was not retransmitted after the RTO, the
	TCP sender SHOULD declare the RTO spurious, set		TCP sender SHOULD declare the RTO spurious, set
	SpuriousRecovery to SPUR_TO and set the value of send_high		SpuriousRecovery to SPUR_TO and set the value of send_high
	variable to SND.UNA.		variable to SND.UNA.
	The F-RTO sender takes cautious actions when it receives duplicate		The F-RTO sender takes cautious actions when it receives duplicate
	acknowledgements after an RTO. Since duplicate ACKs may indicate that		acknowledgements after an RTO. Since duplicate ACKs may indicate that
	segments have been lost, reliably detecting a spurious RTO is		segments have been lost, reliably detecting a spurious RTO is
	skipping to change at page 5, line 35		skipping to change at page 6, line 4
	The F-RTO sender takes cautious actions when it receives duplicate		The F-RTO sender takes cautious actions when it receives duplicate
	acknowledgements after an RTO. Since duplicate ACKs may indicate that		acknowledgements after an RTO. Since duplicate ACKs may indicate that
	segments have been lost, reliably detecting a spurious RTO is		segments have been lost, reliably detecting a spurious RTO is
	difficult in the lack of additional information. Therefore the safest		difficult in the lack of additional information. Therefore the safest
	alternative is to follow the conventional TCP recovery in those		alternative is to follow the conventional TCP recovery in those
	cases.		cases.
	If the first acknowledgement after RTO covers the send_high point at		If the first acknowledgement after RTO covers the send_high point at
	algorithm step (2a), there is not enough evidence that a non-		algorithm step (2a), there is not enough evidence that a non-
	retransmitted segment has arrived at the receiver after the RTO.		retransmitted segment has arrived at the receiver after the RTO.
	This is a common case when a fast retransmission is lost and it has		This is a common case when a fast retransmission is lost and it has
	been retransmitted again after an RTO, while the rest of the		been retransmitted again after an RTO, while the rest of the
	unacknowledged segments have successfully been delivered to the TCP		unacknowledged segments have successfully been delivered to the TCP
	receiver before the RTO. Therefore the RTO cannot be declared		receiver before the RTO. Therefore the RTO cannot be declared
	spurious in this case.		spurious in this case.
	If the first acknowledgement after RTO does not acknowledge all of		If the first acknowledgement after RTO does not acknowledge all of
	the data that was retransmitted in step 1, the TCP sender must not		the data that was retransmitted in step 1, the TCP sender reverts to
	enter step 3 of this algorithm, but revert to the conventional RTO		the conventional RTO recovery. Otherwise, a malicious receiver
	recovery. Otherwise, a malicious receiver acknowledging partial		acknowledging partial segments could cause the sender to declare the
	segments could cause the sender to declare the RTO spurious in a case		RTO spurious in a case where data was lost.
	where data was lost.
	The TCP sender is allowed to send two new segments in algorithm		The TCP sender is allowed to send two new segments in algorithm
	branch (2b), because the conventional TCP sender would retransmit two		branch (2b), because the conventional TCP sender would transmit two
	segments after one round-trip has elapsed since the RTO. If sending		segments when the first new ACK arrives after the RTO. If sending new
	new data is not possible in algorithm branch (2b), or the receiver		data is not possible in algorithm branch (2b), or the receiver window
	window limits the transmission, it has to send something in order to		limits the transmission, the TCP sender has to send something in
	prevent the TCP transfer from stalling. In that case the following		order to prevent the TCP transfer from stalling. If no segments were
	options are available for the sender.		sent, the pipe between sender and receiver may run out of segments,
			and no further acknowledgements arrive. If transmitting previously
			unsent data is not possible, the following options are available for
			the sender.
	- Continue with the conventional RTO recovery algorithm and do not		- Continue with the conventional RTO recovery algorithm and do not
	try to detect the spurious RTO. The disadvantage is that the sender		try to detect the spurious RTO. The disadvantage is that the sender
	may do unnecessary retransmissions due to possible spurious RTO. On		may do unnecessary retransmissions due to possible spurious RTO. On
	the other hand, we believe that the benefits of detecting spurious		the other hand, we believe that the benefits of detecting spurious
	RTO in an application limited or receiver limited situations are		RTO in an application limited or receiver limited situations are
	not very remarkable.		not very remarkable.
	- Use additional information if available, e.g. TCP timestamps with		- Use additional information if available, e.g. TCP timestamps with
	the Eifel Detection algorithm, for detecting a spurious RTO.		the Eifel Detection algorithm, for detecting a spurious RTO.
	However, Eifel detection may yield different results from F-RTO		However, Eifel detection may yield different results from F-RTO
	when ACK losses and a RTO occur within the same round-trip time		when ACK losses and a RTO occur within the same round-trip time
	[SKR02].		[SKR03].
	- Retransmit data from the tail of the retransmission queue and		- Retransmit data from the tail of the retransmission queue and
	continue with step 3 of the F-RTO algorithm. It is possible that		continue with step 3 of the F-RTO algorithm. It is possible that
	the retransmission is unnecessarily made, hence this option is not		the retransmission is unnecessarily made, hence this option is not
	encouraged, except for hosts that are known to operate in an		encouraged, except for hosts that are known to operate in an
	environment that is highly likely to have spurious RTOs. On the		environment that is highly likely to have spurious RTOs. On the
	other hand, with this method it is possible to avoid several		other hand, with this method it is possible to avoid several
	unnecessary retransmissions due to spurious RTO by doing only one		unnecessary retransmissions due to spurious RTO by doing only one
	retransmission that may be unnecessary.		retransmission that may be unnecessary.
	skipping to change at page 6, line 43		skipping to change at page 7, line 14
	from the incoming acknowledgement whether the RTO was spurious.		from the incoming acknowledgement whether the RTO was spurious.
	While this method does not send data unnecessarily, it delays the		While this method does not send data unnecessarily, it delays the
	recovery by one round-trip time in cases where the RTO was not		recovery by one round-trip time in cases where the RTO was not
	spurious, and therefore is not encouraged.		spurious, and therefore is not encouraged.
	- In receiver-limited cases, send one octet of new data regardless of		- In receiver-limited cases, send one octet of new data regardless of
	the advertised window limit, and continue with step 3 of the F-RTO		the advertised window limit, and continue with step 3 of the F-RTO
	algorithm. It is possible that the receiver has free buffer space		algorithm. It is possible that the receiver has free buffer space
	to receive the data by the time the segment has propagated through		to receive the data by the time the segment has propagated through
	the network, in which case no harm is done. If the receiver is not		the network, in which case no harm is done. If the receiver is not
	capable of receiving the segment, it rejects the segment, and sends		capable of receiving the segment, it rejects the segment and sends
	a duplicate ACK.		a duplicate ACK.
	If the RTO is declared spurious, the TCP sender sets the value of		If the RTO is declared spurious, the TCP sender sets the value of
	send_high variable to SND.UNA in order to disable the NewReno		send_high variable to SND.UNA in order to disable the NewReno
	"bugfix" [FH99]. The send_high variable was proposed for avoiding		"bugfix" [FH99]. The send_high variable was proposed for avoiding
	unnecessary multiple fast retransmits when RTO expires during fast		unnecessary multiple fast retransmits when RTO expires during fast
	recovery with NewReno TCP. As the sender has not retransmitted other		recovery with NewReno TCP. As the sender has not retransmitted other
	segments but the one that triggered RTO, the problem addressed by the		segments but the one that triggered RTO, the problem addressed by the
	bugfix cannot occur. Therefore, if there are three duplicate ACKs		bugfix cannot occur. Therefore, if there are three duplicate ACKs
	arriving at the sender after the RTO, they are likely to indicate a		arriving at the sender after the RTO, they are likely to indicate a
	skipping to change at page 7, line 27		skipping to change at page 7, line 46
	Eifel detection algorithm has a similar property, while the DSACK		Eifel detection algorithm has a similar property, while the DSACK
	option can be used to detect whether the retransmitted segment was		option can be used to detect whether the retransmitted segment was
	successfully delivered to the receiver.		successfully delivered to the receiver.
	The F-RTO algorithm has a side-effect on the TCP round-trip time		The F-RTO algorithm has a side-effect on the TCP round-trip time
	measurement. Because the TCP sender can avoid most of the unnecessary		measurement. Because the TCP sender can avoid most of the unnecessary
	retransmissions after detecting a spurious RTO, the sender is able to		retransmissions after detecting a spurious RTO, the sender is able to
	take round-trip time samples on the delayed segments. If the regular		take round-trip time samples on the delayed segments. If the regular
	RTO recovery was used without TCP timestamps, this would not be		RTO recovery was used without TCP timestamps, this would not be
	possible due to retransmission ambiguity. As a result, the RTO		possible due to retransmission ambiguity. As a result, the RTO
	estimator is likely have more accurate and larger values with F-RTO		estimator is likely to be more accurate and have larger values with
	than with the regular TCP after a spurious RTO that was triggered due		F-RTO than with the regular TCP after a spurious RTO that was
	to delayed segments. We believe this is an advantage in the networks		triggered due to delayed segments. We believe this is an advantage in
	that are prone to delay spikes.		the networks that are prone to delay spikes.
	It is possible that the F-RTO algorithm does not always avoid		It is possible that the F-RTO algorithm does not always avoid
	unnecessary retransmissions after a spurious RTO. If packet		unnecessary retransmissions after a spurious RTO. If packet
	reordering or packet duplication occurs on the segment that triggered		reordering or packet duplication occurs on the segment that triggered
	the spurious RTO, the F-RTO algorithm may not detect the spurious RTO		the spurious RTO, the F-RTO algorithm may not detect the spurious RTO
	due to incoming duplicate ACKs. Additionally, if a spurious RTO		due to incoming duplicate ACKs. Additionally, if a spurious RTO
	occurs during fast recovery, the F-RTO algorithm often cannot detect		occurs during fast recovery, the F-RTO algorithm often cannot detect
	the spurious RTO. However, we consider these cases relatively rare,		the spurious RTO. However, we consider these cases relatively rare,
	and note that in cases where F-RTO fails to detect the spurious RTO,		and note that in cases where F-RTO fails to detect the spurious RTO,
	it performs similarly to the regular RTO recovery.		it performs similarly to the regular RTO recovery.
	skipping to change at page 9, line 21		skipping to change at page 9, line 39
	those segments SHOULD be retransmitted similarly to the conventional		those segments SHOULD be retransmitted similarly to the conventional
	SACK recovery algorithm [BAFW03]. If the algorithm exits with		SACK recovery algorithm [BAFW03]. If the algorithm exits with
	SpuriousRecovery set to SPUR_TO, send_high SHOULD be set to SND.UNA,		SpuriousRecovery set to SPUR_TO, send_high SHOULD be set to SND.UNA,
	thus allowing fast recovery on incoming duplicate acknowledgements.		thus allowing fast recovery on incoming duplicate acknowledgements.
	4. Taking Actions after Detecting Spurious RTO		4. Taking Actions after Detecting Spurious RTO
	Upon retransmission timeout, a conventional TCP sender assumes that		Upon retransmission timeout, a conventional TCP sender assumes that
	outstanding segments are lost and starts retransmitting the		outstanding segments are lost and starts retransmitting the
	unacknowledged segments. When the RTO is detected to be spurious, the		unacknowledged segments. When the RTO is detected to be spurious, the
	TCP sender should not start retransmitting based on the RTO. For		TCP sender should not continue retransmitting based on the RTO. For
	example, if the sender was in congestion avoidance phase transmitting		example, if the sender was in congestion avoidance phase transmitting
	new previously unsent segments, it should continue transmitting		new previously unsent segments, it should continue transmitting
	previously unsent segments after detecting spurious RTO. In addition,		previously unsent segments after detecting spurious RTO. In addition,
	it is suggested that the RTO estimation is reinitialized and the RTO		it is suggested that the RTO estimation is reinitialized and the RTO
	timer is adjusted to a more conservative value in order to avoid		timer is adjusted to a more conservative value in order to avoid
	subsequent spurious RTOs [LG03].		subsequent spurious RTOs [LG03].
	Different approaches have been suggested for adjusting the congestion		Different approaches have been discussed for adjusting the congestion
	control state after a spurious RTO. This document does not		control state after a spurious RTO in various research papers [SKR03,
	specifically recommend any of the alternatives below, but considers		GL03, Sar03] and Internet-Drafts [SL03, LG03]. The different response
	the response to spurious RTO as a subject of further research.		suggestions vary in whether the spurious retransmission timeout
			should be taken as a congestion signal, thus causing the congestion
	1) Revert the congestion control parameters to the state before the		window or slow start threshold to be reduced at the sender, or
	RTO [LG03]. This appears to be a justified decision, because it is		whether the congestion control state should be fully reverted to the
	similar to the situation in which the RTO did not expire		state valid prior to the retransmission timeout.
	spuriously. However, two concerns exists with this approach:
	First, some detection mechanisms, such as F-RTO or the Eifel
	Detection algorithm, do not notice the loss of the spurious
	retransmission, thus introducing a small risk of violation of the
	congestion control principles. Second, a spurious RTO indicates
	that some part of the network was unable to deliver packets for a
	while, which can be considered as a potential indication of
	congestion.
	2) Reduce congestion window to half of its earlier value but revert
	slow start threshold to its earlier value [SL03]. This
	alternative takes measures to validate the congestion window after
	a period during which no data has been transmitted. This would be
	a justified action to take if the spurious RTO is assumed to be
	caused due to changes in the network conditions, such as a change
	in the available bandwidth or a wireless handoff to another point
	of attachment in the network.
	3) Reduce ssthresh and congestion window when detecting a spurious		This document does not give recommendation on selecting the response
	RTO [SKR02]. For example, ssthresh and cwnd could be set to half		alternative, but considers the response to spurious RTO as a subject
	of their earlier values, as done with the other congestion		of further research.
	notification events. This alternative would be conservative enough
	considering the possibility of not detecting a packet loss of the
	RTO-triggered retransmission, but the TCP sender should avoid
	reducing the congestion window more than once in a round-trip
	time. Furthermore, if a spurious RTO occurs in the beginning of a
	TCP connection, this alternative causes the slow start to be
	canceled, which may sacrifice TCP performance.
	5. SCTP Considerations		5. SCTP Considerations
	The SACK-enhanced F-RTO algorithm can be applied with the SCTP proto-		The basic F-RTO or the SACK-enhanced F-RTO algorithm can be applied
	col. However, SCTP contains features that are not present with TCP		with the SCTP protocol. However, SCTP contains features that are not
	that need to be discussed when applying the F-RTO algorithm.		present with TCP that need to be discussed when applying the F-RTO
			algorithm.
	SCTP association can be multi-homed. The current retransmission pol-		SCTP association can be multi-homed. The current retransmission pol-
	icy states that retransmissions should go to alternative addresses.		icy states that retransmissions should go to alternative addresses.
	If the retransmission was due to spurious RTO caused by a delay		If the retransmission was due to spurious RTO caused by a delay
	spike, it is possible that the acknowledgement for the retransmission		spike, it is possible that the acknowledgement for the retransmission
	arrives back at the sender before the acknowledgements of the origi-		arrives back at the sender before the acknowledgements of the origi-
	nal transmissions arrive. If this happens, a possible loss of the		nal transmissions arrive. If this happens, a possible loss of the
	original transmission of the data chunk that was retransmitted due to		original transmission of the data chunk that was retransmitted due to
	RTO may remain undetected when applying the F-RTO algorithm and there		the spurious RTO may remain undetected when applying the F-RTO algo-
	was a delay spike that triggered the RTO. Because the RTO was caused		rithm. Because the RTO was caused by the delay, and it was spurious
	by the delay, and it was spurious in that respect, a suitable		in that respect, a suitable response is to continue by sending new
	response is to continue by sending new data. However, if the original		data. However, if the original transmission was lost, fully reverting
	transmission was lost, fully reverting the congestion control parame-		the congestion control parameters is too aggressive. Therefore, tak-
	ters is too aggressive. Therefore, taking conservative actions on		ing conservative actions on congestion control is recommended, if the
	congestion control is recommended, if the SCTP association is multi-		SCTP association is multi-homed and retransmissions go to alternative
	homed and retransmissions go to alternative address. The information		address. The information in duplicate TSNs can be then used for
	in duplicate TSNs can be then used for reverting congestion control,		reverting congestion control, if desired [BA02].
	if desired [BA02].
	Note that the forward transmissions made in F-RTO algorithm step (2b)		Note that the forward transmissions made in F-RTO algorithm step (2b)
	should be destined to the primary address, since they are not		should be destined to the primary address, since they are not
	retransmissions.		retransmissions.
	When making a retransmission, a SCTP sender can bundle a number of		When making a retransmission, a SCTP sender can bundle a number of
	unacknowledged data chunks and include them in the same packet. This		unacknowledged data chunks and include them in the same packet. This
	needs to be considered when implementing F-RTO for SCTP. The basic		needs to be considered when implementing F-RTO for SCTP. The basic
	principle of F-RTO still holds: in order to declare the RTO spurious,		principle of F-RTO still holds: in order to declare the RTO spurious,
	the sender must get an acknowledgement for a data chunk that was not		the sender must get an acknowledgement for a data chunk that was not
	retransmitted after the RTO. In other words, acknowledgements of data		retransmitted after the RTO. In other words, acknowledgements of data
	chunks that were bundled in RTO retransmission must not be used for		chunks that were bundled in RTO retransmission must not be used for
	declaring the RTO spurious.		declaring the RTO spurious.
	6. Security Considerations		6. Security Considerations
	The main security threat regarding F-RTO is the possibility of		The main security threat regarding F-RTO is the possibility of a
	receiver misleading the sender to set too large a congestion window		receiver misleading the sender to set too large a congestion window
	after an RTO. There are two possible ways a malicious receiver could		after an RTO. There are two possible ways a malicious receiver could
	trigger a wrong output from the F-RTO algorithm. First, the receiver		trigger a wrong output from the F-RTO algorithm. First, the receiver
	can acknowledge data that it has not received. Second, it can delay		can acknowledge data that it has not received. Second, it can delay
	acknowledgement of a segment it has received earlier, and acknowledge		acknowledgement of a segment it has received earlier, and acknowledge
	the segment after the TCP sender has been deluded to enter algorithm		the segment after the TCP sender has been deluded to enter algorithm
	step 3.		step 3.
	If the receiver acknowledges a segment it has not really received,		If the receiver acknowledges a segment it has not really received,
	the sender can be lead to declare RTO spurious in F-RTO algorithm		the sender can be lead to declare RTO spurious in F-RTO algorithm
	skipping to change at page 12, line 37		skipping to change at page 12, line 33
	[Ste00] R. Stewart, et. al. Stream Control Transmission Protocol.		[Ste00] R. Stewart, et. al. Stream Control Transmission Protocol.
	RFC 2960, October 2000.		RFC 2960, October 2000.
	Informative References		Informative References
	[ABF01] M. Allman, H. Balakrishnan, and S. Floyd. Enhancing TCP's		[ABF01] M. Allman, H. Balakrishnan, and S. Floyd. Enhancing TCP's
	Loss Recovery Using Limited Transmit. RFC 3042, January		Loss Recovery Using Limited Transmit. RFC 3042, January
	2001.		2001.
	[BA02] E. Blanton and M. Allman. On Making TCP more Robust to		[BA02] E. Blanton and M. Allman. On Making TCP more Robust to
	Packet Reordering. ACM Computer Communication Review,		Packet Reordering. ACM SIGCOMM Computer Communication
	32(1), January 2002.		Review, 32(1), January 2002.
	[BBJ92] D. Borman, R. Braden, and V. Jacobson. TCP Extensions for		[BBJ92] D. Borman, R. Braden, and V. Jacobson. TCP Extensions for
	High Performance. RFC 1323, May 1992.		High Performance. RFC 1323, May 1992.
	[FH99] S. Floyd and T. Henderson. The NewReno Modification to		[FH99] S. Floyd and T. Henderson. The NewReno Modification to
	TCP's Fast Recovery Algorithm. RFC 2582, April 1999.		TCP's Fast Recovery Algorithm. RFC 2582, April 1999.
	[FMMP00] S. Floyd, J. Mahdavi, M. Mathis, and M. Podolsky. An Exten-		[FMMP00] S. Floyd, J. Mahdavi, M. Mathis, and M. Podolsky. An Exten-
	sion to the Selective Acknowledgement (SACK) Option to TCP.		sion to the Selective Acknowledgement (SACK) Option to TCP.
	RFC 2883, July 2000.		RFC 2883, July 2000.
	[GL02] A. Gurtov and R. Ludwig. Evaluating the Eifel Algorithm for		[GL02] A. Gurtov and R. Ludwig. Evaluating the Eifel Algorithm for
	TCP in a GPRS Network. In Proc. of European Wireless, Flo-		TCP in a GPRS Network. In Proc. of European Wireless, Flo-
	rence, Italy, February 2002		rence, Italy, February 2002
			[GL03] A. Gurtov and R. Ludwig, Responding to Spurious Timeouts in
			TCP, In Proceedings of IEEE INFOCOM 03, March 2003.
	[LG03] R. Ludwig and A. Gurtov. The Eifel Response Algorithm for		[LG03] R. Ludwig and A. Gurtov. The Eifel Response Algorithm for
	TCP. Internet draft "draft-ietf-tsvwg-tcp-eifel-		TCP. Internet draft "draft-ietf-tsvwg-tcp-eifel-
	response-03.txt". March 2003. Work in progress.		response-04.txt". October 2003. Work in progress.
	[LK00] R. Ludwig and R.H. Katz. The Eifel Algorithm: Making TCP		[LK00] R. Ludwig and R.H. Katz. The Eifel Algorithm: Making TCP
	Robust Against Spurious Retransmissions. ACM Computer Com-		Robust Against Spurious Retransmissions. ACM SIGCOMM Com-
	munication Review, 30(1), January 2000.		puter Communication Review, 30(1), January 2000.
	[LM03] R. Ludwig and M. Meyer. The Eifel Detection Algorithm for		[LM03] R. Ludwig and M. Meyer. The Eifel Detection Algorithm for
	TCP. RFC 3522, April 2003.		TCP. RFC 3522, April 2003.
	[SKR02] P. Sarolahti, M. Kojo, and K. Raatikainen. F-RTO: A New		[SKR03] P. Sarolahti, M. Kojo, and K. Raatikainen. F-RTO: An
	Recovery Algorithm for TCP Retransmission Timeouts. Univer-		Enhanced Recovery Algorithm for TCP Retransmission Time-
	sity of Helsinki, Dept. of Computer Science. Series of Pub-		outs. ACM SIGCOMM Computer Communication Review, 33(2),
	lications C, No. C-2002-07. February 2002. Available at:		April 2003.
	http://www.cs.helsinki.fi/research/iwtcp/papers/f-rto.ps
			[Sar03] P. Sarolahti. Congestion Control on Spurious TCP Retrans-
			mission Timeouts. In Proceedings of IEEE Globecom 2003.
			December 2003.
	[SL03] Y. Swami and K. Le. DCLOR: De-correlated Loss Recovery		[SL03] Y. Swami and K. Le. DCLOR: De-correlated Loss Recovery
	using SACK option for spurious timeouts. Internet draft		using SACK option for spurious timeouts. Internet draft
	"draft-swami-tsvwg-tcp-dclor-01.txt". April 2003. Work in		"draft-swami-tsvwg-tcp-dclor-02.txt". September 2003. Work
	progress.		in progress.
	Appendix A: Scenarios		Appendix A: Scenarios
	This section discusses different scenarios where RTOs occur and how		This section discusses different scenarios where RTOs occur and how
	the basic F-RTO algorithm performs in those scenarios. The		the basic F-RTO algorithm performs in those scenarios. The
	interesting scenarios are a sudden delay triggering RTO, loss of a		interesting scenarios are a sudden delay triggering RTO, loss of a
	retransmitted packet during fast recovery, link outage causing the		retransmitted packet during fast recovery, link outage causing the
	loss of several packets, and packet reordering. A performance		loss of several packets, and packet reordering. A performance
	evaluation with a more thorough analysis on a real implementation of		evaluation with a more thorough analysis on a real implementation of
	F-RTO is given in [SKR02].		F-RTO is given in [SKR03].
	A.1. Sudden delay		A.1. Sudden delay
	The main motivation of F-RTO algorithm is to improve TCP performance		The main motivation of F-RTO algorithm is to improve TCP performance
	when a delay spike triggers a spurious retransmission timeout. The		when a delay spike triggers a spurious retransmission timeout. The
	example below illustrates the segments and acknowledgements		example below illustrates the segments and acknowledgements
	transmitted by the TCP end hosts when a spurious RTO occurs, but no		transmitted by the TCP end hosts when a spurious RTO occurs, but no
	packets are lost. For simplicity, delayed acknowledgements are not		packets are lost. For simplicity, delayed acknowledgements are not
	used in the example. The example below reduces the congestion window		used in the example. The example below reduces the congestion window
	and slow start threshold by half after detecting a spurious RTO.		and slow start threshold by half after detecting a spurious RTO.
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/