The Eifel Response Algorithm for TCP
RFC 4015

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 06

Network Working Group                                          R. Ludwig
Request for Comments: 4015                             Ericsson Research
Category: Standards Track                                      A. Gurtov
                                                                    HIIT
                                                           February 2005

                  The Eifel Response Algorithm for TCP

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   Based on an appropriate detection algorithm, the Eifel response
   algorithm provides a way for a TCP sender to respond to a detected
   spurious timeout.  It adapts the retransmission timer to avoid
   further spurious timeouts and (depending on the detection algorithm)
   can avoid the often unnecessary go-back-N retransmits that would
   otherwise be sent.  In addition, the Eifel response algorithm
   restores the congestion control state in such a way that packet
   bursts are avoided.

1.  Introduction

   The Eifel response algorithm relies on a detection algorithm such as
   the Eifel detection algorithm, defined in [RFC3522].  That document
   contains informative background and motivation context that may be
   useful for implementers of the Eifel response algorithm, but it is
   not necessary to read [RFC3522] in order to implement the Eifel
   response algorithm.  Note that alternative response algorithms have
   been proposed [BA02] that could also rely on the Eifel detection
   algorithm, and alternative detection algorithms have been proposed
   [RFC3708], [SK04] that could work together with the Eifel response
   algorithm.

   Based on an appropriate detection algorithm, the Eifel response
   algorithm provides a way for a TCP sender to respond to a detected
   spurious timeout.  It adapts the retransmission timer to avoid

Ludwig & Gurtov             Standards Track                     [Page 1]
RFC 4015          The Eifel Response Algorithm for TCP     February 2005

   further spurious timeouts and (depending on the detection algorithm)
   can avoid the often unnecessary go-back-N retransmits that would
   otherwise be sent.  In addition, the Eifel response algorithm
   restores the congestion control state in such a way that packet
   bursts are avoided.

      Note: A previous version of the Eifel response algorithm also
      included a response to a detected spurious fast retransmit.
      However, as a consensus was not reached about how to adapt the
      duplicate acknowledgement threshold in that case, that part of the
      algorithm was removed for the time being.

1.1.  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 also be
   applied to data segments.  However, when repacketization occurs, 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 and response algorithms,
   this makes no difference, as they also operate correctly when
   repacketization occurs.

   We use the term 'acceptable ACK' as defined in [RFC793].  That is an
   ACK that acknowledges previously unacknowledged data.  We use the
   term 'bytes_acked' to refer to the amount (in terms of octets) of
   previously unacknowledged data that is acknowledged by the most
   recently received acceptable ACK.  We use the TCP sender state
   variables 'SND.UNA' and 'SND.NXT' as defined in [RFC793].  SND.UNA
   holds the segment sequence number of the oldest outstanding segment.
   SND.NXT holds the segment sequence number of the next segment the TCP
   sender will (re-)transmit.  In addition, we define as 'SND.MAX' the
   segment sequence number of the next original transmit to be sent.
   The definition of SND.MAX is equivalent to the definition of
   'snd_max' in [WS95].

   We use the TCP sender state variables 'cwnd' (congestion window), and
   'ssthresh' (slow-start threshold), and the term 'FlightSize' as
   defined in [RFC2581].  FlightSize is the amount (in terms of octets)
   of outstanding data at a given point in time.  We use the term
   'Initial Window' (IW) as defined in [RFC3390].  The IW is the size of
   the sender's congestion window after the three-way handshake is