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

Versions: 00 01 02 03 04 draft-ietf-tsvwg-tcp-frto

Internet Engineering Task Force                             P. Sarolahti
INTERNET DRAFT                                     Nokia Research Center
File: draft-sarolahti-tsvwg-tcp-frto-03.txt                      M. Kojo
                                                  University of Helsinki
                                                           January, 2003
                                                     Expires: July, 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-
   Drafts.

   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
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


Abstract

   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 detecting spurious TCP RTOs. 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 helps to avoid
   additional unnecessary retransmissions and thereby improves TCP
   performance in case of a spurious timeout.



Expires: July 2003                                              [Page 1]


draft-sarolahti-tsvwg-tcp-frto-03.txt                       January 2003


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. Furthermore, after a spurious RTO a conventional TCP
   sender increases the congestion window in slow start, injecting a
   large number of data segments to the network within one round-trip
   time.

   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
   general.

   This document describes an alternative RTO recovery algorithm called
   "Forward RTO-Recovery" (F-RTO) to be used for detecting spurious RTO
   and thus avoiding unnecessary retransmissions following the RTO. 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 [BA02]) that have been suggested for detecting unnecessary
   retransmissions.  The Eifel algorithm uses TCP timestamps for



Expires: July 2003                                              [Page 2]


draft-sarolahti-tsvwg-tcp-frto-03.txt                       January 2003


   detecting a spurious timeout and the DSACK-based algorithms require
   that the SACK option with DSACK extension [FMMP00] is in use. With
   DSACK, the TCP receiver can report if it has received a duplicate
   segment, making it possible for the sender to detect afterwards
   whether it has made unnecessary retransmissions.

   When an 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, there was no sufficient evidence
   of spurious RTO; therefore the F-RTO sender retransmits the
   unacknowledged segments in slow start similarly to the traditional
   algorithm. 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.

   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] and Section 4 presents an alternative of F-RTO that
   uses the TCP timestamp option. Section 5 discusses the possible
   actions to be taken after detecting a spurious RTO, and Section 6
   discusses the security considerations.



2.  F-RTO Algorithm

   The 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.  The actions
   taken in response to spurious RTO are not described in this document,
   but we discuss the different alternatives for congestion control in
   Section 5.

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

   1) When RTO expires, the TCP sender SHOULD retransmit first
      unacknowledged segment.

      The highest sequence number transmitted so far is stored in
      variable "send_high". The TCP sender MAY postpone adjusting the
      congestion control parameters for the next two incoming ACKs,
      until it has got more input on whether the RTO was spurious or



Expires: July 2003                                              [Page 3]


draft-sarolahti-tsvwg-tcp-frto-03.txt                       January 2003


      not. If the TCP sender adjusts the congestion control parameters
      at this point, it may store the earlier values of the parameters
      to be able to restore the values when it detects that the RTO was
      spurious.

   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
      ACK.

      a) If the acknowledgement is a duplicate ACK OR it is
         acknowledging a sequence number equal or above to the value of
         send_high, the TCP sender SHOULD revert to the conventional
         recovery and 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 RTO
         retransmission.  This is possible, for example, if the RTO
         expired 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
         also 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, the TCP sender MAY transmit two new
         (previously unsent) segments.

         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 valid 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. In any case,
         the TCP sender SHOULD transmit at least one segment, either new
         data or from the retransmission queue. If the sender
         retransmits the next unacknowledged segment, it MUST NOT enter
         the step 3 of this algorithm, but continue retransmitting
         similarly to the conventional RTO recovery algorithm.

         If the first acknowledgement after RTO does not acknowledge all
         of the data that was retransmitted in step 1, the TCP sender
         MUST NOT enter step 3 of this algorithm. Otherwise, a malicious
         receiver acknowledging partial segments could cause the sender
         to declare the RTO spurious in a case where data was lost. When
         receiving an acknowledgement for a partial segment, the TCP



Expires: July 2003                                              [Page 4]


