Network Working Group R. Ludwig
Request for Comments: 3522 M. Meyer
Category: Experimental Ericsson Research
April 2003
The Eifel Detection Algorithm for TCP
Status of this Memo
This memo defines an Experimental Protocol for the Internet
community. It does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
The Eifel detection algorithm allows a TCP sender to detect a
posteriori whether it has entered loss recovery unnecessarily. It
requires that the TCP Timestamps option defined in RFC 1323 be
enabled for a connection. The Eifel detection algorithm makes use of
the fact that the TCP Timestamps option eliminates the retransmission
ambiguity in TCP. Based on the timestamp of the first acceptable ACK
that arrives during loss recovery, it decides whether loss recovery
was entered unnecessarily. The Eifel detection algorithm provides a
basis for future TCP enhancements. This includes response algorithms
to back out of loss recovery by restoring a TCP sender's congestion
control state.
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].
We refer to the first-time transmission of an octet as the 'original
transmit'. A subsequent transmission of the same octet is referred
to as a 'retransmit'. In most cases, this terminology can likewise
be applied to data segments as opposed to octets. However, with
repacketization, a segment can contain both first-time transmissions
and retransmissions of octets. In that case, this terminology is
only consistent when applied to octets. For the Eifel detection
algorithm, this makes no difference as it also operates correctly
when repacketization occurs.
Ludwig & Meyer Experimental [Page 1]RFC 3522 The Eifel Detection Algorithm for TCP April 2003
We use the term 'acceptable ACK' as defined in [RFC793]. That is an
ACK that acknowledges previously unacknowledged data. We use the
term 'duplicate ACK', and the variable 'dupacks' as defined in
[WS95]. The variable 'dupacks' is a counter of duplicate ACKs that
have already been received by a TCP sender before the fast retransmit
is sent. We use the variable 'DupThresh' to refer to the so-called
duplicate acknowledgement threshold, i.e., the number of duplicate
ACKs that need to arrive at a TCP sender to trigger a fast
retransmit. Currently, DupThresh is specified as a fixed value of
three [RFC2581]. Future TCPs might implement an adaptive DupThresh.
1. Introduction
The retransmission ambiguity problem [Zh86], [KP87] is a TCP sender's
inability to distinguish whether the first acceptable ACK that
arrives after a retransmit was sent in response to the original
transmit or the retransmit. This problem occurs after a timeout-
based retransmit and after a fast retransmit. The Eifel detection
algorithm uses the TCP Timestamps option defined in [RFC1323] to
eliminate the retransmission ambiguity. It thereby allows a TCP
sender to detect a posteriori whether it has entered loss recovery
unnecessarily.
This added capability of a TCP sender is useful in environments where
TCP's loss recovery and congestion control algorithms may often get
falsely triggered. This can be caused by packet reordering, packet
duplication, or a sudden delay increase in the data or the ACK path
that results in a spurious timeout. For example, such sudden delay
increases can often occur in wide-area wireless access networks due
to handovers, resource preemption due to higher priority traffic
(e.g., voice), or because the mobile transmitter traverses through a
radio coverage hole (e.g., see [Gu01]). In such wireless networks,
the often unnecessary go-back-N retransmits that typically occur
after a spurious timeout create a serious problem. They decrease
end-to-end throughput, are useless load upon the network, and waste
transmission (battery) power. Note that across such networks the use
of timestamps is recommended anyway [RFC3481].
Based on the Eifel detection algorithm, a TCP sender may then choose
to implement dedicated response algorithms. One goal of such a
response algorithm would be to alleviate the consequences of a
falsely triggered loss recovery. This may include restoring the TCP
sender's congestion control state, and avoiding the mentioned
unnecessary go-back-N retransmits. Another goal would be to adapt