draft-ietf-tcpm-tcp-dcr-03.txt   draft-ietf-tcpm-tcp-dcr-04.txt 
Internet Engineering Task Force Sumitha Bhandarkar Internet Engineering Task Force Sumitha Bhandarkar
INTERNET DRAFT A. L. Narasimha Reddy INTERNET DRAFT A. L. Narasimha Reddy
draft-ietf-tcpm-tcp-dcr-03.txt Texas A&M University draft-ietf-tcpm-tcp-dcr-04.txt Texas A&M University
Expires : August 2005 Mark Allman Expires : November 2005 Mark Allman
ICIR ICIR
Ethan Blanton Ethan Blanton
Purdue University Purdue University
February 2005 May 2005
Improving the Robustness of TCP to Non-Congestion Events Improving the Robustness of TCP to Non-Congestion Events
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire in August 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract: Abstract:
This document specifies Non-Congestion Robustness (NCR) for TCP. In This document specifies Non-Congestion Robustness (NCR) for TCP. In
the absence of explicit congestion notification from the network, the absence of explicit congestion notification from the network,
TCP's loss recovery algorithms treat the receipt of three duplicate TCP's loss recovery algorithms treat the receipt of three duplicate
acknowledgments as an implicit indication of congestion in the acknowledgments as an implicit indication of congestion in the
network. This is not always correct, notably in the case when network. This is not always correct, notably in the case when
network paths reorder segments (for whatever reason), resulting in network paths reorder segments (for whatever reason), resulting in
degraded performance. TCP-NCR is designed to mitigate this degraded degraded performance. TCP-NCR is designed to mitigate this degraded
performance by increasing the number of duplicate acknowledgments performance by increasing the number of duplicate acknowledgments
required to trigger loss recovery, based on the current state of the required to trigger loss recovery, based on the current state of the
connection, in an effort to disambiguate true segment loss from connection, in an effort to disambiguate true segment loss from
segment reordering. In addition, we specify a change to TCP's segment reordering. In addition, we specify an option, Aggressive
congestion reaction decision point, as well (but, do not require such Limited Transmit, where the TCP sender does not reduce its sending
a change to use NCR). This document specifies the changes to TCP, as rate until a segment is actually retransmitted; this would delay the
well as the costs and benefits of these modifications. reduction of the sending rate by roughly one round-trip time compared
to current TCP implementations. This document specifies the changes
to TCP, as well as the costs and benefits of these modifications.
Terminology Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described "OPTIONAL" in this document are to be interpreted as described
in [RFC2119]. in [RFC2119].
Readers should be familiar with the TCP terminology given in Readers should be familiar with the TCP terminology given in
[RFC2581] and [RFC3517]. [RFC2581] and [RFC3517].
1. Introduction 1. Introduction
One strength of TCP [RFC793] lies in its ability to adjust its One strength of TCP [RFC793] lies in its ability to adjust its
sending rate according to the perceived congestion in the network sending rate according to the perceived congestion in the network
[Jac88,RFC2581]. In the absence of explicit notification of [Jac88,RFC2581]. In the absence of explicit notification of
congestion from the network, TCP uses segment loss as an indication congestion from the network, TCP uses segment loss as an indication
of congestion (i.e., assuming queue overflow). TCP receivers send of congestion (i.e., assuming queue overflow). TCP receivers send
cumulative acknowledgments (ACKs) indicating the next sequence number cumulative acknowledgments (ACKs) indicating the next sequence number
expected from the sender for arriving segments [RFC793]. When expected from the sender for arriving segments [RFC793]. When
segments arrive out of order duplicate ACKs are generated. As segments arrive out-of-order, duplicate ACKs are generated. As
specified in [RFC2581], a TCP sender uses the arrival of three specified in [RFC2581], a TCP sender uses the arrival of three
duplicate ACKs as an indication of segment loss. The TCP sender duplicate ACKs as an indication of segment loss. The TCP sender
retransmits the lost segment and reduces the load imposed on the retransmits the lost segment and reduces the load imposed on the
network, assuming the segment loss was caused by resource contention network, assuming the segment loss was caused by resource contention
within the network path. The TCP sender does not assume loss on the 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 first or second duplicate ACK, but waits for three duplicate ACKs to
reordering. However, the use of this constant number of duplicate account for mild reordering. However, the use of this constant
ACKs has a number of implications that can be mitigated if the threshold of duplicate ACKs has several problems that can be
duplicate ACK requirement is changed. mitigated with a dynamic threshold.
The following is an example of TCP's behavior: The following is an example of TCP's behavior:
+ TCP A is the data sender and TCP B is the data receiver. + 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 + TCP A sends 10 segments each consisting of a single data byte
(i.e., transmits bytes 1-10 in segments 1-10). (i.e., transmits bytes 1-10 in segments 1-10).
+ Assume segment 3 is dropped in the network. + Assume segment 3 is dropped in the network.
skipping to change at page 3, line 26 skipping to change at page 3, line 24
is triggered by an out-of-order segment.) is triggered by an out-of-order segment.)
+ When TCP A receives the third duplicate ACK (or fourth ACK + When TCP A receives the third duplicate ACK (or fourth ACK
overall) for sequence number 3, TCP A will retransmit overall) for sequence number 3, TCP A will retransmit
segment 3 and reduce the sending rate by roughly half (see segment 3 and reduce the sending rate by roughly half (see
[RFC2581] for specifics on the congestion control state [RFC2581] for specifics on the congestion control state
adjustments). adjustments).
Alternatively, suppose segment 3 was not dropped by the network, but Alternatively, suppose segment 3 was not dropped by the network, but
rather delayed such that segment 3 arrives after segment 10. The rather delayed such that segment 3 arrives after segment 10. The
above scenario will play out in precisely the same manner. In other above scenario will play out in precisely the same manner insomuch as
words, TCP is not capable of disambiguating that level of packet a retransmission of segment 3 will be triggered. In other words, TCP
reordering from loss. is not capable of disambiguating this reordering event from a segment
loss.
The following is the specific motivation behind making TCP robust to The following is the specific motivation behind making TCP robust to
reordered segments: reordered segments:
* A number of Internet measurement studies have shown that packet * A number of Internet measurement studies have shown that packet
reordering is not a rare phenomenon [Pax97,BPS99,JIDKT03,GPL04]. reordering is not a rare phenomenon [Pax97,BPS99,JIDKT03,GPL04].
Further, the reordering can be well beyond that which fast Further, the reordering can be well beyond that required for
retransmit can cope with using the arrival of three duplicate fast retransmit to be falsely triggered.
ACKs to disambiguate loss and reordering.
* [BA02,ZKFP03] show the negative performance implications that * [BA02,ZKFP03] show the negative performance implications that
packet reordering has on current TCP. packet reordering has on current TCP.
* The requirement imposed by TCP for almost in-order packet * The requirement imposed by TCP for almost in-order packet
delivery places a severe constraint on the design of future delivery places a constraint on the design of future technology.
technology. Novel routing algorithms, network components, Novel routing algorithms, network components, link-layer
link-layer retransmission mechanisms and applications could all retransmission mechanisms and applications could all be looked
be looked at with a fresh perspective if TCP were to be more at with a fresh perspective if TCP were to be more robust to
robust to segment reordering. For instance, high speed packet segment reordering. For instance, high speed packet switches
switches could cause resequencing of packets if TCP were more could cause resequencing of packets if TCP were more robust.
robust. There has been work proposed in the literature There has been work proposed in the literature explicitly to
explicitly to ensure that packet ordering is maintained in such ensure that packet ordering is maintained in such switches
switches [KM02]. Also, link-layer mechanisms that attempt to [KM02]. Also, link-layer mechanisms that attempt to recover
recover from packet corruption by retransmitting could be from packet corruption by retransmitting could be allowed to
allowed to reorder packets and, hence, increase the chances of reorder packets and, hence, increase the chances of local loss
local loss repair rather than relying on TCP to repair the loss repair rather than relying on TCP to repair the loss (and,
(and, needlessly reduce its sending rate). Other examples are needlessly reduce its sending rate). Additional examples
multi-path routing, high-delay satellite links and some of the include multi-path routing, high-delay satellite links and some
schemes proposed for differentiated services architecture. By of the schemes proposed for differentiated services
making TCP more robust to non-congestion events, TCP-NCR may architecture. By making TCP more robust to non-congestion
open the design space of the future Internet components. 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 In this document we specify a set of TCP sender modifications to
Non-Congestion Robustness (NCR) to TCP. In particular, these changes provide Non-Congestion Robustness (NCR) to TCP. In particular, these
are built on top of TCP with selective acknowledgments (SACKs) changes are built on top of TCP with selective acknowledgments
[RFC2018] and the SACK-based loss recovery scheme given in [RFC3517], (SACKs) [RFC2018] and the SACK-based loss recovery scheme given in
since SACK is widely deployed at this point ([MAF04] indicates that [RFC3517], since SACK is widely deployed at this point ([MAF05]
68% of web servers and 88% of web clients utilize SACK as of spring, indicates that 68% of web servers and 88% of web clients utilize SACK
2004). as of spring, 2004).
The remainder of this document is organized as follows. In Section Finally, we note that the TCP-NCR algorithm provided in this document
2, we specify the TCP-NCR algorithm. Section 3 provides a brief could be easily adapted to SCTP [RFC2960] since SCTP uses congestion
overview of the benefits of TCP-NCR, while Section 4 discusses the control algorithms similar to TCP's (and, hence, has the same
drawbacks of TCP-NCR. Section 5 discusses related work. Section 6 reordering robustness issues).
discusses security concerns.
2. Algorithm The remainder of this document is organized as follows. Section 2
provides a high-level description of the TCP-NCR mechanisms. In
Section 3, we specify the TCP-NCR algorithm. Section 4 provides a
brief overview of the benefits of TCP-NCR, while Section 5 discusses
the drawbacks of TCP-NCR. Section 6 discusses related work. Section
7 discusses security concerns.
2. NCR Description
As discussed above, in the face of packet reordering three duplicate
ACKs may not be enough to disambiguate loss from reordering. In this
section we provide a non-normative sketch of TCP-NCR. The detailed
algorithms for implementing Non-Congestion Robustness for TCP are
presented in the next section.
The general idea behind TCP-NCR is to increase the threshold used to
trigger a fast retransmission from the current fixed value of three
duplicate ACKs [RFC2581] to approximately a congestion window of data
having left the network (but, not less than the currently
standardized value of three duplicate ACKs). Since cwnd represents
the amount of data a TCP flow can transmit in one round-trip time
(RTT), waiting to receive notice that cwnd bytes have left the
network before deciding whether the root cause is loss or reordering
imposes a delay of roughly one RTT. The appropriate choice for a new
value of the threshold is essentially a tradeoff between making the
best decision regarding the cause of the duplicate ACKs and
responsiveness. The choice to trigger a retransmission only after a
cwnd's worth of data is known to have left the network represents
roughly the largest amount of time a TCP can wait before the (often
costly) retransmission timeout may be triggered. Therefore, the
algorithm described in this document attempts to make the best root
cause decision possible.
Simply increasing the threshold before retransmitting a segment can
make TCP brittle to packet loss or ACK loss since such loss reduces
the number of duplicate ACKs that will arrive at the sender from the
receiver. For instance, if the cwnd is 10 segments and one segment
is lost, a duplicate ACK threshold of 10 will never be met because
duplicate ACKs corresponding to at most 9 segments will arrive at the
sender. To offset the issue of loss, we extend TCP's Limited
Transmit [RFC3042] scheme to allow for the sending of new data during
the period when the TCP sender is disambiguating loss and reordering.
This new data serves to increase the likelihood of enough duplicate
ACKs arriving at the sender to trigger loss recovery if it is
appropriate.
At this point we note that TCP tightly couples reliability and
congestion control -- when a segment is declared lost, a
retransmission is triggered and a change to sending rate is also made
on the assumption that the drop is due to resource contention
[RFC2581]. Therefore, by simply changing the retransmission trigger
the congestion control response is also changed. However, we lack
experience on the Internet as to whether delaying the point that a
rate reduction takes place is appropriate for wide-scale deployment.
Therefore, the extended Limited Transmit mechanism proposed in this
document offers two variants for experimentation.
The first Extended Limited Transmit variant, Careful Limited
Transmit, calls for the transmission of a previously unsent segment
for every two segments that are known to have left the network. This
has the effect of halving the sending rate since normal TCP operation
calls for the sending of one segment for every segment that has left
the network. Further, the halving starts immediately and is not
delayed until a retransmission is triggered. In the case of packet
reordering (i.e., not segment loss) the congestion control state is
restored to its previous state when reordering is determined.
The second variant, Aggressive Limited Transmit, calls for
transmitting a previously unsent data segment for every segment known
to have left the network. With this variant, while waiting to
disambiguate the loss from a reordering event, ACK-clocked
transmission continues at rougly the same rate as before the event
started. Retransmission and the sending rate reduction happen per
[RFC2581,RFC3517], albeit with the delayed threshold described above.
While this approach delays legitimate rate reductions (possibly
slightly and temporarily aggravating overall congestion on the
network) the scheme has the advantage of not reducing the
transmission rate in the face of segment reordering.
Which of the two Extended Limited Transmit variants is best for use
on the Internet is an open question.
3. Algorithm
The TCP-NCR modifications make two fundamental changes to the way The TCP-NCR modifications make two fundamental changes to the way
[RFC3517] currently operates, as follows. [RFC3517] currently operates, as follows.
First, the trigger for retransmitting a segment is changed from three First, the trigger for retransmitting a segment is changed from three
duplicate ACKs [RFC2581,RFC3517] to a congestion window's worth of duplicate ACKs [RFC2581,RFC3517] to indications that a congestion
duplicate ACKs. This provides more time for packet reordering to window's worth of data has left the network. Second, TCP-NCR
"work itself out" before the TCP sender infers that a segment has decouples initial congestion control decisions from retransmission
been lost and needs retransmitted. Setting the retransmission point decisions, in some cases delaying congestion control changes relative
is a balancing act. On the one hand, if the trigger is too to TCP's current behavior defined in [RFC2581]. The algorithm
aggressive (as is sometimes the situation in current TCP stacks using provides two alternatives for extending Limited Transmit. The two
three duplicate acknowledgments to trigger loss recovery), the TCP variants of extended Limited Transmit are:
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
algorithm provides two alternatives for extending Limited Transmit.
The two variants of extended Limited Transmit are:
Careful Limited Transmit: Careful Limited Transmit:
This variant calls for reducing the sending rate at This variant calls for reducing the sending rate at
approximately the same time [RFC2581] implementations reduce approximately the same time [RFC2581] implementations reduce
the congestion window, while at the same time withholding a the congestion window, while at the same time withholding a
retransmission (and the final congestion determination) for retransmission (and the final congestion determination) for
approximately one RTT. approximately one RTT.
Aggressive Limited Transmit: Aggressive Limited Transmit:
This variant calls for maintaining the sending rate in the This variant calls for maintaining the sending rate in the
face of duplicate ACKs until TCP concludes a segment is lost face of duplicate ACKs until TCP concludes a segment is lost
and needs to be retransmitted. (which, per the above, TCP-NCR and needs to be retransmitted (which TCP-NCR delays by one
delays by one RTT when compared with current loss recovery RTT when compared with current loss recovery schemes).
schemes).
TCP-NCR implementation MUST use either Careful Limited Transmit or A TCP-NCR implementation MUST use either Careful Limited Transmit or
Aggressive Limited Transmit. Aggressive Limited Transmit.
A constant MUST be set depending on which variant of extended Limited A constant MUST be set depending on which variant of extended Limited
Transmit is used, as follows: Transmit is used, as follows:
Careful Limited Transmit: Careful Limited Transmit:
LT_F = 2/3 LT_F = 2/3
Aggressive Limited Transmit: Aggressive Limited Transmit:
skipping to change at page 5, line 36 skipping to change at page 7, line 4
A constant MUST be set depending on which variant of extended Limited A constant MUST be set depending on which variant of extended Limited
Transmit is used, as follows: Transmit is used, as follows:
Careful Limited Transmit: Careful Limited Transmit:
LT_F = 2/3 LT_F = 2/3
Aggressive Limited Transmit: Aggressive Limited Transmit:
LT_F = 1/2 LT_F = 1/2
This constant reflects the fraction of outstanding data that must be This constant reflects the fraction of outstanding data that must be
ACKed before a retransmission is triggered. Since NCR's goal is to SACKed before a retransmission is triggered. Since Aggressive
wait roughly one RTT to retransmit, the fraction reflects the Limited Transmit sends a new segment for every segment known to have
different number of segments that will be transmitted during extended left the network, a total of roughly cwnd segments will be sent
Limited Transmit by the two schemes (and therefore their during Aggressive Limited Transmit and therefore ideally a total of
aggressiveness). 2*cwnd segments will be outstanding. The duplicate ACK threshold is
then set to LT_F = 1/2 of 2*cwnd (or about 1 RTT worth of data). The
factor is different for Careful Limited Transmit because the sender
only transmits one new segment for every two segments that are SACKed
and therefore will ideally have a total of 1.5*cwnd segments
outstanding when the retransmission is to be triggered. Hence, the
required threshold is LT_F=2/3 of 1.5*cwnd to delay the
retransmission by roughly 1 RTT.
There are situations whereby the sender cannot transmit new data
during Extended Limited Transmit (e.g., lack of data from the
application, receiver's advertised window limit). These situations
can lead to the problems discussed in the last section when a TCP
does not employ Extended Limited Transmit and is starved for ACKs.
Therefore, TCP-NCR adapts the duplicate ACK threshold on each SACK
arrival to be as robust as possible given the actual amount of data
that has been transmitted, or roughly LT_F times the number of
outstanding segments.
The TCP-NCR modifications specified in this document lend themselves The TCP-NCR modifications specified in this document lend themselves
to incremental deployment. Only the TCP implementation on the sender to incremental deployment. Only the TCP implementation on the sender
side requires modification. The changes themselves are modest. side requires modification. The changes themselves are modest.
However, as will be discussed below, availability of additional However, as will be discussed below, availability of additional
buffer space at the receiver will help maximize the benefits of using buffer space at the receiver will help maximize the benefits of using
TCP-NCR but are not strictly necessary. TCP-NCR but are not strictly necessary.
The following algorithms depend on the notions provided by [RFC3517] The following algorithms depend on the notions provided by [RFC3517]
and we assume the reader is familiar with the terminology given in and we assume the reader is familiar with the terminology given in
[RFC3517]. The TCP-NCR algorithm can be adapted to alternate SACK- [RFC3517]. The TCP-NCR algorithm can be adapted to alternate SACK-
based loss recovery schemes. [BR04,BSRV04] outline non-SACK-based based loss recovery schemes. [BR04,BSRV04] outline non-SACK-based
algorithms, however, we do not specify those algorithms in this algorithms, however, we do not specify those algorithms in this
document and do not recommend them due to both the complexity and document and do not recommend them due to both the complexity and
security implications of having only a gross understanding of the security implications of having only a gross understanding of the
number of outstanding segments in the network. number of outstanding segments in the network.
A TCP connection using the Nagle algorithm [RFC896,RFC1122] MAY A TCP connection using the Nagle algorithm [RFC896,RFC1122] MAY
employ the TCP-NCR algorithm. If a TCP implementation does implement employ the TCP-NCR algorithm. If a TCP implementation does implement
TCP-NCR the implementation MUST follow the various specifications TCP-NCR the implementation MUST follow the various specifications
provides in sections 2.1 - 2.4. If the Nagle algorithm is not being provided in sections 3.1 - 3.4. If the Nagle algorithm is not being
used there is no way to accurately calculate the number of used there is no way to accurately calculate the number of
outstanding segments in the network (and, therefore, no good way to outstanding segments in the network (and, therefore, no good way to
derive an appropriate duplicate ACK threshold). A TCP connection derive an appropriate duplicate ACK threshold) without adding state
that does not employ the Nagle algorithm MAY use TCP-NCR if the TCP to the TCP sender. A TCP connection that does not employ the Nagle
implementation tracks the sequence numbers transmitted in each algorithm SHOULD NOT use TCP-NCR. We envision that NCR could be
segment and the following algorithm is carefully adapted. adapted to an implementation that carefully tracks the sequence
numbers transmitted in each segment. However, we leave this as
future work.
2.1. Initialization 3.1. Initialization
When entering a period of loss / reordering detection and Extended When entering a period of loss / reordering detection and Extended
Limited Transmit a TCP-NCR MUST initialize several state variables. Limited Transmit a TCP-NCR MUST initialize several state variables.
A TCP MUST enter Extended Limited Transmit upon receiving the first 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 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 contain SACK information and (b) did increase the connection's
cumulative ACK point. The initializations are: cumulative ACK point. The initializations are:
(I.1) Save the current FlightSize. (I.1) Save the current FlightSize.
FlightSizePrev = FlightSize FlightSizePrev = FlightSize
(I.2) Set a variable for tracking the number of segments for which (I.2) Set a variable for tracking the number of segments for which
an ACK does not trigger a transmission during Careful Limited an ACK does not trigger a transmission during Careful Limited
Transmit. Transmit.
Skipped = 0 Skipped = 0
(Note: Skipped is not used during Aggressive Limited
Transmit.)
(I.3) Set DupThresh (from [RFC3517]) based on the size of the (I.3) Set DupThresh (from [RFC3517]) based on the size of the
current FlightSize. current FlightSize.
DupThresh = max (LT_F * (FlightSize / SMSS),3) DupThresh = max (LT_F * (FlightSize / SMSS),3)
Note: We keep the lower bound of DupThresh = 3 from Note: We keep the lower bound of DupThresh = 3 from
[RFC2581,RFC3517]. [RFC2581,RFC3517].
In addition to the above steps, the incoming ACK MUST be processed In addition to the above steps, the incoming ACK MUST be processed
with the E series of steps in section 2.3. with the E series of steps in section 3.3.
2.2. Terminating Extended Limited Transmit and Preventing Bursts 3.2. Terminating Extended Limited Transmit and Preventing Bursts
Extended Limited Transmit MUST be terminated at the start of loss Extended Limited Transmit MUST be terminated at the start of loss
recovery as outlined in section 2.4. recovery as outlined in section 3.4.
The arrival of an ACK that advances the cumulative ACK point before The arrival of an ACK that advances the cumulative ACK point while in
loss recovery is triggered signals that the series of duplicate ACKs Extended Limited Transmit, but before loss recovery is triggered
were caused by reordering and not congestion. Therefore, the receipt signals that a series of duplicate ACKs were caused by reordering and
of an ACK that extends the cumulative ACK point MUST terminate not congestion. Therefore, the receipt of an ACK that extends the
Extended Limited Transmit. As described below, an ACK that also cumulative ACK point MUST terminate Extended Limited Transmit. As
contains SACK information will also trigger the beginning of a new described below (in (T.4)), an ACK that extends the cumulative ACK
Extended Limited Transmit phase. Upon the termination of Extended point and *also* contains SACK information will also trigger the
Limited Transmit, and especially when using the Careful variant, TCP- beginning of a new Extended Limited Transmit phase.
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 Upon the termination of Extended Limited Transmit, and especially
segments into the network. Therefore, upon exiting Extended Limited when using the Careful variant, TCP-NCR may be in a situation where
Transmit the following steps MUST be taken. 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 When a TCP-NCR in the Extended Limited Transmit phase receives an ACK
that updates the cumulative ACK point (regardless of whether the ACK that updates the cumulative ACK point (regardless of whether the ACK
contains SACK information), the following steps MUST be taken: contains SACK information), the following steps MUST be taken:
(T.1) cwnd = min (FlightSize + SMSS,FlightSizePrev) (T.1) cwnd = min (FlightSize + SMSS,FlightSizePrev)
This step ensures that cwnd is not grossly larger than the This step ensures that cwnd is not grossly larger than the
amount of data outstanding --- a situation that would cause a amount of data outstanding --- a situation that would cause a
line rate burst. line rate burst.
(T.2) ssthresh = FlightSizePrev (T.2) ssthresh = FlightSizePrev
This step provides TCP-NCR with a sense of "history". If step This step provides TCP-NCR with a sense of "history". If step
(T.1) reduces cwnd below FlightSizePrev this step ensures that (T.1) reduces cwnd below FlightSizePrev this step ensures that
TCP-NCR will slow start back to operating point in effect TCP-NCR will slow start back to the operating point in effect
before Extended Limited Transmit. before Extended Limited Transmit.
(T.3) Transmit previously unsent data as allowed by cwnd, (T.3) Transmit previously unsent data as allowed by cwnd,
FlightSize, application data availability and the receiver's FlightSize, application data availability and the receiver's
advertised window. advertised window.
(T.4) When the cumulative ACK also contains SACK information, the (T.4) When the ACK extends the cumulative ACK point and also
initializations in steps (I.2) and (I.3) from section contains SACK information, the initializations in steps (I.2)
2.1 MUST be taken (but, not step (I.1)) to re-start Extended and (I.3) from section 3.1 MUST be taken (but, not step (I.1))
Limited Transmit. In addition, the series of steps in section to re-start Extended Limited Transmit. In addition, the
2.3 (the "E" steps) MUST be taken. series of steps in section 3.3 (the "E" steps) MUST be taken.
2.3. Extended Limited Transmit 3.3. Extended Limited Transmit
On each ACK containing SACK information that arrives after TCP-NCR On each ACK containing SACK information that arrives after TCP-NCR
has entered the Extended Limited Transmit phase (as outlined in has entered the Extended Limited Transmit phase (as outlined in
section 2.1) and before Extended Limited Transmit terminates, the section 3.1) and before Extended Limited Transmit terminates, the
sender MUST use the following procedure. sender MUST use the following procedure.
(E.1) Use the SetPipe () procedure from [RFC3517] to set the "pipe" (E.1) Use the SetPipe () procedure from [RFC3517] to set the "pipe"
variable (which represents the number of bytes still considered variable (which represents the number of bytes still considered
"in the network"). "in the network").
(E.2) If the following comparison holds and there are SMSS bytes of (E.2) If the comparison in equation (1) below holds and there are
previously unsent data available for transmission then SMSS bytes of previously unsent data available for
transmit one segment of SMSS bytes. transmission then transmit one segment of SMSS bytes.
(pipe + Skipped) <= (FlightSizePrev - SMSS) (pipe + Skipped) <= (FlightSizePrev - SMSS) (1)
If the comparison does not hold or no new data can be If the comparison in equation (1) does not hold or no new data
transmitted (due to lack of data from the application or the can be transmitted (due to lack of data from the application
advertised window limit), skip to step (E.6). or the advertised window limit), skip to step (E.6).
(E.3) Increment pipe by SMSS bytes. (E.3) Increment pipe by SMSS bytes.
(E.4) If using Careful Limited Transmit, increment Skipped by SMSS (E.4) If using Careful Limited Transmit, increment Skipped by SMSS
bytes to ensure that the next SMSS bytes of SACKed data bytes to ensure that the next SMSS bytes of SACKed data
processed do not trigger a Limted Transmit transmission (since processed do not trigger a Limited Transmit transmission (since
the goal of Careful Limited Transmit is to send upon the the goal of Careful Limited Transmit is to send upon the
reception of every second duplicate ACK). reception of every second duplicate ACK).
(E.5) Return to step (E.2) to ensure that as many bytes as (E.5) Return to step (E.2) to ensure that as many bytes as
appropriate are transmitted. This provides robustness to ACK appropriate are transmitted. This provides robustness to ACK
loss that can be (largely) compensated for using SACK loss that can be (largely) compensated for using SACK
information. information.
(E.6) Reset DupThresh via: (E.6) Reset DupThresh via:
DupThresh = max (LT_F * (FlightSize / SMSS),3) DupThresh = max (LT_F * (FlightSize / SMSS),3)
where FlightSize is the total number of bytes that have not where FlightSize is the total number of bytes that have not
been cumulatively acknowledged. been cumulatively acknowledged (which is different from
"pipe").
2.4 Entering Loss Recovery 3.4 Entering Loss Recovery
When a segment is deemed lost via the algorithms in [RFC3517], When a segment is deemed lost via the algorithms in [RFC3517],
Extended Limited Transmit MUST be terminated, leaving the Extended Limited Transmit MUST be terminated, leaving the
algoritms in [RFC3517] to govern TCP's behavior. One slight algoritms in [RFC3517] to govern TCP's behavior. One slight
change to [RFC3517] MUST be made, however. In section 5, step change to [RFC3517] MUST be made, however. In section 5, step
(2) of [RFC3517] MUST be changed to: (2) of [RFC3517] MUST be changed to:
(2) ssthresh = cwnd = (FlightSizePrev / 2) (2) ssthresh = cwnd = (FlightSizePrev / 2)
This ensures that the congestion control modifications are made This ensures that the congestion control modifications are made
with respect to the amount of data in the network before with respect to the amount of data in the network before
FlightSize was increased by Extended Limited Transmit. FlightSize was increased by Extended Limited Transmit.
3. Advantages 4. Advantages
The major advantages of TCP-NCR are two-fold. As discussed in The major advantages of TCP-NCR are two-fold. As discussed in
section 1, TCP-NCR will open up the design space for network section 1, TCP-NCR will open up the design space for network
applications and components that are currently constrained by TCP's applications and components that are currently constrained by TCP's
lack of robustness to packet reordering. The second advantage is in lack of robustness to packet reordering. The second advantage is in
terms of an increase in TCP performance. terms of an increase in TCP performance.
[BR04] presents ns-2 [NS-2] simulations of a pre-cursor to the TCP- [BR04] presents ns-2 [NS-2] simulations of a pre-cursor to the TCP-
NCR algorithm specified in this document, called TCP-DCR (Delayed NCR algorithm specified in this document, called TCP-DCR (Delayed
Congestion Response). The paper shows that TCP-DCR aids performance Congestion Response). The paper shows that TCP-DCR aids performance
in comparison to unmodified TCP in the presence of packet reordering. in comparison to unmodified TCP in the presence of packet reordering.
In addition, the extended version of [BR04] presents results based on In addition, the extended version of [BR04] presents results based on
emulations involving Linux (kernel 2.4.24). These results show that emulations involving Linux (kernel 2.4.24). These results show that
the performance of TCP-DCR is similar to Linux's native the performance of TCP-DCR is similar to Linux's native
implementation that seeks to "undo" wrong decisions based on DSACK implementation that seeks to "undo" wrong decisions based on DSACK
[RFC2883] feedback (similar to the schemes outlined in [ZKFP03]) when [RFC2883] feedback (similar to the schemes outlined in [ZKFP03]),
packets are reordered by less than one RTT. The advantages of using when packets are reordered by less than one RTT. The advantage of
TCP-DCR over the DSACK-based scheme is that the DSACK-based scheme using TCP-DCR over the DSACK-based scheme is that the DSACK-based
tries to estimate the exact amount of reordering in the network using scheme tries to estimate the exact amount of reordering in the
fairly complex algorithms, whereas TCP-DCR achieves similar results network using fairly complex algorithms, whereas TCP-DCR achieves
with less complicated modifications. similar results with less complicated modifications.
In addition, [BR04,BSRV04] illustrate the ability of TCP-DCR to allow In addition, [BR04,BSRV04] illustrate the ability of TCP-DCR to allow
for the improvement of other parts of the system. For example, these for the improvement of other parts of the system. For example, these
papers show that increasing TCP's robustness to packet reordering papers show that increasing TCP's robustness to packet reordering
allows for a novel wireless ARQ mechanism to be added at the link- 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 layer. The added robustness of the link-layer to channel errors, in
turn, increases TCP performance by not requiring TCP to retransmit turn, increases TCP performance by not requiring TCP to retransmit
packets that were dropped due to corruption (and, hence, also packets that were dropped due to corruption (and, hence, also
prevents TCP from needlessly reducing the sending rate when prevents TCP from needlessly reducing the sending rate when
retransmitting these segments). retransmitting these segments).
4. Disadvantages 5. Disadvantages
While we note that all of the changes outlined above are implemented 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 in the sender, the receiver also potentially has a part to play. In
particular, TCP-NCR increases the receiver's buffering requirement by particular, TCP-NCR increases the receiver's buffering requirement by
up to an extra cwnd -- in the case of the TCP sender using Aggressive up to an extra cwnd -- in the case of the TCP sender using Aggressive
Limited Transmit and actual loss occurring in the network. Limited Transmit and actual loss occurring in the network.
Therefore, to maximize the benefits from TCP-NCR receivers should Therefore, to maximize the benefits from TCP-NCR receivers should
advertise a large window to absorb the extra out-of-order traffic. In 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 the case that the additonal buffer requirements are not met, the use
of the above algorithm takes into account the reduced advertised of the above algorithm takes into account the reduced advertised
window, resulting in slighlty reduced robustness to reordering. (The window, resulting in slighlty reduced robustness to reordering.
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 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 application by up to one RTT because the fast retransmission point is
delayed by roughly one RTT in TCP-NCR. Applications that are delayed by roughly one RTT in TCP-NCR. Applications that are
sensitive to such delays should turn off the TCP-NCR option. sensitive to such delays should turn off the TCP-NCR option. For
instance, a socket option could be introduced to allow applications
to control whether NCR would be used for a particular connection.
Finally, the use of TCP-NCR makes the recovery from congestion events Finally, the use of TCP-NCR makes the recovery from congestion events
sluggish. While the simulation study presented in [BR04,BSRV04] shows sluggish in comparison to the standard reaction in [RFC2581]. [BR04,
that this does not have a significant impact further experimentation BSRV04] show (via simulation) that the delay in congestion response
on the real Internet is required to verify that result. has minimal impact on the connection itself and the traffic sharing a
bottleneck. [BBFS01] also indicates (again, via simulation) that
"slowly responsive" congestion control may be safe for deployment in
the Internet. These studies suggest that schemes that slightly delay
congestion control decisions may be reasonable, however, further
experimentation on the Internet is required to verify these results.
5. Related Work 6. Related Work
Over the past few years, several solutions have been proposed to Over the past few years, several solutions have been proposed to
improve the performance of TCP in the face of segment reordering. improve the performance of TCP in the face of segment reordering.
These schemes generally fall into one of two categories (with some These schemes generally fall into one of two categories (with some
overlap): mechanisms that try to prevent spurious retransmits from overlap): mechanisms that try to prevent spurious retransmits from
happening and mechanisms that try to detect spurious retransmits and happening and mechanisms that try to detect spurious retransmits and
"undo" the needless congestion control state changes that have been "undo" the needless congestion control state changes that have been
taken. taken.
[BA02,ZKFP03] attempt to prevent segment reordering from triggering [BA02,ZKFP03] attempt to prevent segment reordering from triggering
spurious retransmits by using various algorithms to approximate the spurious retransmits by using various algorithms to approximate the
duplicate ACK threshold required to disambiguate loss and reordering duplicate ACK threshold required to disambiguate loss and reordering
over the given network path. TCP-NCR similarly tries to prevent over a given network path at a given time. TCP-NCR similarly tries
spurious retransmits. However, TCP-NCR takes a simplified approach to prevent spurious retransmits. However, TCP-NCR takes a simplified
compared to those in [BA02,ZKFP03] in that TCP-NCR simply delays approach compared to those in [BA02,ZKFP03] in that TCP-NCR simply
retransmission by a fixed amount (in comparison to standard TCP), delays retransmission by a fixed amount (in comparison to standard
while the other schemes use relatively complex algorithms in an TCP), while the other schemes use relatively complex algorithms in an
attempt to derive a more precise value for DupThresh that depends on attempt to derive a more precise value for DupThresh that depends on
the network conditions. While TCP-NCR offers simplicity the other the network conditions. While TCP-NCR offers simplicity the other
schemes may offer more precision such that applications would not be schemes may offer more precision such that applications would not be
forced to wait as long for their retransmissions. forced to wait as long for their retransmissions. Future work could
be undertaken to achieve robustness without needless delay.
On the other hand, several schemes have been developed to detect and On the other hand, several schemes have been developed to detect and
mitigate needless retransmissions after the fact. mitigate needless retransmissions after the fact.
[RFC3522,RFC3708,BA02,LG04,SK04] present algorithms to detect [RFC3522,RFC3708,BA02,LG04,SK04] present algorithms to detect
spurious retransmits and mitigate the changes these events made to spurious retransmits and mitigate the changes these events made to
the congestion control state. TCP-NCR could be used in conjunction the congestion control state. TCP-NCR could be used in conjunction
with these algorithms, with TCP-NCR attempting to prevent spurious with these algorithms, with TCP-NCR attempting to prevent spurious
retransmits and some other scheme kicking in if the prevention retransmits and some other scheme kicking in if the prevention
failed. In addition, we note that TCP-NCR is concentrated on failed. In addition, we note that TCP-NCR is concentrated on
preventing spurious fast retransmits and some of the above algorithms preventing spurious fast retransmits and some of the above algorithms
also attempt to detect and mitigate spurious timeout-based also attempt to detect and mitigate spurious timeout-based
retransmits. retransmits.
6. Security Considerations 7. Security Considerations
We do not believe there are security implications involved with TCP- We do not believe there are security implications involved with TCP-
NCR over and above those for general TCP congestion control NCR over and above those for general TCP congestion control
[RFC2581]. In particular, the Extended Limited Transmit algorithms [RFC2581]. In particular, the Extended Limited Transmit algorithms
have been specifically designed to not be susceptible to the sorts of specified in this document have been specifically designed not to be
ACK splitting attacks TCP's general TCP congestion control is susceptible to the sorts of ACK splitting attacks TCP's general TCP
vulnerable to (as discussed in [RFC3465]. congestion control is vulnerable to (as discussed in [RFC3465].
8. Acknowledgements 8. Acknowledgements
Sally Floyd, Nauzad Sadry and Nitin Vaidya as well as feedback from Ted Faber, Sally Floyd, Nauzad Sadry, Pasi Sarolahti and Nitin Vaidya
from the TCPM working group have contributed significantly to this as well as feedback from from the TCPM working group have contributed
document. Our thanks to all! significantly to this document. Our thanks to all!
9. Normative References 9. Normative References
[RFC793] J. Postel, "Transmission Control Protocol", RFC 793, [RFC793] J. Postel, "Transmission Control Protocol", RFC 793,
September 1981. September 1981.
[RFC2018] M. Mathis, J. Mahdavi, S. Floyd and A. Romanow, "TCP [RFC2018] M. Mathis, J. Mahdavi, S. Floyd and A. Romanow, "TCP
selective acknowledgment options," Internet RFC 2018. selective acknowledgment options," Internet RFC 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 11, line 41 skipping to change at page 13, line 41
[RFC2581] M. Allman, V. Paxson, and W. Stevens, "TCP Congestion [RFC2581] M. Allman, V. Paxson, and W. Stevens, "TCP Congestion
Control", RFC 2581, April 1999. Control", RFC 2581, April 1999.
[RFC3042] M. Allman, H. Balakrishnan and S. Floyd, "Enhancing TCP's [RFC3042] M. Allman, H. Balakrishnan and S. Floyd, "Enhancing TCP's
Loss Recovery Using Limited Transmit", RFC 3042, January 2001. Loss Recovery Using Limited Transmit", RFC 3042, January 2001.
[RFC3517] E. Blanton, M. Allman, K. Fall and L. Wang, "A Conservative [RFC3517] E. Blanton, M. Allman, K. Fall and L. Wang, "A Conservative
Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for
TCP", RFC 3517, April 2003. TCP", RFC 3517, April 2003.
9. Informative References 10. Informative References
[BA02] E. Blanton and M. Allman, "On Making TCP More Robust to Packet [BA02] E. Blanton and M. Allman, "On Making TCP More Robust to Packet
Reordering," ACM Computer Communication Review, January 2002. Reordering," ACM Computer Communication Review, January 2002.
[BBFS01] D. Bansal, H. Balakrishnan, S. Floyd and S. Shenker,
"Dynamic Behavior of Slowly Responsive Congestion Control
Algorithms", Proceedings of ACM SIGCOMM, Sep. 2001.
[BPS99] J. Bennett, C. Partridge, and N. Shectman, "Packet reordering [BPS99] J. Bennett, C. Partridge, and N. Shectman, "Packet reordering
is not pat hological network behavior," IEEE/ACM Transactions on is not pat hological network behavior," IEEE/ACM Transactions on
Networking, December 1999. Networking, December 1999.
[BR04] Sumitha Bhandarkar and A. L. Narasimha Reddy, "TCP-DCR: Making [BR04] Sumitha Bhandarkar and A. L. Narasimha Reddy, "TCP-DCR: Making
TCP Robust to Non-Congestion Events", In the Proceedings of TCP Robust to Non-Congestion Events", In the Proceedings of
Networking 2004 conference, May 2004. Extended version available as Networking 2004 conference, May 2004. Extended version available as
tech report TAMU-ECE-2003-04. tech report TAMU-ECE-2003-04.
[BSRV04] Sumitha Bhandarkar, Nauzad Sadry, A. L. Narasimha Reddy and [BSRV04] Sumitha Bhandarkar, Nauzad Sadry, A. L. Narasimha Reddy and
skipping to change at page 12, line 29 skipping to change at page 14, line 33
Towsley, "Measurement and Classification of Out-of-Sequence Packets Towsley, "Measurement and Classification of Out-of-Sequence Packets
in a Tier-1 IP Backbone," Proceedings of IEEE INFOCOM, 2003. in a Tier-1 IP Backbone," Proceedings of IEEE INFOCOM, 2003.
[KM02] I. Keslassy and N. McKeown, "Maintaining packet order in [KM02] I. Keslassy and N. McKeown, "Maintaining packet order in
twostage switche s," Proceedings of the IEEE Infocom, June 2002 twostage switche s," Proceedings of the IEEE Infocom, June 2002
[LG04] R. Ludwig, A. Gurtov, "The Eifel Response Algorithm for TCP", [LG04] R. Ludwig, A. Gurtov, "The Eifel Response Algorithm for TCP",
Internet-Draft draft-ietf-tsvwg-tcp-eifel-response-06.txt (work in Internet-Draft draft-ietf-tsvwg-tcp-eifel-response-06.txt (work in
progress). September 2004. progress). September 2004.
[MAF04] A. Medina, M. Allman, S. Floyd. Measuring Interactions [MAF05] A. Medina, M. Allman, S. Floyd. Measuring the Evolution of
Between Transport Protocols and Middleboxes. ACM SIGCOMM/USENIX Transport Protocols in the Internet. ACM Computer Communication
Internet Measurement Conference, Taormina, Sicily, Italy, October Review, 35(2), April 2005.
2004.
[NS-2] ns-2 Network Simulator. http://www.isi.edu/nsnam/ [NS-2] ns-2 Network Simulator. http://www.isi.edu/nsnam/
[Pax97] V. Paxson, "End-to-End Internet Packet Dynamics," Proceedings [Pax97] V. Paxson, "End-to-End Internet Packet Dynamics," Proceedings
of ACM SIGCOMM, September 1997. of ACM SIGCOMM, September 1997.
[RFC896] J. Nagle, "Congestion Control in IP/TCP Internetworks", RFC [RFC896] J. Nagle, "Congestion Control in IP/TCP Internetworks", RFC
896, January 1984. 896, January 1984.
[RFC1122] R. Braden, "Requirements for Internet Hosts - Communication [RFC1122] R. Braden, "Requirements for Internet Hosts - Communication
Layers", RFC 1122, October 1989. Layers", RFC 1122, October 1989.
[RFC2883] Sally Floyd, Jamshid Mahdavi, Matt Mathis and Matt [RFC2883] Sally Floyd, Jamshid Mahdavi, Matt Mathis and Matt
Podolsky, "An Extension to the Selective Acknowledgement (SACK) Podolsky, "An Extension to the Selective Acknowledgement (SACK)
Option for TCP," RFC 2883, July 2000. Option for TCP," RFC 2883, July 2000.
[RFC2960] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H.
Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, V. Paxson.
Stream Control Transmission Protocol. October 2000.
[RFC2988] V. Paxson and M. Allman, "Computing TCP's Retransmission [RFC2988] V. Paxson and M. Allman, "Computing TCP's Retransmission
Timer", RFC 2988, November 2000. Timer", RFC 2988, November 2000.
[RFC3465] M. Allman. TCP Congestion Control with Appropriate Byte [RFC3465] M. Allman. TCP Congestion Control with Appropriate Byte
Counting (ABC), February 2003. RFC 3465. Counting (ABC), February 2003. RFC 3465.
[RFC3522] R. Ludwig and M. Meyer, "The Eifel Detection Algorithm for [RFC3522] R. Ludwig and M. Meyer, "The Eifel Detection Algorithm for
TCP," RFC 3522, April 2003. TCP," RFC 3522, April 2003.
[RFC3708] E. Blanton and M. Allman, "Using TCP Duplicate Selective [RFC3708] E. Blanton and M. Allman, "Using TCP Duplicate Selective
Acknowledgement (DSACKs) and Stream Control Transmission Protocol Acknowledgement (DSACKs) and Stream Control Transmission Protocol
(SCTP) Duplicate Transmission Sequence Numbers (TSNs) to Detect (SCTP) Duplicate Transmission Sequence Numbers (TSNs) to Detect
Spurious Retransmissions", RFC 3708, February 2004. Spurious Retransmissions", RFC 3708, February 2004.
[SK04] P. Sarolahti, M. Kojo, "Forward RTO-Recovery (F-RTO): An [SK04] P. Sarolahti, M. Kojo, "Forward RTO-Recovery (F-RTO): An
Algorithm for Detecting Spurious Retransmission Timeouts with TCP and Algorithm for Detecting Spurious Retransmission Timeouts with TCP and
SCTP", Internet-Draft draft-ietf-tcpm-frto-02.txt (work in progress). SCTP", Internet-Draft draft-ietf-tcpm-frto-02.txt (work in progress).
November 2004. November 2004.
[ZKFP03] M. Zhang, B. Karp, S. Floyd, L. Peterson, RR-TCP: A [ZKFP03] M. Zhang, B. Karp, S. Floyd, L. Peterson, "RR-TCP: A
Reordering-Robust TCP with DSACK, in Proceedings of the Eleventh IEEE Reordering-Robust TCP with DSACK", in Proceedings of the Eleventh
International Conference on Networking Protocols (ICNP 2003), IEEE International Conference on Networking Protocols (ICNP 2003),
Atlanta, GA, November, 2003. Atlanta, GA, November, 2003.
13. Author's Addresses 11. Author's Addresses
Sumitha Bhandarkar Sumitha Bhandarkar
Dept. of Elec. Engg. Dept. of Elec. Engg.
214 ZACH 214 ZACH
College Station, TX 77843-3128 College Station, TX 77843-3128
Phone: (512) 468-8078 Phone: (512) 468-8078
Email: sumitha@tamu.edu Email: sumitha@tamu.edu
URL : http://students.cs.tamu.edu/sumitha/ URL : http://students.cs.tamu.edu/sumitha/
A. L. Narasimha Reddy A. L. Narasimha Reddy
skipping to change at page 14, line 4 skipping to change at page 16, line 9
Email : reddy@ee.tamu.edu Email : reddy@ee.tamu.edu
URL : http://ee.tamu.edu/~reddy/ URL : http://ee.tamu.edu/~reddy/
Mark Allman Mark Allman
ICSI Center for Internet Research ICSI Center for Internet Research
1947 Center Street, Suite 600 1947 Center Street, Suite 600
Berkeley, CA 94704-1198 Berkeley, CA 94704-1198
Phone: (216) 243-7361 Phone: (216) 243-7361
Email: mallman@icir.org Email: mallman@icir.org
URL: http://www.icir.org/mallman/ URL: http://www.icir.org/mallman/
Ethan Blanton Ethan Blanton
Purdue University Computer Sciences Purdue University Computer Sciences
1398 Computer Science Building 250 North University Street
West Lafayette, IN 47907 West Lafayette, IN 47907
EMail: eblanton@cs.purdue.edu Email: eblanton@cs.purdue.edu
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed to
to pertain to the implementation or use of the technology described pertain to the implementation or use of the technology described in
in this document or the extent to which any license under such this document or the extent to which any license under such rights
rights might or might not be available; nor does it represent that might or might not be available; nor does it represent that it has
it has made any independent effort to identify any such rights. made any independent effort to identify any such rights. Information
Information on the procedures with respect to rights in RFC on the procedures with respect to rights in RFC documents can be
documents can be found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use attempt made to obtain a general license or permission for the use of
of such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository specification can be obtained from the IETF on-line IPR repository at
at http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity Disclaimer of Validity
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/