[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 03 04 05 06 07 rfc4653                                  
Internet Engineering Task Force                       Sumitha Bhandarkar
INTERNET DRAFT                                     A. L. Narasimha Reddy
draft-ietf-tcpm-tcp-dcr-03.txt                      Texas A&M University
Expires : August 2005                                        Mark Allman
                                                           Ethan Blanton
                                                       Purdue University
                                                           February 2005

        Improving the Robustness of TCP to Non-Congestion Events

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

   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

   This Internet-Draft will expire in August 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).


   This document specifies Non-Congestion Robustness (NCR) for TCP.  In
   the absence of explicit congestion notification from the network,
   TCP's loss recovery algorithms treat the receipt of three duplicate

Bhandarkar/et. al.         Expires August 2005                  [Page 1]

draft-ietf-tcpm-tcp-dcr-03                                 February 2005

   acknowledgments as an implicit indication of congestion in the
   network.  This is not always correct, notably in the case when
   network paths reorder segments (for whatever reason), resulting in
   degraded performance.  TCP-NCR is designed to mitigate this degraded
   performance by increasing the number of duplicate acknowledgments
   required to trigger loss recovery, based on the current state of the
   connection, in an effort to disambiguate true segment loss from
   segment reordering.  In addition, we specify a change to TCP's
   congestion reaction decision point, as well (but, do not require such
   a change to use NCR).  This document specifies the changes to TCP, as
   well as the costs and benefits of these modifications.


       The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
       "OPTIONAL" in this document are to be interpreted as described
       in [RFC2119].

       Readers should be familiar with the TCP terminology given in
       [RFC2581] and [RFC3517].

1. Introduction

   One strength of TCP [RFC793] lies in its ability to adjust its
   sending rate according to the perceived congestion in the network
   [Jac88,RFC2581].  In the absence of explicit notification of
   congestion from the network, TCP uses segment loss as an indication
   of congestion (i.e., assuming queue overflow).  TCP receivers send
   cumulative acknowledgments (ACKs) indicating the next sequence number
   expected from the sender for arriving segments [RFC793].  When
   segments arrive out of order duplicate ACKs are generated.  As
   specified in [RFC2581], a TCP sender uses the arrival of three
   duplicate ACKs as an indication of segment loss.  The TCP sender
   retransmits the lost segment and reduces the load imposed on the
   network, assuming the segment loss was caused by resource contention
   within the network path.  The TCP sender does not assume loss on the
   first duplicate ACK, but waits for three dupacks to account for mild
   reordering.    However, the use of this constant number of duplicate
   ACKs has a number of implications that can be mitigated if the
   duplicate ACK requirement is changed.

   The following is an example of TCP's behavior:

     + TCP A is the data sender and TCP B is the data receiver.

     + TCP A sends 10 segments each consisting of a single data byte
       (i.e., transmits bytes 1-10 in segments 1-10).

Bhandarkar/et. al.         Expires August 2005                  [Page 2]