draft-sarolahti-tsvwg-tcp-frto-03.txt                       January 2003


         sender SHOULD revert to conventional RTO recovery.

   3) When the second acknowledgement after the RTO arrives at the
      sender, either declare the RTO spurious, or start retransmitting
      the unacknowledged segments.

      a) If the acknowledgement is a duplicate ACK, the TCP sender MUST
         set congestion window to no more than 3 * MSS, and continue
         with the slow start algorithm retransmitting unacknowledged
         segments.

         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 the RTO was
         spurious. 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 retransmits.

      b) If the acknowledgement advances the window and acknowledges
         data beyond the highest sequence number that was retransmitted
         on RTO, the TCP sender SHOULD declare the RTO spurious.

         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. The TCP
         sender should not assume that the unacknowledged segments are
         lost, and it should continue by sending new previously unsent
         segments.

         If this algorithm branch is taken, the TCP sender SHOULD set
         the value of send_high variable to SND.UNA in order to disable
         the Reno "bugfix" [FH99]. The send_high variable was proposed
         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 algorithm.

   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 SHOULD revert back to retransmitting unacknowledged data



Expires: July 2003                                              [Page 5]


draft-sarolahti-tsvwg-tcp-frto-03.txt                       January 2003


   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 that would result in additional RTO significantly
   degrading the TCP performance.  The TCP sender could try to proceed
   with the F-RTO algorithm by alternatively transmitting one segment
   from the tail of the retransmission queue, if it is not possible to
   transmit new data in algorithm step (2b). Another option would be to
   transmit data beyond the advertised receiver window. If the RTO was
   spurious, the receiver is likely to be able to store the segment at
   the time when it arrives. However, the current recommendation is to
   revert to the conventional RTO recovery if sending new data is not
   possible, because we believe the benefits of doing otherwise are not
   very remarkable.

   After the RTO is declared spurious, the TCP sender cannot detect if
   the unnecessary RTO retransmission was lost. In principle the loss of
   the RTO retransmission should be taken as a congestion signal, and
   thus there is a small possibility that the F-RTO sender violates the
   congestion control rules, if it chooses to fully revert congestion
   control parameters after detecting a spurious RTO. The Eifel
   detection algorithm has a similar property, but the DSACK option can
   be used to detect whether the retransmitted segment was successfully
   delivered to the receiver.

   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 may not detect the spurious RTO.
   Additionally, if a spurious RTO occurs during fast recovery, the F-
   RTO algorithm often cannot detect the spurious RTO.  However, we
   consider these cases relatively rare, and note that in cases where F-
   RTO fails to detect the spurious RTO, it performs similarly to the
   regular RTO recovery.








Expires: July 2003                                              [Page 6]


draft-sarolahti-tsvwg-tcp-frto-03.txt                       January 2003


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

   This section describes an alternative version of the F-RTO algorithm,
   that makes use of TCP Selective Acknowledgement Option [MMFR96].  By
   using the SACK option the TCP sender can detect spurious RTOs in most
   of the cases when packet reordering or packet duplication is present,
   or when the TCP sender is under loss recovery. The difference to the
   basic F-RTO algorithm is that the sender may declare RTO spurious
   even when duplicate ACKs follow the RTO, if the SACK blocks
   acknowledge new data that was not transmitted after RTO.

   DCLOR is a related TCP enhancement that uses SACK option for avoiding
   unnecessary retransmissions after a spurious RTO [SL02].  However,
   DCLOR is different from F-RTO in that it does not declare the RTO
   spurious before all segments outstanding when the RTO occurs have
   been acknowledged.

   The SACK-enhanced F-RTO algorithm takes the following steps:

   1) When RTO expires, the TCP sender SHOULD retransmit first
      unacknowledged segment.

      The TCP sender should also store the highest sequence number
      transmitted in variable "send_high".

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

      a) if the cumulative ACK acknowledges all segments up to send_high
         stored in algorithm step 1, the TCP sender SHOULD revert to the
         conventional RTO recovery and it MUST set congestion window to
         no more than 2 * MSS. The sender does not enter step 3 of this
         algorithm.

      b) otherwise, the TCP sender MAY transmit two new segments. If the
         TCP sender does not transmit any previously unsent data, it
         MUST NOT enter step 3 of this algorithm, but revert to the
         conventional RTO recovery.

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

      a) if the ACK acknowledges data above send_high, either in SACK
         blocks or as a cumulative ACK, the sender MUST set congestion
         window to no more than 3 * MSS and proceed with slow start,
         retransmitting unacknowledged segments. The sender SHOULD take
         this branch also when the acknowledgement is a duplicate ACK
         and it does not contain any new SACK blocks for previously
         unacknowledged data below send_high.




