[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04

Internet Engineering Task Force                             P. Sarolahti
INTERNET DRAFT                                     Nokia Research Center
File: draft-sarolahti-tsvwg-tcp-frto-01.txt                      M. Kojo
                                                  University of Helsinki
                                                           October, 2002
                                                    Expires: April, 2003

                F-RTO: A TCP RTO Recovery Algorithm for
                  Avoiding Unnecessary Retransmissions

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of [RFC2026].

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at


   Spurious retransmission timeouts (RTOs) cause suboptimal TCP
   performance, because they often result in unnecessary retransmission
   of the last window of data. This document describes the "Forward RTO
   Recovery" (F-RTO) algorithm for recovering from the TCP RTOs
   efficiently even when the RTO was spurious. F-RTO is a TCP sender
   only algorithm that does not require any TCP options to operate.
   After retransmitting the first unacknowledged segment triggered by an
   RTO, the F-RTO algorithm at a TCP sender monitors the incoming
   acknowledgements to determine whether the timeout was spurious and to
   decide whether to send new segments or retransmit unacknowledged
   segments. The algorithm effectively avoids additional unnecessary
   retransmissions and thereby improves TCP performance in case of a

Expires: April 2003                                             [Page 1]

draft-sarolahti-tsvwg-tcp-frto-01.txt                       October 2002

   spurious timeout.

1.  Introduction

   The TCP protocol [Pos81] has two methods for triggering
   retransmissions.  Primarily, the TCP sender relies on incoming
   duplicate ACKs, which indicate that the receiver is missing some of
   the data. After a required amount of successive duplicate ACKs have
   arrived at the sender, it retransmits the first unacknowledged
   segment [APS99]. Secondarily, the TCP sender maintains a
   retransmission timer which triggers retransmission of segments, if
   they have not been acknowledged within the retransmission timer
   expiration period. When the retransmission timer expires, the
   congestion window is initialized to one segment and unacknowledged
   segments are retransmitted using the slow-start algorithm. The
   retransmission timer is adjusted dynamically based on the measured
   round-trip times [PA00].

   It has been pointed out that the retransmission timer can expire
   spuriously and trigger unnecessary retransmissions when no segments
   have been lost [GL02]. After a spurious RTO the acknowledgements of
   original segments arrive at the sender, usually triggering
   unnecessary retransmissions of whole window of segments during the
   RTO recovery.

   There are a number of potential reasons for spurious RTOs. First,
   some mobile networking technologies involve sudden delay peaks on
   transmission because of actions taken during a hand-off. Second,
   arrival of competing traffic, possibly with higher priority, on a
   low-bandwidth link or some other change in available bandwidth
   involves a sudden increase of round-trip time which may trigger a
   spurious retransmission timeout. A persistently reliable link layer
   can also cause a sudden delay when several data frames are lost for
   some reason. This document does not distinguish the different causes
   of such a delay, but discusses the spurious RTO caused by delay in

   This document describes an alternative algorithm called "Forward RTO-
   Recovery" (F-RTO) to be used for retransmitting segments after an
   RTO. The purpose of the F-RTO algorithm is to avoid most of the
   unnecessary retransmissions following a spurious timeout and thereby
   improve TCP performance. When the RTO is not spurious, the F-RTO
   algorithm reverts back to the conventional RTO recovery algorithm and
   should have similar performance. F-RTO does not require any TCP
   options in its operation, and it can be implemented by modifying only
   the TCP sender. This is different from alternative algorithms (Eifel
   [LK00] and DSACK-based algorithms) that have been suggested for

Expires: April 2003                                             [Page 2]

draft-sarolahti-tsvwg-tcp-frto-01.txt                       October 2002

   detecting unnecessary retransmissions.  The Eifel algorithm uses TCP
   timestamps for detecting a spurious timeout and the DSACK-based
   algorithms require that the SACK option with DSACK extension [FMMP00]
   is in use.

   When a RTO occurs, the F-RTO sender retransmits the first
   unacknowledged segment normally. If the next two acknowledgements
   advance the window, the F-RTO sender continues sending new data and
   exits the recovery.  However, if either of the next two
   acknowledgements is a duplicate ACK, the RTO was likely to be caused
   because of missing data; therefore the F-RTO sender retransmits the
   unacknowledged segments in slow start similarly to the traditional

   The F-RTO algorithm only attempts to avoid unnecessary
   retransmissions after a RTO. Eifel can also be used in avoiding
   unnecessary retransmissions in other events, for example due to
   packet reordering. In addition, F-RTO is not intended to be used for
   deciding whether to revert the congestion control parameters after a
   spurious timeout. However, F-RTO can be used jointly with either
   Eifel or DSACK detection algorithms. In such a case the TCP sender
   may detect unnecessary retransmissions also due to other reasons than
   a spurious RTO and it can use this information to revert the
   congestion control parameters, if so desired.

   This document is organized as follows. Section 2 describes the basic
   F-RTO algorithm. Section 3 outlines an optional enhancement to the F-
   RTO algorithm that takes leverage on the TCP Selective Acknowledgment
   Option [MMFR96]. Section 4 discusses how the F-RTO algorithm performs
   in different scenarios where RTOs typically occur. Section 5
   discusses the issue of reverting the congestion control state after a
   spurious RTO.  Section 6 discusses security considerations.

2.  F-RTO Algorithm

   The basic F-RTO algorithm affects the TCP sender behavior only after
   a retransmission timeout. Otherwise the TCP behavior remains
   unmodified.  This section describes a basic version of the F-RTO
   algorithm that does not require TCP options to work.

   When the retransmission timer expires, the F-RTO algorithm takes the
   following steps at the TCP sender.

   1) When RTO expires, retransmit first unacknowledged segment.

      The TCP sender must adjust ssthresh to max(FlightSize / 2, 2 *

Expires: April 2003                                             [Page 3]

draft-sarolahti-tsvwg-tcp-frto-01.txt                       October 2002

      MSS), according to the TCP congestion control specifications.
      However, congestion window (cwnd) is not yet adjusted, but the TCP
      sender waits for the next incoming acknowledgements before
      deciding on the following actions. Leaving cwnd unadjusted in this
      stage does not cause TCP sender to inject any additional segments
      to the network. The highest sequence number transmitted so far is
      stored in variable "send_high".

   2) When the first acknowledgement after the RTO arrives at the
      sender, the sender chooses the following actions depending on
      whether the ACK advances the window or whether it is a duplicate

      a) If the acknowledgement is a duplicate ACK OR it is
         acknowledging a sequence number equal or above to the value of
         "send_high", revert to the conventional recovery and do not
         enter step 3 of this algorithm.

         The sender must set cwnd to 1 * MSS. This duplicate ACK is
         triggered by a segment that was sent before the retransmission
         triggered by the RTO.  This is possible, for example, if the
         RTO is triggered during fast recovery while forward
         transmissions are triggering duplicate ACKs.  Furthermore, if a
         segment retransmitted during fast recovery is lost, it needs to
         be retransmitted again by retransmission timer. In this case it
         is possible that the duplicate ACK is triggered by a new
         segment transmitted during the fast recovery before the RTO.

      b) If the acknowledgement advances the window AND it is below the
         value of "send_high", transmit two new segments.

         At this point the TCP sender should set cwnd <- ssthresh, thus
         halving the transmission rate. Sending two new segments at this
         point is equally aggressive to the conventional RTO recovery
         algorithm, which would have increased its cwnd to 2 * MSS when
         the first ACK arrives after RTO. It is possible that the sender
         can transmit only one new segment at this time, because the
         receiver window limits it, or because the TCP sender does not
         have more data to send. This does not prevent the algorithm
         from working.

   3) When the second acknowledgement after the RTO arrives at the
      sender, either continue transmitting new data, or start
      retransmitting the unacknowledged segments.

      a) If the acknowledgement is a duplicate ACK, set congestion
         window to 3 * MSS, continue with the slow start algorithm
         retransmitting unacknowledged segments.

