doc: Add RFC documents

1 files changed, 787 insertions, 0 deletions

diff --git a/doc/rfc/rfc3522.txt b/doc/rfc/rfc3522.txt
new file mode 100644
index 0000000..4f48546
--- /dev/null
+++ b/doc/rfc/rfc3522.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+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
+   protocol parameters such as the duplicate acknowledgement threshold
+   [RFC2581], and the RTT estimators [RFC2988].  This is to reduce the
+   risk of falsely triggering TCP's loss recovery again as the
+   connection progresses.  However, such response algorithms are outside
+
+
+
+Ludwig & Meyer                Experimental                      [Page 2]
+
+RFC 3522         The Eifel Detection Algorithm for TCP        April 2003
+
+
+   the scope of this document.  Note: The original proposal, the "Eifel
+   algorithm" [LK00], comprises both a detection and a response
+   algorithm.  This document only defines the detection part.  The
+   response part is defined in [LG03].
+
+   A key feature of the Eifel detection algorithm is that it already
+   detects, upon the first acceptable ACK that arrives during loss
+   recovery, whether a fast retransmit or a timeout was spurious.  This
+   is crucial to be able to avoid the mentioned go-back-N retransmits.
+   Another feature is that the Eifel detection algorithm is fairly
+   robust against the loss of ACKs.
+
+   Also the DSACK option [RFC2883] can be used to detect a posteriori
+   whether a TCP sender has entered loss recovery unnecessarily [BA02].
+   However, the first ACK carrying a DSACK option usually arrives at a
+   TCP sender only after loss recovery has already terminated.  Thus,
+   the DSACK option cannot be used to eliminate the retransmission
+   ambiguity.  Consequently, it cannot be used to avoid the mentioned
+   unnecessary go-back-N retransmits.  Moreover, a DSACK-based detection
+   algorithm is less robust against ACK losses.  A recent proposal based
+   on neither the TCP timestamps nor the DSACK option does not have the
+   limitation of DSACK-based schemes, but only addresses the case of
+   spurious timeouts [SK03].
+
+2. Events that Falsely Trigger TCP Loss Recovery
+
+   The following events may falsely trigger a TCP sender's loss recovery
+   and congestion control algorithms.  This causes a so-called spurious
+   retransmit, and an unnecessary reduction of the TCP sender's
+   congestion window and slow start threshold [RFC2581].
+
+      -  Spurious timeout
+
+      -  Packet reordering
+
+      -  Packet duplication
+
+   A spurious timeout is a timeout that would not have occurred had the
+   sender "waited longer".  This may be caused by increased delay that
+   suddenly occurs in the data and/or the ACK path.  That in turn might
+   cause an acceptable ACK to arrive too late, i.e., only after a TCP
+   sender's retransmission timer has expired.  For the purpose of
+   specifying the algorithm in Section 3, we define this case as SPUR_TO
+   (equal 1).
+
+      Note: There is another case where a timeout would not have
+      occurred had the sender "waited longer": the retransmission timer
+      expires, and afterwards the TCP sender receives the duplicate ACK
+
+
+
+Ludwig & Meyer                Experimental                      [Page 3]
+
+RFC 3522         The Eifel Detection Algorithm for TCP        April 2003
+
+
+      that would have triggered a fast retransmit of the oldest
+      outstanding segment.  We call this a 'fast timeout', since in
+      competition with the fast retransmit algorithm the timeout was
+      faster.  However, a fast timeout is not spurious since apparently
+      a segment was in fact lost, i.e., loss recovery was initiated
+      rightfully.  In this document, we do not consider fast timeouts.
+
+   Packet reordering in the network may occur because IP [RFC791] does
+   not guarantee in-order delivery of packets.  Additionally, a TCP
+   receiver generates a duplicate ACK for each segment that arrives
+   out-of-order.  This results in a spurious fast retransmit if three or
+   more data segments arrive out-of-order at a TCP receiver, and at
+   least three of the resulting duplicate ACKs arrive at the TCP sender.
+   This assumes that the duplicate acknowledgement threshold is set to
+   three as defined in [RFC2581].
+
+   Packet duplication may occur because a receiving IP does not (cannot)
+   remove packets that have been duplicated in the network.  A TCP
+   receiver in turn also generates a duplicate ACK for each duplicate
+   segment.  As with packet reordering, this results in a spurious fast
+   retransmit if duplication of data segments or ACKs results in three
+   or more duplicate ACKs to arrive at a TCP sender.  Again, this
+   assumes that the duplicate acknowledgement threshold is set to three.
+
+   The negative impact on TCP performance caused by packet reordering
+   and packet duplication is commonly the same: a single spurious
+   retransmit (the fast retransmit), and the unnecessary halving of a
+   TCP sender's congestion window as a result of the subsequent fast
+   recovery phase [RFC2581].
+
+   The negative impact on TCP performance caused by a spurious timeout
+   is more severe.  First, the timeout event itself causes a single
+   spurious retransmit, and unnecessarily forces a TCP sender into slow
+   start [RFC2581].  Then, as the connection progresses, a chain
+   reaction gets triggered that further decreases TCP's performance.
+   Since the timeout was spurious, at least some ACKs for original
+   transmits typically arrive at the TCP sender before the ACK for the
+   retransmit arrives.  (This is unless severe packet reordering
+   coincided with the spurious timeout in such a way that the ACK for
+   the retransmit is the first acceptable ACK to arrive at the TCP
+   sender.)  Those ACKs for original transmits then trigger an implicit
+   go-back-N loss recovery at the TCP sender [LK00].  Assuming that none
+   of the outstanding segments and none of the corresponding ACKs were
+   lost, all outstanding segments get retransmitted unnecessarily.  In
+   fact, during this phase, a TCP sender violates the packet
+   conservation principle [Jac88].  This is because the unnecessary go-
+   back-N retransmits are sent during slow start.  Thus, for each packet
+   that leaves the network and that belongs to the first half of the
+
+
+
+Ludwig & Meyer                Experimental                      [Page 4]
+
+RFC 3522         The Eifel Detection Algorithm for TCP        April 2003
+
+
+   original flight, two useless retransmits are sent into the network.
+   In addition, some TCPs suffer from a spurious fast retransmit.  This
+   is because the unnecessary go-back-N retransmits arrive as duplicates
+   at the TCP receiver, which in turn triggers a series of duplicate
+   ACKs.  Note that this last spurious fast retransmit could be avoided
+   with the careful variant of 'bugfix' [RFC2582].
+
+   More detailed explanations, including TCP trace plots that visualize
+   the effects of spurious timeouts and packet reordering, can be found
+   in the original proposal [LK00].
+
+3. The Eifel Detection Algorithm
+
+3.1 The Idea
+
+   The goal of the Eifel detection algorithm is to allow a TCP sender to
+   detect a posteriori whether it has entered loss recovery
+   unnecessarily.  Furthermore, the TCP sender should be able to make
+   this decision upon the first acceptable ACK that arrives after the
+   timeout-based retransmit or the fast retransmit has been sent.  This
+   in turn requires extra information in ACKs by which the TCP sender
+   can unambiguously distinguish whether that first acceptable ACK was
+   sent in response to the original transmit or the retransmit.  Such
+   extra information is provided by the TCP Timestamps option [RFC1323].
+   Generally speaking, timestamps are monotonously increasing "serial
+   numbers" added into every segment that are then echoed within the
+   corresponding ACKs.  This is exploited by the Eifel detection
+   algorithm in the following way.
+
+   Given that timestamps are enabled for a connection, a TCP sender
+   always stores the timestamp of the retransmit sent in the beginning
+   of loss recovery, i.e., the timestamp of the timeout-based retransmit
+   or the fast retransmit.  If the timestamp of the first acceptable
+   ACK, that arrives after the retransmit was sent, is smaller then the
+   stored timestamp of that retransmit, then that ACK must have been
+   sent in response to an original transmit.  Hence, the TCP sender must
+   have entered loss recovery unnecessarily.
+
+   The fact that the Eifel detection algorithm decides upon the first
+   acceptable ACK is crucial to allow future response algorithms to
+   avoid the unnecessary go-back-N retransmits that typically occur
+   after a spurious timeout.  Also, if loss recovery was entered
+   unnecessarily, a window worth of ACKs are outstanding that all carry
+   a timestamp that is smaller than the stored timestamp of the
+   retransmit.  The arrival of any one of those ACKs is sufficient for
+   the Eifel detection algorithm to work.  Hence, the solution is fairly
+
+
+
+
+
+Ludwig & Meyer                Experimental                      [Page 5]
+
+RFC 3522         The Eifel Detection Algorithm for TCP        April 2003
+
+
+   robust against ACK losses.  Even the ACK sent in response to the
+   retransmit, i.e., the one that carries the stored timestamp, may get
+   lost without compromising the algorithm.
+
+3.2 The Algorithm
+
+   Given that the TCP Timestamps option [RFC1323] is enabled for a
+   connection, a TCP sender MAY use the Eifel detection algorithm as
+   defined in this subsection.
+
+   If the Eifel detection algorithm is used, the following steps MUST be
+   taken by a TCP sender, but only upon initiation of loss recovery,
+   i.e., when either the timeout-based retransmit or the fast retransmit
+   is sent.  The Eifel detection algorithm MUST NOT be reinitiated after
+   loss recovery has already started.  In particular, it must not be
+   reinitiated upon subsequent timeouts for the same segment, and not
+   upon retransmitting segments other than the oldest outstanding
+   segment, e.g., during selective loss recovery.
+
+      (1)     Set a "SpuriousRecovery" variable to FALSE (equal 0).
+
+      (2)     Set a "RetransmitTS" variable to the value of the
+              Timestamp Value field of the Timestamps option included in
+              the retransmit sent when loss recovery is initiated.  A
+              TCP sender must ensure that RetransmitTS does not get
+              overwritten as loss recovery progresses, e.g., in case of
+              a second timeout and subsequent second retransmit of the
+              same octet.
+
+      (3)     Wait for the arrival of an acceptable ACK.  When an
+              acceptable ACK has arrived, proceed to step (4).
+
+      (4)     If the value of the Timestamp Echo Reply field of the
+              acceptable ACK's Timestamps option is smaller than the
+              value of RetransmitTS, then proceed to step (5),
+
+              else proceed to step (DONE).
+
+      (5)     If the acceptable ACK carries a DSACK option [RFC2883],
+              then proceed to step (DONE),
+
+              else if during the lifetime of the TCP connection the TCP
+              sender has previously received an ACK with a DSACK option,
+              or the acceptable ACK does not acknowledge all outstanding
+              data, then proceed to step (6),
+
+              else proceed to step (DONE).
+
+
+
+
+Ludwig & Meyer                Experimental                      [Page 6]
+
+RFC 3522         The Eifel Detection Algorithm for TCP        April 2003
+
+
+      (6)     If the loss recovery has been initiated with a timeout-
+              based retransmit, then set
+                  SpuriousRecovery <- SPUR_TO (equal 1),
+
+              else set
+                  SpuriousRecovery <- dupacks+1
+
+      (RESP)  Do nothing (Placeholder for a response algorithm).
+
+      (DONE)  No further processing.
+
+   The comparison "smaller than" in step (4) is conservative.  In
+   theory, if the timestamp clock is slow or the network is fast,
+   RetransmitTS could at most be equal to the timestamp echoed by an ACK
+   sent in response to an original transmit.  In that case, it is
+   assumed that the loss recovery was not falsely triggered.
+
+   Note that the condition "if during the lifetime of the TCP connection
+   the TCP sender has previously received an ACK with a DSACK option" in
+   step (5) would be true in case the TCP receiver would signal in the
+   SYN that it is DSACK-enabled.  But unfortunately, this is not
+   required by [RFC2883].
+
+3.3 A Corner Case: "Timeout due to loss of all ACKs" (step 5)
+
+   Even though the oldest outstanding segment arrived at a TCP receiver,
+   the TCP sender is forced into a timeout if all ACKs are lost.
+   Although the resulting retransmit is unnecessary, such a timeout is
+   unavoidable.  It should therefore not be considered spurious.
+   Moreover, the subsequent reduction of the congestion window is an
+   appropriate response to the potentially heavy congestion in the ACK
+   path.  The original proposal [LK00] does not handle this case well.
+   It effectively disables this implicit form of congestion control for
+   the ACK path, which otherwise does not exist in TCP.  This problem is
+   fixed by step (5) of the Eifel detection algorithm as explained in
+   the remainder of this section.
+
+   If all ACKs are lost while the oldest outstanding segment arrived at
+   the TCP receiver, the retransmit arrives as a duplicate.  In response
+   to duplicates, RFC 1323 mandates that the timestamp of the last
+   segment that arrived in-sequence should be echoed.  That timestamp is
+   carried by the first acceptable ACK that arrives at the TCP sender
+   after loss recovery was entered, and is commonly smaller than the
+   timestamp carried by the retransmit.  Consequently, the Eifel
+   detection algorithm misinterprets such a timeout as being spurious,
+   unless the TCP receiver is DSACK-enabled [RFC2883].  In that case,
+   the acceptable ACK carries a DSACK option, and the Eifel algorithm is
+   terminated through the first part of step (5).
+
+
+
+Ludwig & Meyer                Experimental                      [Page 7]
+
+RFC 3522         The Eifel Detection Algorithm for TCP        April 2003
+
+
+      Note: Not all TCP implementations strictly follow RFC 1323.  In
+      response to a duplicate data segment, some TCP receivers echo the
+      timestamp of the duplicate.  With such TCP receivers, the corner
+      case discussed in this section does not apply.  The timestamp
+      carried by the retransmit would be echoed in the first acceptable
+      ACK, and the Eifel detection algorithm would be terminated through
+      step (4).  Thus, even though all ACKs were lost and independent of
+      whether the DSACK option was enabled for a connection, the Eifel
+      detection algorithm would have no effect.
+
+   With TCP receivers that are not DSACK-enabled, disabling the
+   mentioned implicit congestion control for the ACK path is not a
+   problem as long as data segments are lost, in addition to the entire
+   flight of ACKs.  The Eifel detection algorithm misinterprets such a
+   timeout as being spurious, and the Eifel response algorithm would
+   reverse the congestion control state.  Still, the TCP sender would
+   respond to congestion (in the data path) as soon as it finds out
+   about the first loss in the outstanding flight.  I.e., the TCP sender
+   would still halve its congestion window for that flight of packets.
+   If no data segment is lost while the entire flight of ACKs is lost,
+   the first acceptable ACK that arrives at the TCP sender after loss
+   recovery was entered acknowledges all outstanding data.  In that
+   case, the Eifel algorithm is terminated through the second part of
+   step (5).
+
+   Note that there is little concern about violating the packet
+   conservation principle when entering slow start after an unavoidable
+   timeout caused by the loss of an entire flight of ACKs, i.e., when
+   the Eifel detection algorithm was terminated through step (5).  This
+   is because in that case, the acceptable ACK corresponds to the
+   retransmit, which is a strong indication that the pipe has drained
+   entirely, i.e., that no more original transmits are in the network.
+   This is different with spurious timeouts as discussed in Section 2.
+
+3.4 Protecting Against Misbehaving TCP Receivers (the Safe Variant)
+
+   A TCP receiver can easily make a genuine retransmit appear to the TCP
+   sender as a spurious retransmit by forging echoed timestamps.  This
+   may pose a security concern.
+
+   Fortunately, there is a way to modify the Eifel detection algorithm
+   in a way that makes it robust against lying TCP receivers.  The idea
+   is to use timestamps as a segment's "secret" that a TCP receiver only
+   gets to know if it receives the segment.  Conversely, a TCP receiver
+   will not know the timestamp of a segment that was lost.  Hence, to
+   "prove" that it received the original transmit of a segment that a
+   TCP sender retransmitted, the TCP receiver would need to return the
+   timestamp of that original transmit.  The Eifel detection algorithm
+
+
+
+Ludwig & Meyer                Experimental                      [Page 8]
+
+RFC 3522         The Eifel Detection Algorithm for TCP        April 2003
+
+
+   could then be modified to only decide that loss recovery has been
+   unnecessarily entered if the first acceptable ACK echoes the
+   timestamp of the original transmit.
+
+   Hence, implementers may choose to implement the algorithm with the
+   following modifications.
+
+   Step (2) is replaced with step (2'):
+
+      (2')    Set a "RetransmitTS" variable to the value of the
+              Timestamp Value field of the Timestamps option that was
+              included in the original transmit corresponding to the
+              retransmit.  Note: This step requires that the TCP sender
+              stores the timestamps of all outstanding original
+              transmits.
+
+   Step (4) is replaced with step (4'):
+
+      (4')    If the value of the Timestamp Echo Reply field of the
+              acceptable ACK's Timestamps option is equal to the value
+              of the variable RetransmitTS, then proceed to step (5),
+
+              else proceed to step (DONE).
+
+   These modifications come at a cost: the modified algorithm is fairly
+   sensitive against ACK losses since it relies on the arrival of the
+   acceptable ACK that corresponds to the original transmit.
+
+      Note: The first acceptable ACK that arrives after loss recovery
+      has been unnecessarily entered should echo the timestamp of the
+      original transmit.  This assumes that the ACK corresponding to the
+      original transmit was not lost, that that ACK was not reordered in
+      the network, and that the TCP receiver does not forge timestamps
+      but complies with RFC 1323.  In case of a spurious fast
+      retransmit, this is implied by the rules for generating ACKs for
+      data segments that fill in all or part of a gap in the sequence
+      space (see section 4.2 of [RFC2581]) and by the rules for echoing
+      timestamps in that case (see rule (C) in section 3.4 of
+      [RFC1323]).  In case of a spurious timeout, it is likely that the
+      delay that has caused the spurious timeout has also caused the TCP
+      receiver's delayed ACK timer [RFC1122] to expire before the
+      original transmit arrives.  Also, in this case the rules for
+      generating ACKs and the rules for echoing timestamps (see rule (A)
+      in section 3.4 of [RFC1323]) ensure that the original transmit's
+      timestamp is echoed.
+
+
+
+
+
+
+Ludwig & Meyer                Experimental                      [Page 9]
+
+RFC 3522         The Eifel Detection Algorithm for TCP        April 2003
+
+
+   A remaining problem is that a TCP receiver might guess a lost
+   segment's timestamp from observing the timestamps of recently
+   received segments.  For example, if segment N was lost while segment
+   N-1 and N+1 have arrived, a TCP receiver could guess the timestamp
+   that lies in the middle of the timestamps of segments N-1 and N+1,
+   and echo it in the ACK sent in response to the retransmit of segment
+   N.  Especially if the TCP sender implements timestamps with a coarse
+   granularity, a misbehaving TCP receiver is likely to be successful
+   with such an approach.  In fact, with the 500 ms granularity
+   suggested in [WS95], it even becomes quite likely that the timestamps
+   of segments N-1, N, N+1 are identical.
+
+   One way to reduce this risk is to implement fine grained timestamps.
+   Note that the granularity of the timestamps is independent of the
+   granularity of the retransmission timer.  For example, some TCP
+   implementations run a timestamp clock that ticks every millisecond.
+   This should make it more difficult for a TCP receiver to guess the
+   timestamp of a lost segment.  Alternatively, it might be possible to
+   combine the timestamps with a nonce, as is done for the Explicit
+   Congestion Notification (ECN) [RFC3168].  One would need to take
+   care, though, that the timestamps of consecutive segments remain
+   monotonously increasing and do not interfere with the RTT timing
+   defined in [RFC1323].
+
+4. IPR Considerations
+
+   The IETF has been notified of intellectual property rights claimed in
+   regard to some or all of the specification contained in this
+   document.  For more information consult the online list of claimed
+   rights at http://www.ietf.org/ipr.
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; neither does it represent that it
+   has made any effort to identify any such rights.  Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11.  Copies of
+   claims of rights made available for publication and any assurances of
+   licenses to be made available, or the result of an attempt made to
+   obtain a general license or permission for the use of such
+   proprietary rights by implementors or users of this specification can
+   be obtained from the IETF Secretariat.
+
+
+
+
+
+
+
+Ludwig & Meyer                Experimental                     [Page 10]
+
+RFC 3522         The Eifel Detection Algorithm for TCP        April 2003
+
+
+5. Security Considerations
+
+   There do not seem to be any security considerations associated with
+   the Eifel detection algorithm.  This is because the Eifel detection
+   algorithm does not alter the existing protocol state at a TCP sender.
+   Note that the Eifel detection algorithm only requires changes to the
+   implementation of a TCP sender.
+
+   Moreover, a variant of the Eifel detection algorithm has been
+   proposed in Section 3.4 that makes it robust against lying TCP
+   receivers.  This may become relevant when the Eifel detection
+   algorithm is combined with a response algorithm such as the Eifel
+   response algorithm [LG03].
+
+Acknowledgments
+
+   Many thanks to Keith Sklower, Randy Katz, Stephan Baucke, Sally
+   Floyd, Vern Paxson, Mark Allman, Ethan Blanton, Andrei Gurtov, Pasi
+   Sarolahti, and Alexey Kuznetsov for useful discussions that
+   contributed to this work.
+
+Normative References
+
+   [RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion
+             Control", RFC 2581, April 1999.
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2883] Floyd, S., Mahdavi, J., Mathis, M., Podolsky, M. and A.
+             Romanow, "An Extension to the Selective Acknowledgement
+             (SACK) Option for TCP", RFC 2883, July 2000.
+
+   [RFC1323] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for
+             High Performance", RFC 1323, May 1992.
+
+   [RFC2018] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP
+             Selective Acknowledgement Options", RFC 2018, October 1996.
+
+   [RFC793]  Postel, J., "Transmission Control Protocol", STD 7, RFC
+             793, September 1981.
+
+
+
+
+
+
+
+
+
+
+Ludwig & Meyer                Experimental                     [Page 11]
+
+RFC 3522         The Eifel Detection Algorithm for TCP        April 2003
+
+
+Informative References
+
+   [BA02]    Blanton, E. and M. Allman, "Using TCP DSACKs and SCTP
+             Duplicate TSNs to Detect Spurious Retransmissions", Work in
+             Progress.
+
+   [RFC1122] Braden, R., "Requirements for Internet Hosts -
+             Communication Layers", STD 3, RFC 1122, October 1989.
+
+   [RFC2582] Floyd, S. and T. Henderson, "The NewReno Modification to
+             TCP's Fast Recovery Algorithm", RFC 2582, April 1999.
+
+   [Gu01]    Gurtov, A., "Effect of Delays on TCP Performance", In
+             Proceedings of IFIP Personal Wireless Communications,
+             August 2001.
+
+   [RFC3481] Inamura, H., Montenegro, G., Ludwig, R., Gurtov, A. and F.
+             Khafizov, "TCP over Second (2.5G) and Third (3G) Generation
+             Wireless Networks", RFC 3481, February 2003.
+
+   [Jac88]   Jacobson, V., "Congestion Avoidance and Control", In
+             Proceedings of ACM SIGCOMM 88.
+
+   [KP87]    Karn, P. and C. Partridge, "Improving Round-Trip Time
+             Estimates in Reliable Transport Protocols", In Proceedings
+             of ACM SIGCOMM 87.
+
+   [LK00]    Ludwig, R. and R. H. Katz, "The Eifel Algorithm: Making TCP
+             Robust Against Spurious Retransmissions", ACM Computer
+             Communication Review, Vol. 30, No. 1, January 2000.
+
+   [LG03]    Ludwig, R. and A. Gurtov, "The Eifel Response Algorithm for
+             TCP", Work in Progress.
+
+   [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission
+             Timer", RFC 2988, November 2000.
+
+   [RFC791]  Postel, J., "Internet Protocol", STD 5, RFC 791, September
+             1981.
+
+   [RFC3168] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of
+             Explicit Congestion Notification (ECN) to IP", RFC 3168,
+             September 2001.
+
+   [SK03]    Sarolahti, P. and M. Kojo, "F-RTO: A TCP RTO Recovery
+             Algorithm for Avoiding Unnecessary Retransmissions", Work
+             in Progress.
+
+
+
+
+Ludwig & Meyer                Experimental                     [Page 12]
+
+RFC 3522         The Eifel Detection Algorithm for TCP        April 2003
+
+
+   [WS95]    Wright, G. R. and W. R. Stevens, "TCP/IP Illustrated,
+             Volume 2 (The Implementation)", Addison Wesley, January
+             1995.
+
+   [Zh86]    Zhang, L., "Why TCP Timers Don't Work Well", In Proceedings
+             of ACM SIGCOMM 86.
+
+Authors' Addresses
+
+   Reiner Ludwig
+   Ericsson Research
+   Ericsson Allee 1
+   52134 Herzogenrath, Germany
+
+   EMail: Reiner.Ludwig@eed.ericsson.se
+
+
+   Michael Meyer
+   Ericsson Research
+   Ericsson Allee 1
+   52134 Herzogenrath, Germany
+
+   EMail: Michael.Meyer@eed.ericsson.se
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ludwig & Meyer                Experimental                     [Page 13]
+
+RFC 3522         The Eifel Detection Algorithm for TCP        April 2003
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ludwig & Meyer                Experimental                     [Page 14]
+