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] Ekstrm, H. and R. Ludwig, The Peak-Hopper: A New End-to- [EL04] Ekstrm, 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/