Expires: April 2003                                             [Page 4]

draft-sarolahti-tsvwg-tcp-frto-01.txt                       October 2002

         The duplicate ACK indicates that at least one segment other
         than the segment which triggered RTO is lost in the last window
         of data. There is no sufficient evidence that any of the
         segments was delayed. Therefore, the sender proceeds with
         retransmissions similarly to the conventional RTO recovery
         algorithm, with the send_high variable stored when the
         retransmission timer expired to avoid unnecessary fast

      b) If the acknowledgement advances the window, continue
         transmitting new data following the congestion avoidance

         Because the TCP sender has retransmitted only one segment after
         the RTO, this acknowledgement indicates that an originally
         transmitted segment has arrived at the receiver. This is
         regarded as a strong indication of a spurious RTO. However,
         since the TCP sender cannot surely know at this point whether
         the segment that triggered the RTO was actually lost, adjusting
         the congestion control parameters after the RTO is the correct
         action.  From this point on, the TCP sender continues as in the
         normal congestion avoidance.

         If this algorithm branch is taken, the TCP sender ignores the
         send_high variable that indicates the highest sequence number
         transmitted so far [FH99]. The send_high variable was proposed
         as a "bugfix" for avoiding unnecessary multiple fast
         retransmits when RTO expires during fast recovery with NewReno
         TCP. As the sender has not retransmitted other segments but the
         one that triggered RTO, the problem addressed by the bugfix
         cannot occur. Therefore, if there are duplicate ACKs arriving
         at the sender after the RTO, they are likely to indicate a
         packet loss, hence fast retransmit should be used to allow
         efficient recovery.  If there are not enough duplicate ACKs
         arriving at the sender after a packet loss, the retransmission
         timer expires another time and the sender enters step 1 of this

   If the TCP sender does not have any new data to send in algorithm
   branch (2b), or the receiver window limits the transmission, the
   sender reverts back to retransmitting unacknowledged data similarly
   to the regular TCP. The motivation for this is to ensure that the
   flow of segments into the network does not stop. In the worst case
   this would result in additional RTOs significantly degrading the TCP
   performance.  An alternative is to transmit one segment from the tail
   of the retransmission queue, if it is not possible to transmit new
   data in algorithm step (2b). This would make it possible to proceed
   with the F-RTO algorithm.