Expires: July 2003                                              [Page 7]


draft-sarolahti-tsvwg-tcp-frto-03.txt                       January 2003


      b) if the ACK does not acknowledge data above send_high and some
         previously unacknowledged data below send_high is acknowledged,
         the TCP sender SHOULD declare the RTO spurious.

         If there are unacknowledged holes between the received SACK
         blocks, those segments SHOULD be retransmitted similarly to the
         conventional SACK recovery algorithm. In addition, send_high
         should be set to its earlier value, since no loss recovery was
         needed due to the RTO.

   As with the basic version of the F-RTO algorithm, in step (2b) the
   sender may transmit only one segment if the receiver window does not
   allow more, or there are no more application data.


4.  On using the TCP timestamps with F-RTO

   The basic F-RTO algorithm suggests applying the conventional RTO
   recovery if the receiver window or application limits the
   transmission of new previously unsent data, and in such a case it is
   possible that the F-RTO algorithm cannot be used to detect a spurious
   RTO. The F-RTO sender can avoid the need of transmitting new
   previously unsent segments after RTO, if it has TCP timestamps
   [BBJ92] available. The Eifel detection algorithm [LK00] describes how
   the TCP timestamps can be used to avoid unnecessary retransmissions
   after a spurious RTO. However, if the RTO is declared spurious based
   on the timestamp echoed with the first acceptable ACK following the
   RTO, the TCP sender may falsely declare the RTO spurious and continue
   by transmitting new data when the RTO was caused by loss of
   acknowledgements. The Eifel algorithm may signal spurious RTO
   falsely, if the first data segment retransmitted after RTO was not
   lost, but the corresponding acknowledgement was, and the
   acknowledgement does not include DSACK option [FMMP00]. If sender and
   receiver implement DSACK, this problem can be avoided.

   An alternative algorithm for detecting spurious RTOs by using TCP
   timestamps without DSACK is described below. When TCP timestamps are
   available, the F-RTO sender MAY apply the following algorithm.

   1) When RTO expires, retransmit first unacknowledged segment and
      store the timestamp of retransmitted segment in variable
      "RetransmitTS". Store the highest sequence number transmitted so
      far in variable "send_high".

   2) Wait until the first ACK that acknowledges previously
      unacknowledged data arrives at the sender. If duplicate ACKs
      arrive, they are processed normally while the sender stays in this
      step of the algorithm.



Expires: July 2003                                              [Page 8]


