The Eifel Detection Algorithm for TCP
RFC 3522

Document Type RFC - Experimental (April 2003; No errata)
Authors Ludwig Reiner  , Michael Meyer 
Last updated 2013-03-02
Replaces draft-ludwig-tsvwg-tcp-eifel-alg
Stream IETF
Formats plain text html pdf htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 3522 (Experimental)
Consensus Boilerplate Unknown
Telechat date
Responsible AD Scott Bradner
Send notices to <>, <>
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.


   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.


   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

   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
Show full document text