Expires: April 2003                                             [Page 5]

draft-sarolahti-tsvwg-tcp-frto-01.txt                       October 2002

   When algorithm branch (3b) is taken, the sender does not reduce the
   congestion window to one segment, but halves it to the level of
   ssthresh. Because the sender does not enter slow start, it increases
   congestion window only once in a round-trip time after RTO, and
   therefore is slightly more conservative than the conventional
   recovery algorithm.

   Branch (3b) can also be taken when a retransmission triggered by
   delay is lost. Because loss of the retransmission cannot be detected
   at the sender in this case, we consider that reducing the congestion
   window to half of its previous size is an adequate action at this
   point. A similar action is taken when TCP sender enters fast
   recovery. The DSACK option can be used to detect whether the
   retransmitted segment was sent unnecessarily and possibly revert the
   congestion window to its earlier size in this case. However, fully
   reverting the congestion window may be too aggressive action after
   the spurious RTO, hence the possible adjustment of congestion window
   in this case remains a future research issue.

   The F-RTO algorithm has a side-effect on the TCP round-trip time
   measurement. Because the TCP sender avoids most of the unnecessary
   retransmissions after a spurious RTO, the sender is able to take
   round-trip time samples of the delayed segments. This would not be
   possible due to retransmission ambiguity, if the regular RTO recovery
   is used without TCP timestamps. As a result, the RTO estimator is
   likely have larger values with F-RTO than with the regular TCP after
   the spurious RTO. We believe this is an advantage in the networks
   that are prone to delay spikes.

   It is possible that the F-RTO algorithm does not always avoid
   unnecessary retransmissions after spurious RTO. If packet reordering
   or packet duplication occurs on the segment that triggered the
   spurious RTO, the F-RTO algorithm ends up retransmitting the last
   window of data similarly to the regular TCP. Additionally, if a
   spurious RTO occurs during fast recovery, the F-RTO algorithm may
   cause unnecessary retransmissions just like the regular RTO recovery.
   However, we consider these cases relatively rare, and note that in
   cases where F-RTO fails to avoid the unnecessary retransmissions, it
   performs similarly to the regular RTO recovery.