draft-sarolahti-tsvwg-tcp-frto-03.txt                       January 2003


      a) if the timestamp echoed with the ACK is later or equal than
         what is stored in "RetransmitTS", the TCP sender SHOULD revert
         to the conventional RTO recovery and it MUST NOT enter step 3
         of this algorithm. The sender should adjust the congestion
         window according to the standard congestion control rules.

      b) if the timestamp echoed with the first ACK is earlier than what
         is stored in "RetransmitTS", the TCP sender SHOULD transmit the
         first unacknowledged segment and enter step 3 of this
         algorithm.

   3) When the next acknowledgement arrives at the sender, it SHOULD
      apply one of the following branches of the algorithm.

      a) if the timestamp echoed with the ACK is later or equal than
         what is stored in "RetransmitTS", or if the acknowledgement is
         duplicate ACK, the TCP sender SHOULD revert to the conventional
         RTO recovery. The TCP sender MUST set the congestion window to
         no more than 2 * MSS.

      b) if the timestamp echoed with the ACK is earlier than what is
         stored in "RetransmitTS", the TCP sender SHOULD declare the RTO
         spurious. send_high SHOULD be set to the value of SND.UNA to
         cancel the NewReno bugfix, as described in Section 2.

   The drawback of this algorithm compared to the original Eifel
   detection is that the above-presented algorithm can make two
   unnecessary retransmissions instead of one. In addition, packet
   reordering, packet duplication, or packet loss for the next segment
   after the one that triggered RTO may prevent the detection of
   spurious RTO.  Therefore, it may be desirable to apply the basic F-
   RTO or the SACK-enhanced version of the F-RTO algorithm whenever the
   sender is able to transmit previously unsent data when the first ACK
   after RTO arrives. However, we believe the algorithm above
   effectively avoids false spurious RTO signals.


5.  Taking Actions after Detecting Spurious RTO

   Upon retransmission timeout, a conventional TCP sender assumes that
   outstanding segments are lost and starts retransmitting the
   unacknowledged segments. When the RTO is detected to be spurious, the
   TCP sender should not start retransmitting based on the RTO. For
   example, if the sender was in congestion avoidance phase transmitting
   new previously unsent segments, it should continue transmitting
   previously unsent segments after detecting spurious RTO. In addition,
   it is suggested that the RTO estimation is reinitialized and the RTO
   timer is adjusted to a more conservative value in order to avoid



Expires: July 2003                                              [Page 9]


draft-sarolahti-tsvwg-tcp-frto-03.txt                       January 2003


   subsequent spurious RTOs [LG02].

   Different approaches have been suggested for adjusting the congestion
   control state after a spurious RTO. This document does not recommend
   any of the alternatives below, but considers the response to spurious
   RTO as a subject of further research.

   1) Revert the congestion control parameters to the state before the
      RTO [LG02]. This appears to be a justified decision, because it is
      similar to the situation in which the RTO did not expire
      spuriously. However, we identified two concerns in this approach:
      First, some detection mechanisms, such as F-RTO or the Eifel
      Detection algorithm, do not notice the loss of the spurious
      retransmission, thus introducing a small risk of violation of the
      congestion control principles. Second, a spurious RTO indicates
      that some part of the network was unable to deliver packets for a
      while, which can be considered as a potential indication of
      congestion.

   2) Reduce ssthresh and congestion window when detecting a spurious
      RTO [SKR02]. For example, ssthresh and cwnd could be set to half
      of their earlier values, as done with the other congestion
      notification events. This alternative would be conservative enough
      considering the possibility of not detecting a packet loss of the
      RTO-triggered retransmission, but the TCP sender should avoid
      reducing the congestion window more than once in a round-trip
      time.

   3) Reset congestion window to one segment and proceed with slow
      start, once the pipe is assumed to be empty from earlier packets
      [SL02]. This would be a justified action to take if the spurious
      RTO is assumed to be caused due to changes in the network
      conditions, such as a change in the available bandwidth or a
      wireless handoff to another point in the network. Disadvantage of
      this alternative is that it is rather inefficient on a network
      paths with high delay, and on the other hand, it may result in
      slow start overshoot.


6.  Security Considerations

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


Acknowledgements





Expires: July 2003                                             [Page 10]


draft-sarolahti-tsvwg-tcp-frto-03.txt                       January 2003


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


