draft-ietf-tsvwg-tcp-eifel-response-05.txt		draft-ietf-tsvwg-tcp-eifel-response-06.txt
	Network Working Group Reiner Ludwig		Network Working Group Reiner Ludwig
	INTERNET-DRAFT Ericsson Research		INTERNET-DRAFT Ericsson Research
	Expires: September 2004 Andrei Gurtov		Expires: March 2004 Andrei Gurtov
	TeliaSonera		HIIT
	March, 2004		September, 2004
	The Eifel Response Algorithm for TCP		The Eifel Response Algorithm for TCP
	<draft-ietf-tsvwg-tcp-eifel-response-05.txt>		<draft-ietf-tsvwg-tcp-eifel-response-06.txt>
	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
	Task Force (IETF), its areas, and its working groups. Note that other		Task Force (IETF), its areas, and its working groups. Note that other
	groups may also distribute working documents as Internet-Drafts.		groups may also distribute working documents as Internet-Drafts.
	skipping to change at page 2, line 55		skipping to change at page 2, line 55
	We use the TCP sender state variable 'T_last', and the term 'tcpnow'		We use the TCP sender state variable 'T_last', and the term 'tcpnow'
	as used in [RFC2861]. T_last holds the time when the TCP sender sent		as used in [RFC2861]. T_last holds the time when the TCP sender sent
	the last data segment while tcpnow is the TCP sender's current		the last data segment while tcpnow is the TCP sender's current
	"system time".		"system time".
	1. Introduction		1. Introduction
	The Eifel response algorithm relies on a detection algorithm such as		The Eifel response algorithm relies on a detection algorithm such as
	the Eifel detection algorithm defined in [RFC3522]. That document		the Eifel detection algorithm defined in [RFC3522]. That document
	discusses the relevant background and motivation that also applies to		contains informative background and motivation context that may be
	this document. Hence, the reader is expected to be familiar with		useful for implementers of the Eifel response algorithm, but it is
	[RFC3522]. Note that alternative response algorithms have been		not necessary to read [RFC3522] in order to implement the Eifel
	proposed [BA02] that could also rely on the Eifel detection		response algorithm. Note that alternative response algorithms have
			been proposed [BA02] that could also rely on the Eifel detection
	algorithm, and vice versa alternative detection algorithms have been		algorithm, and vice versa alternative detection algorithms have been
	proposed [RFC3708], [SK04] that could work together with the Eifel		proposed [RFC3708], [SK04] that could work together with the Eifel
	response algorithm.		response algorithm.
	Based on an appropriate detection algorithm, the Eifel response		Based on an appropriate detection algorithm, the Eifel response
	algorithm provides a way for a TCP sender to respond to a detected		algorithm provides a way for a TCP sender to respond to a detected
	spurious timeout. It adapts the retransmission timer to avoid further		spurious timeout. It adapts the retransmission timer to avoid further
	spurious timeouts, and can avoid - depending on the detection		spurious timeouts, and can avoid - depending on the detection
	algorithm - the often unnecessary go-back-N retransmits that would		algorithm - the often unnecessary go-back-N retransmits that would
	otherwise be sent. In addition, the Eifel response algorithm restores		otherwise be sent. In addition, the Eifel response algorithm restores
	the congestion control state in such a way that packet bursts are		the congestion control state in such a way that packet bursts are
	avoided.		avoided.
	Note: A previous version of the Eifel response algorithm also		Note: A previous version of the Eifel response algorithm also
	included a response to a detected spurious fast retransmit.		included a response to a detected spurious fast retransmit.
	However, since a consensus was not reached about how to adapt the		However, since a consensus was not reached about how to adapt the
	duplicate acknowledgement threshold in that case, that part of the		duplicate acknowledgement threshold in that case, that part of the
	algorithm was removed for the time being.		algorithm was removed for the time being.
	2. Interworking with Detection Algorithms		2. Appropriate Detection Algorithms
	If the Eifel response algorithm is implemented at the TCP sender, it		If the Eifel response algorithm is implemented at the TCP sender, it
	MUST be implemented together with a detection algorithm that is		MUST be implemented together with a detection algorithm that is
	specified in an RFC.		specified in a standards track or experimental RFC.
	Designers of detection algorithms who want their algorithms to work		Designers of detection algorithms who want their algorithms to work
	together with the Eifel response algorithm should reuse the variable		together with the Eifel response algorithm should reuse the variable
	"SpuriousRecovery" with the semantics and defined values specified in		"SpuriousRecovery" with the semantics and defined values specified in
	[RFC3522]. In addition, we define LATE_SPUR_TO (equal -1) as another		[RFC3522]. In addition, we define LATE_SPUR_TO (equal -1) as another
	possible value of the variable SpuriousRecovery. Detection algorithms		possible value of the variable SpuriousRecovery. Detection algorithms
	should set the value of SpuriousRecovery to LATE_SPUR_TO if the		should set the value of SpuriousRecovery to LATE_SPUR_TO if the
	detection of a spurious retransmit is based upon receiving the ACK		detection of a spurious retransmit is based upon receiving the ACK
	for the retransmit (as opposed to an ACK for an original transmit).		for the retransmit (as opposed to an ACK for an original transmit).
	For example, this applies to detection algorithms that are based on		For example, this applies to detection algorithms that are based on
	skipping to change at page 4, line 25		skipping to change at page 4, line 25
	loss recovery is initiated, set a "pipe_prev" variable as		loss recovery is initiated, set a "pipe_prev" variable as
	follows:		follows:
	pipe_prev <- max (FlightSize, ssthresh)		pipe_prev <- max (FlightSize, ssthresh)
	Set a "SRTT_prev" variable and a "RTTVAR_prev" variable as		Set a "SRTT_prev" variable and a "RTTVAR_prev" variable as
	follows:		follows:
	SRTT_prev <- SRTT + (2 * G)		SRTT_prev <- SRTT + (2 * G)
	RTTVAR_prev <- RTTVAR		RTTVAR_prev <- RTTVAR
	(DET) This is a placeholder for a detection algorithm that must		(DET) This is a placeholder for a detection algorithm that must
	be executed at this point. In case [RFC3522] is used as		be executed at this point, and that sets the variable
	the detection algorithm, steps (1) - (6) of that algorithm		SpuriousRecovery as outlined in Section 2. In case
	go here.		[RFC3522] is used as the detection algorithm, steps (1) -
			(6) of that algorithm go here.
	(7) If SpuriousRecovery equals SPUR_TO, then		(7) If SpuriousRecovery equals SPUR_TO, then
	proceed to step (8),		proceed to step (8),
	else if SpuriousRecovery equals LATE_SPUR_TO, then		else if SpuriousRecovery equals LATE_SPUR_TO, then
	proceed to step (9),		proceed to step (9),
	else		else
	proceed to step (DONE).		proceed to step (DONE).
	skipping to change at page 11, line 45		skipping to change at page 11, line 45
	[RFC3708] Blanton, E. and M. Allman, Using TCP Duplicate Selective		[RFC3708] Blanton, E. and M. Allman, Using TCP Duplicate Selective
	Acknowledgements (DSACKs) and SCTP Duplicate Transmission		Acknowledgements (DSACKs) and SCTP Duplicate Transmission
	Sequence Numbers (TSNs) to Detect Spurious Retransmissions,		Sequence Numbers (TSNs) to Detect Spurious Retransmissions,
	RFC 3708, February 2004.		RFC 3708, February 2004.
	[RFC3517] Blanton, E., Allman, M., Fall, K. and L. Wang,		[RFC3517] Blanton, E., Allman, M., Fall, K. and L. Wang,
	A Conservative SACK-based Loss Recovery Algorithm for TCP,		A Conservative SACK-based Loss Recovery Algorithm for TCP,
	RFC3517, April 2003.		RFC3517, April 2003.
	[EL04] Ekström, H. and R. Ludwig, The Peak-Hopper: A New End-to-		[EL04] Ekstr÷m, H. and R. Ludwig, The Peak-Hopper: A New End-to-
	End Retransmission Timer for Reliable Unicast Transport, In		End Retransmission Timer for Reliable Unicast Transport, In
	Proceedings of IEEE INFOCOM 04, March 2004.		Proceedings of IEEE INFOCOM 04, March 2004.
	[RFC2883] Floyd, S., Mahdavi, J., Mathis, M., Podolsky, M. and A.		[RFC2883] Floyd, S., Mahdavi, J., Mathis, M., Podolsky, M. and A.
	Romanow, An Extension to the Selective Acknowledgement		Romanow, An Extension to the Selective Acknowledgement
	(SACK) Option for TCP, RFC 2883, July 2000.		(SACK) Option for TCP, RFC 2883, July 2000.
	[GL02] Gurtov, A. and R. Ludwig, Evaluating the Eifel Algorithm		[GL02] Gurtov, A. and R. Ludwig, Evaluating the Eifel Algorithm
	for TCP in a GPRS Network, In Proceedings of the European		for TCP in a GPRS Network, In Proceedings of the European
	Wireless Conference, February 2002.		Wireless Conference, February 2002.
	skipping to change at page 12, line 25		skipping to change at page 12, line 25
	[KP87] Karn, P. and C. Partridge, Improving Round-Trip Time		[KP87] Karn, P. and C. Partridge, Improving Round-Trip Time
	Estimates in Reliable Transport Protocols, In Proceedings		Estimates in Reliable Transport Protocols, In Proceedings
	of ACM SIGCOMM 87.		of ACM SIGCOMM 87.
	[LK00] Ludwig, R. and R. H. Katz, The Eifel Algorithm: Making TCP		[LK00] Ludwig, R. and R. H. Katz, The Eifel Algorithm: Making TCP
	Robust Against Spurious Retransmissions, ACM Computer		Robust Against Spurious Retransmissions, ACM Computer
	Communication Review, Vol. 30, No. 1, January 2000.		Communication Review, Vol. 30, No. 1, January 2000.
	[SK04] Sarolahti, P. and M. Kojo, F-RTO: An Algorithm for		[SK04] Sarolahti, P. and M. Kojo, F-RTO: An Algorithm for
	Detecting Spurious Retransmission Timeouts with TCP and		Detecting Spurious Retransmission Timeouts with TCP and
	SCTP, work in progress, draft-ietf-tsvwg-tcp-frto-01.txt,		SCTP, work in progress, draft-ietf-tcpm-frto-01.txt,
	February 2004.		July 2004.
	[WS95] Wright, G. R. and W. R. Stevens, TCP/IP Illustrated,		[WS95] Wright, G. R. and W. R. Stevens, TCP/IP Illustrated,
	Volume 2 (The Implementation), Addison Wesley,		Volume 2 (The Implementation), Addison Wesley,
	January 1995.		January 1995.
	[Zh86] Zhang, L., Why TCP Timers Don't Work Well, In Proceedings		[Zh86] Zhang, L., Why TCP Timers Don't Work Well, In Proceedings
	of ACM SIGCOMM 88.		of ACM SIGCOMM 88.
	Author's Address		Author's Address
	Reiner Ludwig		Reiner Ludwig
	Ericsson Research (EED)		Ericsson Research (EED)
	Ericsson Allee 1		Ericsson Allee 1
	52134 Herzogenrath, Germany		52134 Herzogenrath, Germany
	Email: Reiner.Ludwig@ericsson.com		Email: Reiner.Ludwig@ericsson.com
	Andrei Gurtov		Andrei Gurtov
	TeliaSonera Finland		Helsinki Institute for Information Technology (HIIT)
	P.O. Box 970, FIN-00051 Sonera		P.O. Box 9800, FIN-02015
	Helsinki, Finland		HUT, Finland
	Email: andrei.gurtov@teliasonera.com		Email: andrei.gurtov@cs.helsinki.fi
	Homepage: http://www.cs.helsinki.fi/u/gurtov		Homepage: http://www.cs.helsinki.fi/u/gurtov
	This Internet-Draft expires in September 2004.		This Internet-Draft expires in March 2005.
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/