3.  A SACK-enhanced version of the F-RTO algorithm

   We briefly describe an SACK-enhanced version of the F-RTO algorithm
   for improving the performance in cases where a packet loss or a
   similar event following the spurious RTO causes a wrong action by the
   F-RTO algorithm, as described above.

Expires: April 2003                                             [Page 6]

draft-sarolahti-tsvwg-tcp-frto-01.txt                       October 2002

   The difference to the basic F-RTO algorithm is, that the sender may
   continue sending new data even when duplicate ACKs follow the RTO, if
   the SACK blocks indicate that original, non-retransmitted data
   arrives to the receiver after the RTO.

   The SACK enhancement changes the F-RTO algorithm steps 1-3 as
   follows. The undescribed details remain as in the basic version of
   the F-RTO algorithm:

   1) When RTO expires, retransmit first unacknowledged segment. The
      SACK information received so far has to be remembered over the RTO
      event in order to allow the SACK-enhanced variant of F-RTO to

      Not expunging the SACK information upon a retransmission timeout
      conflicts with recommendations of the SACK specification [MMFR96].
      However, there are sender-side algorithms for detecting SACK
      reneging, that allow the sender to maintain the SACK information
      over the retransmission timeouts. Such algorithm is required to be
      implemented at the sender in order to apply the SACK-enhanced F-

   2) The first acknowledgement after RTO arrives at the sender.

      a) if the acknowledgement is a duplicate ACK AND it does not hold
         new SACK blocks between SND.UNA and "send_high", revert to the
         conventional recovery and do not enter step 3 of this

      b) if the acknowledgement advances the window to a level not equal
         or above the "send_high" OR it contains a SACK block between
         SND.UNA and "send_high" that acknowledges new data not yet
         acknowledged, transmit two new segments.

   3) The second acknowledgement after RTO arrives at the sender.

      a) if the acknowledgement is a duplicate ACK AND it does not hold
         new SACK blocks between SND.UNA and "send_high", set congestion
         window to 3 * MSS and continue with the slow start algorithm
         retransmitting unacknowledged segments.

      b) if the acknowledgement advances the window OR it contains a
         SACK block between SND.UNA and "send_high" which acknowledges
         new data not yet marked acknowledged at the TCP sender,
         continue transmitting new data following the congestion
         avoidance algorithm.

   As with the basic version of the F-RTO algorithm, in step (2b) the

Expires: April 2003                                             [Page 7]

draft-sarolahti-tsvwg-tcp-frto-01.txt                       October 2002

   sender may transmit only one segment if the receiver window does not
   allow more, or there are no more application data.

4.  Scenarios

   We now discuss different scenarios where RTOs typically may occur and
   discuss how the F-RTO algorithm would perform in those scenarios. The
   interesting scenarios are a sudden delay triggering RTO, loss of a
   retransmitted packet during fast recovery, link outage losing several
   packets, and packet reordering. A performance evaluation with a more
   thorough analysis on a real implementation of F-RTO is given in

4.1.  Sudden delay

   An unexpectedly long delay can trigger RTO, should it occur on a
   single packet blocking the following packets, or appear as increased
   RTTs for several successive packets. The example below illustrates
   the sequence of packets and acknowledgements seen by the TCP sender
   that follows the F-RTO algorithm, when a sudden delay occurs
   triggering RTO but no packets are lost.  For simplicity, delayed
   acknowledgements are not used in the example.

         ...                (cwnd = 6, ssthresh < 6, FlightSize = 5)
         1.  SEND(10) ->
         2.  ACK(6) <-
         3.  SEND(11) ->
         4.  <delay + RTO>  (ssthresh <- 3)
         5.  SEND(6) ->
         6.  ACK(7) <-
         7.  SEND(12) ->
         8.  SEND(13) ->
         9.  ACK(8) <-      (cwnd <- 3, FlightSize = 6)
         10. ACK(9) <-      (cwnd = 3,  FlightSize = 5)
         11. ACK(10) <-     (cwnd = 3,  FlightSize = 4)
         12. ACK(11) <-     (cwnd = 4,  FlightSize = 3)
         13. SEND(14) ->

   When a sudden delay long enough to trigger RTO occurs at step 4, the
   TCP sender retransmits the first unacknowledged segment (step 5).
   Because the next ACK advances the window, the TCP sender continues by
   sending two new data segments (steps 7, 8) and adjusts cwnd to 3 MSS.
   Because the second acknowledgement arriving after the RTO also
   advances the window the TCP sender exits the recovery and continues
   with the congestion avoidance. From this point on the retransmissions