draft-ietf-tcpm-tcp-dcr-03                                 February 2005

     + Assume segment 3 is dropped in the network.

     + TCP B cumulatively acknowledges segments 1 and 2, making the
       cumulative ACK transmitted to the sender 3 (the next expected
       sequence number).  (Note: TCP B may generate one or two ACKs,
       depending on whether delayed ACKs [RFC1122,RFC2581] are

     + The arrival of segments 4-10 at TCP B will each trigger the
       transmission of a cumulative ACK for sequence number 3.  (Note:
       [RFC2581] recommends that delayed ACKs not be used when the ACK
       is triggered by an out-of-order segment.)

     + When TCP A receives the third duplicate ACK (or fourth ACK
       overall) for sequence number 3, TCP A will retransmit
       segment 3 and reduce the sending rate by roughly half (see
       [RFC2581] for specifics on the congestion control state

   Alternatively, suppose segment 3 was not dropped by the network, but
   rather delayed such that segment 3 arrives after segment 10.  The
   above scenario will play out in precisely the same manner.  In other
   words, TCP is not capable of disambiguating that level of packet
   reordering from loss.

   The following is the specific motivation behind making TCP robust to
   reordered segments:

     * A number of Internet measurement studies have shown that packet
       reordering is not a rare phenomenon [Pax97,BPS99,JIDKT03,GPL04].
       Further, the reordering can be well beyond that which fast
       retransmit can cope with using the arrival of three duplicate
       ACKs to disambiguate loss and reordering.

     * [BA02,ZKFP03] show the negative performance implications that
       packet reordering has on current TCP.

     * The requirement imposed by TCP for almost in-order packet
       delivery places a severe constraint on the design of future
       technology.  Novel routing algorithms, network components,
       link-layer retransmission mechanisms and applications could all
       be looked at with a fresh perspective if TCP were to be more
       robust to segment reordering.  For instance, high speed packet
       switches could cause resequencing of packets if TCP were more
       robust.  There has been work proposed in the literature
       explicitly to ensure that packet ordering is maintained in such
       switches [KM02].  Also, link-layer mechanisms that attempt to
       recover from packet corruption by retransmitting could be

Bhandarkar/et. al.         Expires August 2005                  [Page 3]

draft-ietf-tcpm-tcp-dcr-03                                 February 2005

       allowed to reorder packets and, hence, increase the chances of
       local loss repair rather than relying on TCP to repair the loss
       (and, needlessly reduce its sending rate).  Other examples are
       multi-path routing, high-delay satellite links and some of the
       schemes proposed for differentiated services architecture.  By
       making TCP more robust to non-congestion events, TCP-NCR may
       open the design space of the future Internet components.

   In this document we specify a set of sender modifications to provide
   Non-Congestion Robustness (NCR) to TCP.  In particular, these changes
   are built on top of TCP with selective acknowledgments (SACKs)
   [RFC2018] and the SACK-based loss recovery scheme given in [RFC3517],
   since SACK is widely deployed at this point ([MAF04] indicates that
   68% of web servers and 88% of web clients utilize SACK as of spring,

   The remainder of this document is organized as follows.  In Section
   2, we specify the TCP-NCR algorithm.  Section 3 provides a brief
   overview of the benefits of TCP-NCR, while Section 4 discusses the
   drawbacks of TCP-NCR.  Section 5 discusses related work.  Section 6
   discusses security concerns.

2. Algorithm

   The TCP-NCR modifications make two fundamental changes to the way
   [RFC3517] currently operates, as follows.

   First, the trigger for retransmitting a segment is changed from three
   duplicate ACKs [RFC2581,RFC3517] to a congestion window's worth of
   duplicate ACKs.  This provides more time for packet reordering to
   "work itself out" before the TCP sender infers that a segment has
   been lost and needs retransmitted.  Setting the retransmission point
   is a balancing act.  On the one hand, if the trigger is too
   aggressive (as is sometimes the situation in current TCP stacks using
   three duplicate acknowledgments to trigger loss recovery), the TCP
   sender cannot accurately disambiguate loss from reordering. On the
   other hand, waiting too long to decide to use fast retransmit risks
   relying on the costly retransmission timeout (RTO) mechanism
   [RFC2988].  Using a congestion window's worth of duplicate ACKs
   provides a reasonable tradeoff because the delay involved (roughly
   one RTT) is strictly less than the RTO and there is enough data in
   the pipe to generate the number of duplicate ACKs required to trigger
   a retransmission (given the extended version of Limited Transmit
   [RFC3042] specified below).

   Second, TCP-NCR decouples initial congestion control decisions from
   retransmission decisions, in some cases delaying congestion control
   changes relative to TCP's current behavior defined in [RFC2581].  The

Bhandarkar/et. al.         Expires August 2005                  [Page 4]

draft-ietf-tcpm-tcp-dcr-03                                 February 2005

   algorithm provides two alternatives for extending Limited Transmit.
   The two variants of extended Limited Transmit are:

       Careful Limited Transmit:

        This variant calls for reducing the sending rate at
        approximately the same time [RFC2581] implementations reduce
        the congestion window, while at the same time withholding a
        retransmission (and the final congestion determination) for
        approximately one RTT.

       Aggressive Limited Transmit:

        This variant calls for maintaining the sending rate in the
        face of duplicate ACKs until TCP concludes a segment is lost
        and needs to be retransmitted. (which, per the above, TCP-NCR
        delays by one RTT when compared with current loss recovery

   TCP-NCR implementation MUST use either Careful Limited Transmit or
   Aggressive Limited Transmit.

   A constant MUST be set depending on which variant of extended Limited
   Transmit is used, as follows:

       Careful Limited Transmit:

        LT_F = 2/3

       Aggressive Limited Transmit:

        LT_F = 1/2

   This constant reflects the fraction of outstanding data that must be
   ACKed before a retransmission is triggered.  Since NCR's goal is to
   wait roughly one RTT to retransmit, the fraction reflects the
   different number of segments that will be transmitted during extended
   Limited Transmit by the two schemes (and therefore their

   The TCP-NCR modifications specified in this document lend themselves
   to incremental deployment. Only the TCP implementation on the sender
   side requires modification.  The changes themselves are modest.
   However, as will be discussed below, availability of additional
   buffer space at the receiver will help maximize the benefits of using
   TCP-NCR but are not strictly necessary.

   The following algorithms depend on the notions provided by [RFC3517]

Bhandarkar/et. al.         Expires August 2005                  [Page 5]

draft-ietf-tcpm-tcp-dcr-03                                 February 2005

   and we assume the reader is familiar with the terminology given in
   [RFC3517].  The TCP-NCR algorithm can be adapted to alternate SACK-
   based loss recovery schemes.  [BR04,BSRV04] outline non-SACK-based
   algorithms, however, we do not specify those algorithms in this
   document and do not recommend them due to both the complexity and
   security implications of having only a gross understanding of the
   number of outstanding segments in the network.

   A TCP connection using the Nagle algorithm [RFC896,RFC1122] MAY
   employ the TCP-NCR algorithm.  If a TCP implementation does implement
   TCP-NCR the implementation MUST follow the various specifications
   provides in sections 2.1 - 2.4.  If the Nagle algorithm is not being
   used there is no way to accurately calculate the number of
   outstanding segments in the network (and, therefore, no good way to
   derive an appropriate duplicate ACK threshold).  A TCP connection
   that does not employ the Nagle algorithm MAY use TCP-NCR if the TCP
   implementation tracks the sequence numbers transmitted in each
   segment and the following algorithm is carefully adapted.

   2.1.  Initialization

   When entering a period of loss / reordering detection and Extended
   Limited Transmit a TCP-NCR MUST initialize several state variables.
   A TCP MUST enter Extended Limited Transmit upon receiving the first
   ACK with a SACK block after the reception of an ACK that (a) did not
   contain SACK information and (b) did increase the connection's
   cumulative ACK point.  The initializations are:

   (I.1) Save the current FlightSize.

         FlightSizePrev = FlightSize

   (I.2) Set a variable for tracking the number of segments for which
         an ACK does not trigger a transmission during Careful Limited

         Skipped = 0

   (I.3) Set DupThresh (from [RFC3517]) based on the size of the
         current FlightSize.

         DupThresh = max (LT_F * (FlightSize / SMSS),3)

         Note: We keep the lower bound of DupThresh = 3 from

   In addition to the above steps, the incoming ACK MUST be processed
   with the E series of steps in section 2.3.

Bhandarkar/et. al.         Expires August 2005                  [Page 6]

draft-ietf-tcpm-tcp-dcr-03                                 February 2005

   2.2.  Terminating Extended Limited Transmit and Preventing Bursts

   Extended Limited Transmit MUST be terminated at the start of loss
   recovery as outlined in section 2.4.

   The arrival of an ACK that advances the cumulative ACK point before
   loss recovery is triggered signals that the series of duplicate ACKs
   were caused by reordering and not congestion.  Therefore, the receipt
   of an ACK that extends the cumulative ACK point MUST terminate
   Extended Limited Transmit.  As described below, an ACK that also
   contains SACK information will also trigger the beginning of a new
   Extended Limited Transmit phase.  Upon the termination of Extended
   Limited Transmit, and especially when using the Careful variant, TCP-
   NCR may be in a situation where the entire cwnd is not being utilized
   and therefore TCP-NCR will be prone to transmitting a burst of
   segments into the network.  Therefore, upon exiting Extended Limited
   Transmit the following steps MUST be taken.

   When a TCP-NCR in the Extended Limited Transmit phase receives an ACK
   that updates the cumulative ACK point (regardless of whether the ACK
   contains SACK information), the following steps MUST be taken:

   (T.1) cwnd = min (FlightSize + SMSS,FlightSizePrev)

         This step ensures that cwnd is not grossly larger than the
         amount of data outstanding --- a situation that would cause a
         line rate burst.

   (T.2) ssthresh = FlightSizePrev

         This step provides TCP-NCR with a sense of "history".  If step
         (T.1) reduces cwnd below FlightSizePrev this step ensures that
         TCP-NCR will slow start back to operating point in effect
         before Extended Limited Transmit.

   (T.3) Transmit previously unsent data as allowed by cwnd,
         FlightSize, application data availability and the receiver's
         advertised window.

   (T.4) When the cumulative ACK also contains SACK information, the
         initializations in steps (I.2) and (I.3) from section
         2.1 MUST be taken (but, not step (I.1)) to re-start Extended
         Limited Transmit.  In addition, the series of steps in section
         2.3 (the "E" steps) MUST be taken.

   2.3. Extended Limited Transmit

   On each ACK containing SACK information that arrives after TCP-NCR

Bhandarkar/et. al.         Expires August 2005                  [Page 7]

draft-ietf-tcpm-tcp-dcr-03                                 February 2005

   has entered the Extended Limited Transmit phase (as outlined in
   section 2.1) and before Extended Limited Transmit terminates, the
   sender MUST use the following procedure.

   (E.1) Use the SetPipe () procedure from [RFC3517] to set the "pipe"
         variable (which represents the number of bytes still considered
         "in the network").

   (E.2) If the following comparison holds and there are SMSS bytes of
         previously unsent data available for transmission then
         transmit one segment of SMSS bytes.

           (pipe + Skipped) <= (FlightSizePrev - SMSS)

         If the comparison does not hold or no new data can be
         transmitted (due to lack of data from the application or the
         advertised window limit), skip to step (E.6).

   (E.3) Increment pipe by SMSS bytes.

   (E.4) If using Careful Limited Transmit, increment Skipped by SMSS
         bytes to ensure that the next SMSS bytes of SACKed data
         processed do not trigger a Limted Transmit transmission (since
         the goal of Careful Limited Transmit is to send upon the
         reception of every second duplicate ACK).

   (E.5) Return to step (E.2) to ensure that as many bytes as
         appropriate are transmitted.  This provides robustness to ACK
         loss that can be (largely) compensated for using SACK

   (E.6) Reset DupThresh via:

           DupThresh = max (LT_F * (FlightSize / SMSS),3)

         where FlightSize is the total number of bytes that have not
         been cumulatively acknowledged.

   2.4 Entering Loss Recovery

       When a segment is deemed lost via the algorithms in [RFC3517],
       Extended Limited Transmit MUST be terminated, leaving the
       algoritms in [RFC3517] to govern TCP's behavior.  One slight
       change to [RFC3517] MUST be made, however.  In section 5, step
       (2) of [RFC3517] MUST be changed to:

           (2) ssthresh = cwnd = (FlightSizePrev / 2)

Bhandarkar/et. al.         Expires August 2005                  [Page 8]

draft-ietf-tcpm-tcp-dcr-03                                 February 2005

       This ensures that the congestion control modifications are made
       with respect to the amount of data in the network before
       FlightSize was increased by Extended Limited Transmit.

3. Advantages

   The major advantages of TCP-NCR are two-fold.  As discussed in
   section 1, TCP-NCR will open up the design space for network
   applications and components that are currently constrained by TCP's
   lack of robustness to packet reordering.  The second advantage is in
   terms of an increase in TCP performance.

   [BR04] presents ns-2 [NS-2] simulations of a pre-cursor to the TCP-
   NCR algorithm specified in this document, called TCP-DCR (Delayed
   Congestion Response). The paper shows that TCP-DCR aids performance
   in comparison to unmodified TCP in the presence of packet reordering.
   In addition, the extended version of [BR04] presents results based on
   emulations involving Linux (kernel 2.4.24).  These results show that
   the performance of TCP-DCR is similar to Linux's native
   implementation that seeks to "undo" wrong decisions based on DSACK
   [RFC2883] feedback (similar to the schemes outlined in [ZKFP03]) when
   packets are reordered by less than one RTT. The advantages of using
   TCP-DCR over the DSACK-based scheme is that the DSACK-based scheme
   tries to estimate the exact amount of reordering in the network using
   fairly complex algorithms, whereas TCP-DCR achieves similar results
   with less complicated modifications.

   In addition, [BR04,BSRV04] illustrate the ability of TCP-DCR to allow
   for the improvement of other parts of the system.  For example, these
   papers show that increasing TCP's robustness to packet reordering
   allows for a novel wireless ARQ mechanism to be added at the link-
   layer.  The added robustness of the link-layer to channel errors, in
   turn, increases TCP performance by not requiring TCP to retransmit
   packets that were dropped due to corruption (and, hence, also
   prevents TCP from needlessly reducing the sending rate when
   retransmitting these segments).

4. Disadvantages

   While we note that all of the changes outlined above are implemented
   in the sender, the receiver also potentially has a part to play.  In
   particular, TCP-NCR increases the receiver's buffering requirement by
   up to an extra cwnd -- in the case of the TCP sender using Aggressive
   Limited Transmit and actual loss occurring in the network.
   Therefore, to maximize the benefits from TCP-NCR receivers should
   advertise a large window to absorb the extra out-of-order traffic. In
   the case that the additonal buffer requirements are not met, the use
   of the above algorithm takes into account the reduced advertised

Bhandarkar/et. al.         Expires August 2005                  [Page 9]

draft-ietf-tcpm-tcp-dcr-03                                 February 2005

   window, resulting in slighlty reduced robustness to reordering. (The
   worst case robustness of cwnd/2 still offers an improvement over
   existing [RFC2581] implementations.)

   In addition, using TCP-NCR could delay the delivery of data to the
   application by up to one RTT because the fast retransmission point is
   delayed by roughly one RTT in TCP-NCR.  Applications that are
   sensitive to such delays should turn off the TCP-NCR option.

   Finally, the use of TCP-NCR makes the recovery from congestion events
   sluggish. While the simulation study presented in [BR04,BSRV04] shows
   that this does not have a significant impact further experimentation
   on the real Internet is required to verify that result.

5. Related Work

   Over the past few years, several solutions have been proposed to
   improve the performance of TCP in the face of segment reordering.
   These schemes generally fall into one of two categories (with some
   overlap): mechanisms that try to prevent spurious retransmits from
   happening and mechanisms that try to detect spurious retransmits and
   "undo" the needless congestion control state changes that have been

   [BA02,ZKFP03] attempt to prevent segment reordering from triggering
   spurious retransmits by using various algorithms to approximate the
   duplicate ACK threshold required to disambiguate loss and reordering
   over the given network path.  TCP-NCR similarly tries to prevent
   spurious retransmits.  However, TCP-NCR takes a simplified approach
   compared to those in [BA02,ZKFP03] in that TCP-NCR simply delays
   retransmission by a fixed amount (in comparison to standard TCP),
   while the other schemes use relatively complex algorithms in an
   attempt to derive a more precise value for DupThresh that depends on
   the network conditions.  While TCP-NCR offers simplicity the other
   schemes may offer more precision such that applications would not be
   forced to wait as long for their retransmissions.

   On the other hand, several schemes have been developed to detect and
   mitigate needless retransmissions after the fact.
   [RFC3522,RFC3708,BA02,LG04,SK04] present algorithms to detect
   spurious retransmits and mitigate the changes these events made to
   the congestion control state.  TCP-NCR could be used in conjunction
   with these algorithms, with TCP-NCR attempting to prevent spurious
   retransmits and some other scheme kicking in if the prevention
   failed.  In addition, we note that TCP-NCR is concentrated on
   preventing spurious fast retransmits and some of the above algorithms
   also attempt to detect and mitigate spurious timeout-based

Bhandarkar/et. al.         Expires August 2005                 [Page 10]

draft-ietf-tcpm-tcp-dcr-03                                 February 2005

6. Security Considerations

   We do not believe there are security implications involved with TCP-
   NCR over and above those for general TCP congestion control
   [RFC2581].  In particular, the Extended Limited Transmit algorithms
   have been specifically designed to not be susceptible to the sorts of
   ACK splitting attacks TCP's general TCP congestion control is
   vulnerable to (as discussed in [RFC3465].

8. Acknowledgements

   Sally Floyd, Nauzad Sadry and Nitin Vaidya as well as feedback from
   from the TCPM working group have contributed significantly to this
   document.  Our thanks to all!

9. Normative References

   [RFC793] J. Postel, "Transmission Control Protocol", RFC 793,
   September 1981.

   [RFC2018] M. Mathis, J. Mahdavi, S. Floyd and A. Romanow, "TCP
   selective acknowledgment options," Internet RFC 2018.

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
   Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2581] M. Allman, V. Paxson, and  W. Stevens, "TCP Congestion
   Control", RFC 2581, April 1999.

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

   [RFC3517] E. Blanton, M. Allman, K. Fall and L. Wang, "A Conservative
   Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for
   TCP", RFC 3517, April 2003.

9. Informative References

   [BA02] E. Blanton and M. Allman, "On Making TCP More Robust to Packet
   Reordering," ACM Computer Communication Review, January 2002.

   [BPS99] J. Bennett, C. Partridge, and N. Shectman, "Packet reordering
   is not pat hological network behavior," IEEE/ACM Transactions on
   Networking, December 1999.

   [BR04] Sumitha Bhandarkar and A. L. Narasimha Reddy, "TCP-DCR: Making
   TCP Robust to Non-Congestion Events", In the Proceedings of
   Networking 2004 conference, May 2004. Extended version available as

Bhandarkar/et. al.         Expires August 2005                 [Page 11]

draft-ietf-tcpm-tcp-dcr-03                                 February 2005

   tech report TAMU-ECE-2003-04.

   [BSRV04] Sumitha Bhandarkar, Nauzad Sadry, A. L. Narasimha Reddy and
   Nitin Vaidya, "TCP-DCR: A Novel Protocol for Tolerating Wireless
   Channel Errors", To appear in IEEE Transactions on Mobile Computing

   [GPL04] Ladan Gharai, Colin Perkins and Tom Lehman, "Packet
   Reordering, High Speed Networks and Transport Protocol Performance",
   ICCCN 2004, October 2004.

   [Jac88] V. Jacobson, "Congestion Avoidance and Control", Computer
   Communication Review, vol. 18, no. 4, pp. 314-329, Aug. 1988.

   [JIDKT03] S. Jaiswal, G. Iannaccone, C. Diot, J. Kurose, and D.
   Towsley, "Measurement and Classification of Out-of-Sequence Packets
   in a Tier-1 IP Backbone," Proceedings of IEEE INFOCOM, 2003.

   [KM02] I. Keslassy and N. McKeown, "Maintaining packet order in
   twostage switche s," Proceedings of the IEEE Infocom, June 2002

   [LG04] R. Ludwig, A. Gurtov, "The Eifel Response Algorithm for TCP",
   Internet-Draft draft-ietf-tsvwg-tcp-eifel-response-06.txt (work in
   progress).  September 2004.

   [MAF04] A. Medina, M. Allman, S. Floyd.  Measuring Interactions
   Between Transport Protocols and Middleboxes.  ACM SIGCOMM/USENIX
   Internet Measurement Conference, Taormina, Sicily, Italy, October

   [NS-2] ns-2 Network Simulator. http://www.isi.edu/nsnam/

   [Pax97] V. Paxson, "End-to-End Internet Packet Dynamics," Proceedings
   of ACM SIGCOMM, September 1997.

   [RFC896] J. Nagle, "Congestion Control in IP/TCP Internetworks", RFC
   896, January 1984.

   [RFC1122] R. Braden, "Requirements for Internet Hosts - Communication
   Layers", RFC 1122, October 1989.

   [RFC2883] Sally Floyd, Jamshid Mahdavi, Matt Mathis and Matt
   Podolsky, "An Extension to the Selective Acknowledgement (SACK)
   Option for TCP," RFC 2883, July 2000.

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

Bhandarkar/et. al.         Expires August 2005                 [Page 12]

draft-ietf-tcpm-tcp-dcr-03                                 February 2005

   [RFC3465] M. Allman.  TCP Congestion Control with Appropriate Byte
   Counting (ABC), February 2003.  RFC 3465.

   [RFC3522] R. Ludwig and M. Meyer, "The Eifel Detection Algorithm for
   TCP," RFC 3522, April 2003.

   [RFC3708] E. Blanton and M. Allman, "Using TCP Duplicate Selective
   Acknowledgement (DSACKs) and Stream Control Transmission Protocol
   (SCTP) Duplicate Transmission Sequence Numbers (TSNs) to Detect
   Spurious Retransmissions", RFC 3708, February 2004.

   [SK04] P. Sarolahti, M. Kojo, "Forward RTO-Recovery (F-RTO): An
   Algorithm for Detecting Spurious Retransmission Timeouts with TCP and
   SCTP", Internet-Draft draft-ietf-tcpm-frto-02.txt (work in progress).
   November 2004.

   [ZKFP03] M. Zhang, B. Karp, S. Floyd, L. Peterson, RR-TCP: A
   Reordering-Robust TCP with DSACK, in Proceedings of the Eleventh IEEE
   International Conference on Networking Protocols (ICNP 2003),
   Atlanta, GA, November, 2003.

13. Author's Addresses

   Sumitha Bhandarkar
   Dept. of Elec. Engg.
   214 ZACH
   College Station, TX 77843-3128
   Phone: (512) 468-8078
   Email: sumitha@tamu.edu
   URL  : http://students.cs.tamu.edu/sumitha/

   A. L. Narasimha Reddy
   Dept. of Elec. Engg.
   315C WERC
   College Station, TX 77843-3128
   Phone : (979) 845-7598
   Email : reddy@ee.tamu.edu
   URL   : http://ee.tamu.edu/~reddy/

   Mark Allman
   ICSI Center for Internet Research
   1947 Center Street, Suite 600
   Berkeley, CA 94704-1198
   Phone: (216) 243-7361
   Email: mallman@icir.org
   URL: http://www.icir.org/mallman/

Bhandarkar/et. al.         Expires August 2005                 [Page 13]

draft-ietf-tcpm-tcp-dcr-03                                 February 2005

   Ethan Blanton
   Purdue University Computer Sciences
   1398 Computer Science Building
   West Lafayette, IN  47907
   EMail: eblanton@cs.purdue.edu

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights 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; nor does it represent that
   it has made any independent effort to identify any such rights.
   Information on the procedures with respect to rights in RFC
   documents can be found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
   specification can be obtained from the IETF on-line IPR repository
   at http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at

Disclaimer of Validity

   This document and the information contained herein are provided on an

Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Bhandarkar/et. al.         Expires August 2005                 [Page 14]

draft-ietf-tcpm-tcp-dcr-03                                 February 2005

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Bhandarkar/et. al.         Expires August 2005                 [Page 15]