Normative References

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

   [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.

Informative References

   [ABF01]   M. Allman, H. Balakrishnan, and S. Floyd. Enhancing TCP's
             Loss Recovery Using Limited Transmit. RFC 3042, January
             2001.

   [BA02]    E. Blanton and M. Allman. On Making TCP more Robust to
             Packet Reordering. ACM Computer Communication Review,
             32(1), January 2002.

   [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

   [LG02]    R. Ludwig and A. Gurtov. The Eifel Response Algorithm for
             TCP. Internet draft "draft-ietf-tsvwg-tcp-eifel-
             response-02.txt".  December 2002. Work in progress.

   [LK00]    R. Ludwig and R.H. Katz. The Eifel Algorithm: Making TCP



Expires: July 2003                                             [Page 11]


draft-sarolahti-tsvwg-tcp-frto-03.txt                       January 2003


             Robust Against Spurious Retransmissions. ACM Computer Com-
             munication Review, 30(1), January 2000.

   [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:
             http://www.cs.helsinki.fi/research/iwtcp/papers/f-rto.ps

   [SL02]    Y. Swami and K. Le. DCLOR: De-correlated Loss Recovery
             using SACK option for spurious timeouts. Internet draft
             "draft-swami-tsvwg-tcp-dclor-00.txt". November 2002. Work
             in progress.


Appendix A: Scenarios

   This section discusses different scenarios where RTOs occur and how
   the basic F-RTO algorithm performs in those scenarios. The
   interesting scenarios are a sudden delay triggering RTO, loss of a
   retransmitted packet during fast recovery, link outage causing the
   loss of several packets, and packet reordering. A performance
   evaluation with a more thorough analysis on a real implementation of
   F-RTO is given in [SKR02].

A.1.  Sudden delay

   An unexpectedly long delay can trigger an 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>  (set ssthresh <- 3)
         5.  SEND(6)
         6.  ACK(7)
         7.  SEND(12)
         8.  SEND(13)
         9.  ACK(8)         (set 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)



Expires: July 2003                                             [Page 12]


draft-sarolahti-tsvwg-tcp-frto-03.txt                       January 2003


         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 cumulative ACK point, 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 cumulative ACK point, the TCP sender
   exits the recovery and continues with the congestion avoidance. From
   this point on the retransmissions 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.

A.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)        (set cwnd <- 6, set ssthresh <- 3)
             <segment 6 lost>
         8.  ACK(6)
         9.  <RTO>          (set ssthresh <- 2)
         10. SEND(6)
         11. ACK(9)
         12. SEND(12)
         13. SEND(13)
         14. ACK(9)         (set cwnd <- 3)
         15. SEND(9)
         16. SEND(10)
         17. SEND(11)
         18. ACK(11)



Expires: July 2003                                             [Page 13]


draft-sarolahti-tsvwg-tcp-frto-03.txt                       January 2003


         ...

   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 cumulative ACK point (step 11), the sender transmits two
   new segments. The second ACK in step 14 does not advance the
   cumulative ACK point, and the sender enters the slow start, sets cwnd
   to 3 * MSS, and retransmits the next 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.

A.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, triggering an RTO [SKR02].  If
   the RTO was not spurious but some data was actually lost, one of the
   next two ACKs after RTO does not advance the cumulative ACK point
   when RTO was caused by data loss, because the basic F-RTO retransmits
   only one segment after RTO. As a result, F-RTO sender continues by
   retransmitting unacknowledged segments similarly to the conventional
   RTO recovery.

A.4.  Packet reordering

   Since F-RTO modifies the TCP sender behavior only after a
   retransmission timeout and it is intended to avoid unnecessary
   retransmits only after spurious RTO, 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
   an 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.


Authors' Addresses

   Pasi Sarolahti
   Nokia Research Center



Expires: July 2003                                             [Page 14]


draft-sarolahti-tsvwg-tcp-frto-03.txt                       January 2003


   P.O. Box 407
   FIN-00045 NOKIA GROUP
   Finland

   Phone: +358 50 4876607
   EMail: pasi.sarolahti@nokia.com
   http://www.cs.helsinki.fi/u/sarolaht/


   Markku Kojo
   University of Helsinki
   Department of Computer Science
   P.O. Box 26
   FIN-00014 UNIVERSITY OF HELSINKI
   Finland

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

































Expires: July 2003                                             [Page 15]


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