Expires: April 2003                                             [Page 8]

draft-sarolahti-tsvwg-tcp-frto-01.txt                       October 2002

   are invoked either by fast retransmit or when triggered by the
   retransmission timer. Because the TCP sender reduces cwnd when
   receiving the first ACK after RTO and sends the two new data segments
   at steps 7 and 8, it has to wait until the FlightSize is reduced to
   the level of congestion window before it can continue transmitting
   again at step 13.

4.2.  Loss of a retransmission

   If a retransmitted segment is lost, the only way to retransmit it
   again is to wait for the RTO to trigger the retransmission. Once the
   segment is successfully received, the receiver usually acknowledges
   several segments cumulatively. The example below shows a scenario
   where retransmission (of segment 6) is lost, as well as a later
   segment (segment 9) in the same window. The limited transmit [ABF01]
   or SACK TCP [MMFR96] enhancements are not in use in this example.

         ...                (cwnd = 6, ssthresh < 6, FlightSize = 5)
             <segment 6 lost>
         1.  SEND(10) ->
         2.  ACK(6) <-
         3.  SEND(11) ->
         4.  ACK(6) <-
         5.  ACK(6) <-
         6.  ACK(6) <-
         7.  SEND(6) ->     (cwnd <- 6, ssthresh <- 3, FlightSize = 6)
         8.  ACK(6) <-
         9.  <RTO>          (ssthresh <- 2)
         10. SEND(6) ->
         11. ACK(9) <-
         12. SEND(12) ->
         13. SEND(13) ->
         14. ACK(9) <-      (cwnd <- 3)
         15. SEND(9) ->
         16. SEND(10) ->
         17. SEND(11) ->
         18. ACK(11) <-

   In the example above, segment 6 is lost and the sender retransmits it
   after three duplicate ACKs in step 7. However, the retransmission is
   also lost, and the sender has to wait for the RTO to expire before
   retransmitting it again. Because the first ACK following the RTO
   advances the window (step 11), the sender transmits two new segments.
   The second ACK in step 14 does not advance the window, and the sender
   enters the slow start, sets cwnd to 3 * MSS, and retransmits the next

Expires: April 2003                                             [Page 9]

draft-sarolahti-tsvwg-tcp-frto-01.txt                       October 2002

   three unacknowledged segments, as per the F-RTO algorithm description
   given in Section 2. After this the receiver acknowledges all segments
   transmitted prior to entering recovery and the sender can continue
   transmitting new data in congestion avoidance.

4.3.  Link outage

   A performance study shows that F-RTO performs similarly to the
   regular recovery when consecutive packets are lost both up- and
   downstream as a result of link outage [SKR02]. Because one of the two
   next ACKs after RTO does not advance the window in case of data loss,
   the TCP sender starts retransmitting unacknowledged segments in slow

   The abovementioned performance study recovered a problem if the
   decision to skip retransmissions after RTO is based on the
   information from the TCP timestamps only (i.e. by following the Eifel
   algorithm). When both data segments and acknowledgements are dropped
   in the same window, the TCP sender may end up in a wrong conclusion:
   in some occasions it continues transmitting new segments according to
   timestamp feedback, even though several data segments have been
   dropped. A simple example illustrating the problem is given below. In
   Section 5 we outline how this phenomenon can be avoided by using a
   retransmission logic of the F-RTO algorithm in conjunction with the
   timestamp information.

         ...                (cwnd = 6, ssthresh = 4, FlightSize = 5)
         1.  SEND(10) ->    (ts 110>
         2.  ACK(6) <-      <tsecr 105>
         3.  SEND(11) ->    <ts 111>
         4.  <data segment 7 is lost, ACKs for 6-11 are lost>
         5.  <RTO>          (cwnd <- 1, ssthresh <- 3)
         6.  SEND(6) ->     <ts 116>
         7.  ACK(7) <-      <tsecr 106> (undo: cwnd <- 6, ssthresh <- 4)
         8.  SEND(12) ->    <ts 117>
         9.  ACK(7) <-      <tsecr 106>
         10. <RTO>
         11. SEND(7) ->     <ts 120>
         12. ACK(8) ->      <tsecr 120>

   In the above case the sender fails, because the duplicate ACKs caused
   by lost data segment 7 are required to echo the timestamp of the
   segment that was last to update the window [BBJ92]. Because the
   duplicate ACKs were dropped, the first ACK after the retransmission
   in step 6 appears as a new acknowledgement with a timestamp earlier
   than the timestamp of the retransmission. The sender reverts the

Expires: April 2003                                            [Page 10]

draft-sarolahti-tsvwg-tcp-frto-01.txt                       October 2002

   adjustments on the congestion window and continues transmitting new
   data, which is a wrong action to take. This can lead to another RTO
   which could have been avoided with the regular TCP sender that
   retransmits the unacknowledged segments after the RTO. The F-RTO
   sender can avoid the problem presented above, because it starts
   retransmitting in slow start after getting the second acknowledgement
   not advancing the window at step 9. This is the reason why the F-RTO
   sender is required to check at least two acknowledgements following
   the RTO before deciding on skipping the retransmissions.

4.4.  Packet reordering

   Since F-RTO modifies the TCP sender behavior only after a
   retransmission timeout, we limit the discussion on the effects of
   packet reordering in F-RTO behavior to the cases where packet
   reordering occurs immediately after RTO. We consider the
   retransmission timeout due to packet reordering to be very rare case,
   since reordering often triggers fast retransmit due to duplicate ACKs
   caused by out-of-order segments. Should packet reordering occur after
   a RTO, duplicate ACKs arrive to the sender, taking the F-RTO
   algorithm to retransmit in slow start as a regular RTO recovery would
   do. Although this might not be the correct action, it is similar to
   the behavior of the regular TCP, making F-RTO a safe modification
   also in the presence of reordering.

5.  Reverting the Congestion Control State

   The related work on improving the TCP performance on spurious
   retransmission timeouts suggests that the congestion control state
   would be reverted to the situation preceding the spurious timeout.
   The justification for this is that since there are no packets
   actually lost, the congestion window should not be reduced either.
   However, the recovery algorithms that react immediately after RTO,
   such as the F-RTO algorithm and Eifel algorithm, cannot detect the
   loss of the spurious retransmission. Although the probability of such
   packet loss is relatively small, we recommend that the congestion
   window would be halved in order to avoid the risk of a congestion
   control violation. By using the DSACK [FMMP00] option, the TCP sender
   can reliably detect whether the retransmission was unnecessary.

   An additional consideration related to congestion window adjustment
   is whether a spurious RTO caused by a delay spike or a similar event
   should be taken as a minor congestion signal, even though no packets
   were lost. During the delay outstanding packets will be queued up to
   a network node before the delay point, thus increasing the congestion
   level on that node and increasing the probability of a congestion

Expires: April 2003                                            [Page 11]

draft-sarolahti-tsvwg-tcp-frto-01.txt                       October 2002

   loss event later on. A retransmission timeout in general, even if
   spurious, is a strong indication of some sort of disruption in the
   network's ability to deliver packets to the destionation in time.
   Based on this discussion we consider reducing congestion window on
   suspected spurious RTO to be a safer action than reverting it to the
   level preceding the spurious RTO. However, we consider the exact
   actions to be taken on the congestion control state after a spurious
   RTO as a subject of further research.

   If TCP timestamps are in use, and the TCP sender decides to use
   timestamps as a basis of reverting the congestion control state
   regardless of the concerns raised above, the TCP sender SHOULD follow
   the retransmission algorithm given in Section 2 and revert the
   congestion control state only if it proceeds to algorithm branch
   (3b). This is to avoid the unwanted effects related to link outages
   that were shown in Section 4.3.

   When selective acknowledgements are available with the DSACK
   enhancement, the TCP sender can employ the DSACK enhancement for
   deciding when to revert the congestion control state. Again, the TCP
   sender should follow the retransmission algorithm given in Section 2.
   In the common case, only the segment that triggered RTO is
   retransmitted. Hence, if the TCP sender gets a DSACK feedback
   indicating that the RTO retransmission was unnecessary, it MAY revert
   the congestion control parameters to the values preceding the RTO. If
   the F-RTO algorithm results in retransmitting the last window of
   data, the sender must get a DSACK acknowledgement for all
   retransmitted segments before taking action on reverting the
   congestion control state.

6.  Security Considerations

   No additional security threats on TCP due to the F-RTO algorithm are


   We are grateful to Reiner Ludwig, Andrei Gurtov, Josh Blanton, Mark
   Allman, and Sally Floyd for the discussion and feedback contributed
   to this text.


   [ABF01]   M. Allman, H. Balakrishnan, and S. Floyd. Enhancing TCP's

Expires: April 2003                                            [Page 12]

draft-sarolahti-tsvwg-tcp-frto-01.txt                       October 2002

             Loss Recovery Using Limited Transmit. RFC 3042, January

   [APS99]   M. Allman, V. Paxson, and W. Stevens. TCP Congestion Con-
             trol. RFC 2581, April 1999.

   [BBJ92]   D. Borman, R. Braden, and V. Jacobson. TCP Extensions for
             High Performance. RFC 1323, May 1992.

   [FH99]    S. Floyd and T. Henderson. The NewReno Modification to
             TCP's Fast Recovery Algorithm. RFC 2582, April 1999.

   [FMMP00]  S. Floyd, J. Mahdavi, M. Mathis, and M. Podolsky. An Exten-
             sion to the Selective Acknowledgement (SACK) Option to TCP.
             RFC 2883, July 2000.

   [GL02]    A. Gurtov and R. Ludwig. Evaluating the Eifel Algorithm for
             TCP in a GPRS Network. In Proc. of European Wireless, Flo-
             rence, Italy, February 2002

   [LK00]    R. Ludwig and R.H. Katz. The Eifel Algorithm: Making TCP
             Robust Against Spurious Retransmissions. ACM Computer Com-
             munication Review, 30(1), January 2000.

   [MMFR96]  M. Mathis, J. Mahdavi, S. Floyd, and A. Romanow. TCP Selec-
             tive Acknowledgement Options. RFC 2018, October 1996.

   [PA00]    V. Paxson and M. Allman. Computing TCP's Retransmission
             Timer. RFC 2988, November 2000.

   [Pos81]   J. Postel. Transmission Control Protocol. RFC 793, Septem-
             ber 1981.

   [SKR02]   P. Sarolahti, M. Kojo, and K. Raatikainen. F-RTO: A New
             Recovery Algorithm for TCP Retransmission Timeouts. Univer-
             sity of Helsinki, Dept. of Computer Science. Series of Pub-
             lications C, No. C-2002-07. February 2002. Available at:

Authors' Addresses

   Pasi Sarolahti
   Nokia Research Center
   P.O. Box 407

Expires: April 2003                                            [Page 13]

draft-sarolahti-tsvwg-tcp-frto-01.txt                       October 2002

   Phone: +358 50 4876607
   EMail: pasi.sarolahti@nokia.com

   Markku Kojo
   University of Helsinki
   Department of Computer Science
   P.O. Box 26

   Phone: +358 9 1914 4179
   EMail: markku.kojo@cs.helsinki.fi

Expires: April 2003                                            [Page 14]

Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/