draft-ietf-tcpm-sack-recovery-entry-00.txt   draft-ietf-tcpm-sack-recovery-entry-01.txt 
Internet Engineering Task Force I. Jarvinen Internet Engineering Task Force I. Jarvinen
INTERNET-DRAFT M. Kojo INTERNET-DRAFT M. Kojo
draft-ietf-tcpm-sack-recovery-entry-00.txt University of Helsinki draft-ietf-tcpm-sack-recovery-entry-01.txt University of Helsinki
Intended status: Standards Track 19 October 2009 Intended status: Standards Track 8 March 2010
Expires: April 2010 Expires: September 2010
Using TCP Selective Acknowledgement (SACK) Information to Determine Using TCP Selective Acknowledgement (SACK) Information to Determine
Duplicate Acknowledgements for Loss Recovery Initiation Duplicate Acknowledgements for Loss Recovery Initiation
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79. the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 1, line 32 skipping to change at page 1, line 32
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." 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 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 on April 2010. This Internet-Draft will expire on September 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your publication of this document. Please review these documents
rights and restrictions with respect to this document. carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Abstract Abstract
This document describes a TCP sender algorithm to trigger loss This document describes a TCP sender algorithm to trigger loss
recovery based on the TCP Selective Acknowledgement (SACK) recovery based on the TCP Selective Acknowledgement (SACK)
information gathered on a SACK scoreboard instead of simply counting information gathered on a SACK scoreboard instead of simply counting
the number of arriving duplicate acknowledgements (ACKs) in the the number of arriving duplicate acknowledgements (ACKs) in the
traditional way. The given algorithm is more robust to ACK losses, traditional way. The given algorithm is more robust to ACK losses,
ACK reordering, missed duplicate acknowledgements due to delayed ACK reordering, missed duplicate acknowledgements due to delayed
acknowledgements, and extra duplicate acknowledgements due to acknowledgements, and extra duplicate acknowledgements due to
duplicated segments and out-of-window segments. The algorithm allows duplicated segments and out-of-window segments. The algorithm allows
not only a timely initiation of TCP loss recovery but also reduces not only a timely initiation of TCP loss recovery but also reduces
false fast retransmits. It has a low implementation cost on top of false fast retransmits. It has a low implementation cost on top of
the SACK scoreboard defined in RFC 3517. the SACK scoreboard defined in RFC 3517.
Table of Contents Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Conventions and Terminology. . . . . . . . . . . . . . . 6 1.1. Conventions and Terminology. . . . . . . . . . . . . . . 6
1.2. Definitions. . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Definitions. . . . . . . . . . . . . . . . . . . . . . . 7
2. Algorithm Details . . . . . . . . . . . . . . . . . . . . . . 6 2. Algorithm Details . . . . . . . . . . . . . . . . . . . . . . 7
3. Discussion. . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.1. Redefined IsLost (SeqNum). . . . . . . . . . . . . . . . 7
3.1. Small Segment Sender . . . . . . . . . . . . . . . . . . 8 2.2. The Algorithm. . . . . . . . . . . . . . . . . . . . . . 7
3.2. One Segment is Small . . . . . . . . . . . . . . . . . . 10 3. Discussion. . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3. SACK Capability Misbehavior. . . . . . . . . . . . . . . 10 3.1. Small Segment Sender . . . . . . . . . . . . . . . . . . 9
3.4. Compatibility with Duplicate ACK based Loss 3.2. SACK Capability Misbehavior. . . . . . . . . . . . . . . 10
Recovery Algorithms . . . . . . . . . . . . . . . . . . . . . 10 3.3. Compatibility with Duplicate ACK based Loss
4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 Recovery Algorithms . . . . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 12
Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
A. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 12 A. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 12
A.1. Basic Case . . . . . . . . . . . . . . . . . . . . . . . 12 A.1. Basic Case . . . . . . . . . . . . . . . . . . . . . . . 12
A.2. Delayed ACK. . . . . . . . . . . . . . . . . . . . . . . 13 A.2. Delayed ACK. . . . . . . . . . . . . . . . . . . . . . . 13
A.3. ACK Losses . . . . . . . . . . . . . . . . . . . . . . . 14 A.3. ACK Loss . . . . . . . . . . . . . . . . . . . . . . . . 14
A.4. ACK Reordering . . . . . . . . . . . . . . . . . . . . . 14 A.4. ACK Reordering . . . . . . . . . . . . . . . . . . . . . 15
A.5. Packet Duplication . . . . . . . . . . . . . . . . . . . 15 A.5. Duplicated Packet. . . . . . . . . . . . . . . . . . . . 16
A.6. Mitigation of Blind Throughput Reduction A.6. Mitigation of Blind Throughput Reduction
Attack. . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Attack. . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
References . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Normative References . . . . . . . . . . . . . . . . . . . . . . 16 Normative References . . . . . . . . . . . . . . . . . . . . . . 16
Informative References . . . . . . . . . . . . . . . . . . . . . 16 Informative References . . . . . . . . . . . . . . . . . . . . . 17
AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . . . . 17 AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . . . . 18
TO BE DELETED BY THE RFC EDITOR UPON PUBLICATION: TO BE DELETED BY THE RFC EDITOR UPON PUBLICATION:
Changes from draft-ietf-tcpm-sack-recovery-entry-00.txt
* Mention setting of RecoveryPoint explicitly as this algorithm
depends on it being valid.
* Changed definition of IsLost (SeqNum) to be less strict.
* Changed packet ordering in one of the appendix examples, now it
makes more sense in the context of this algorithm. Point out in the
examples which of the transmissions are due to Limited Transmit and
Fast retransmit.
Changes from draft-jarvinen-tcpm-sack-recovery-entry-01.txt Changes from draft-jarvinen-tcpm-sack-recovery-entry-01.txt
* Clarified issues that based on feedback may cause confusion for * Clarified issues that based on feedback may cause confusion for
the reader. the reader.
* Incorporated handling of cumulative ACKs into the algorithm * Incorporated handling of cumulative ACKs into the algorithm
* 2581 refs -> 5681 * 2581 refs -> 5681
* Added early-rexmt ID as a related one, it uses SACK information * Added early-rexmt ID as a related one, it uses SACK information
skipping to change at page 5, line 35 skipping to change at page 5, line 43
simply counting the number of duplicate ACKs to trigger a loss simply counting the number of duplicate ACKs to trigger a loss
recovery fails in several cases to determine correctly the actual recovery fails in several cases to determine correctly the actual
number of valid out-of-order segments the receiver has successfully number of valid out-of-order segments the receiver has successfully
received. First, trusting on duplicate ACKs alone utterly fails to received. First, trusting on duplicate ACKs alone utterly fails to
get hold of the whole picture in case of ACK losses and ACK get hold of the whole picture in case of ACK losses and ACK
reordering, resulting in delayed or missed initiation of fast reordering, resulting in delayed or missed initiation of fast
retransmit and fast recovery. Similarly, the delayed ACK mechanism retransmit and fast recovery. Similarly, the delayed ACK mechanism
tends to conceal the first duplicate ACK as the delayed cumulative tends to conceal the first duplicate ACK as the delayed cumulative
ACK becomes combined with the first duplicate ACK when the first ACK becomes combined with the first duplicate ACK when the first
out-of-order segment arrives at the receiver (in case of an enlarged out-of-order segment arrives at the receiver (in case of an enlarged
ACK ratio such as with ACK congestion control [FARI08], even more ACK ratio such as with ACK congestion control [RFC5690], even more
significant portion is affected). Second, segment duplication or significant portion is affected). Second, segment duplication or
out-of-window segments increase the risk of falsely triggering loss out-of-window segments increase the risk of falsely triggering loss
recovery as they trigger duplicate ACKs. At worst, this legitimate recovery as they trigger duplicate ACKs. At worst, this legitimate
behavior on out-of-window segments can be turned into a blind behavior on out-of-window segments can be turned into a blind
throughput reduction attack [CPNI09]. Third, receiver window throughput reduction attack [CPNI09]. Third, receiver window
updates or opposite direction data segments cannot be counted as updates or opposite direction data segments cannot be counted as
duplicate ACKs with the traditional approach but can still contain duplicate ACKs with the traditional approach but can still contain
redundant SACK information that the sender could benefit from in a redundant SACK information that the sender could benefit from in a
scenario where the actual duplicate ACKs where lost. scenario where the actual duplicate ACKs where lost.
The algorithm specified in this document uses TCP Selective The algorithm specified in this document uses TCP Selective
Acknowledgement Option [RFC2018] to determine duplicate ACKs and to Acknowledgement Option [RFC2018] in the pre-recovery state to
trigger loss recovery based on the information gathered on the SACK determine duplicate ACKs and to trigger loss recovery based on the
scoreboard [RFC3517]. It works in the pre-recovery state giving a information gathered on the SACK scoreboard [RFC3517]. It gives a
more accurate heuristic for determining the number of out-of-order more accurate heuristic for determining the number of out-of-order
segments arrived at the TCP receiver. The information gathered on segments that have arrived at the TCP receiver. The information
the scoreboard reveals missing ACKs and allows detecting duplicate gathered on the SACK scoreboard reveals missing ACKs and allows
events. Therefore, the algorithm enables a timely triggering of Fast detecting duplicate events. Therefore, the algorithm enables a
Retransmit. In addition, it allows the use of Limited Transmit timely triggering of Fast Retransmit. In addition, it allows the use
[RFC3042] regardless of lost ACKs and also in the cases where the of Limited Transmit [RFC3042] accurately regardless of lost ACKs and
SACK information is piggybacked to a cumulative ACK due to delayed also in the cases where the SACK information is piggybacked to a
ACKs. This, in turn, allows keeping the ACK clock running more cumulative ACK due to delayed ACKs. This, in turn, improves the ACK
accurately. clock accuracy.
This algorithm is close to what Linux TCP implementation has used This algorithm is close to what Linux TCP implementation has used
for a very long time when in conservative SACK mode. A similar for a very long time when in conservative SACK mode. A similar
approach is briefly mentioned along ACK congestion control [FARI08] approach is briefly mentioned along ACK congestion control [RFC5690]
but as the usefulness of the algorithm in this document is more but as the usefulness of the algorithm in this document is more
general and not limited to ACK congestion control we specify it general and not limited to ACK congestion control we specify it
separately. We also note that the definition of a duplicate separately. We also note that the definition of a duplicate
acknowledgement already suggests that an incoming ACK can be acknowledgement already suggests that an incoming ACK can be
considered as a duplicate ACK if it "contains previously unknown considered as a duplicate ACK if it "contains previously unknown
SACK information" [RFC5681]. In addition, SACK information is used, SACK information" [RFC5681]. In addition, SACK information is used,
whenever available, for similar purpose by Early Retransmit whenever available, for similar purpose by Early Retransmit
[AAA+09]. [AAA+10].
This algorithm also resembles Forward Acknowledgement (FACK) [MM96] This algorithm also resembles Forward Acknowledgement (FACK) [MM96]
but they differ in how the quantity of data outstanding in the but they differ in how the quantity of data outstanding in the
network is determined. FACK always assumes that every non-SACKed network is determined. FACK always assumes that every non-SACKed
octet below the highest SACKed octet is lost which is only true if octet below the highest SACKed octet is lost which is only true if
no reordering occurs. Thus it would simply trigger loss recovery no reordering occurs. Thus it would simply trigger loss recovery
whenever the highest SACKed octet is more than dupThresh segments whenever the highest SACKed octet is more than dupThresh * SMSS
above SND.UNA. octets above SND.UNA.
1.1. Conventions and Terminology 1.1. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119] and indicate requirement levels for protocols. [RFC2119] and indicate requirement levels for protocols.
1.2. Definitions 1.2. Definitions
The reader is expected to be familiar with the definitions given in The reader is expected to be familiar with the definitions given in
[RFC5681], [RFC2018], and [RFC3517]. [RFC5681], [RFC2018], and [RFC3517].
2. Algorithm Details 2. Algorithm Details
In order to use this algorithm, a TCP sender MUST have TCP Selective In order to use this algorithm, a TCP sender MUST have TCP Selective
Acknowledgement Option [RFC2018] enabled and negotiated for the TCP Acknowledgement Option [RFC2018] enabled and negotiated for the TCP
connection. A TCP sender MUST maintain SACK information in an connection. The TCP sender MUST maintain SACK information in an
appropriate data structure such as scoreboard defined in [RFC3517]. appropriate data structure such as scoreboard defined in [RFC3517].
This algorithm uses functions Update(), and SetPipe () and variables
DupThresh, HighData, HighRxt, Pipe, and RecoveryPoint, as defined in
[RFC3517]. Note: the definition of IsLost (SeqNum) is altered from
the one specified in [RFC3517].
This algorithm uses functions IsLost (SeqNum), Update(), and SetPipe 2.1. Redefined IsLost (SeqNum)
() and variables DupThresh, HighData, HighRxt, Pipe, and
RecoveryPoint, as defined in [RFC3517].
A TCP sender using this algorithm MUST take following steps: IsLost (SeqNum) defined in [RFC3517] is stricter than necessary in
counting how many segments the receiver has received past SeqNum.
Instead of requiring at least three times SMSS bytes to be SACKed,
it is enough to have at least two times SMSS bytes plus one byte
SACKed to confirm that the receiver has received at least three
segments above SeqNum (and would have generated at least three
duplicate ACKs). The less strict definition is:
1) Upon the receipt of any ACK containing SACK information: IsLost (SeqNum):
If no previous loss event has occurred on the connection OR This routine returns whether the given sequence number is
considered to be lost. The routine returns true when either
DupThresh discontiguous SACKed sequences have arrived above
'SeqNum' or more than (DupThresh - 1) * SMSS bytes with sequence
numbers greater than 'SeqNum' have been SACKed. Otherwise, the
routine returns false.
2.2. The Algorithm
A TCP sender using this algorithm MUST take the following steps upon
the receipt of any ACK containing SACK information:
1) If no previous loss event has occurred on the connection OR
RecoveryPoint is less than SND.UNA (the oldest unacknowledged RecoveryPoint is less than SND.UNA (the oldest unacknowledged
sequence number [RFC793]), continue with the other steps of this sequence number [RFC793]), continue with the other steps of
algorithm. Otherwise, continue the ongoing loss recovery. this algorithm. Otherwise, continue the ongoing loss recovery.
2) Update the scoreboard via the Update () function as outlined in 2) Update the scoreboard via the Update () function as outlined
[RFC3517]. in [RFC3517].
3) If ACK is a cumulative ACK, reset duplicate ACK counter to zero. 3) If ACK is a cumulative ACK, reset duplicate ACK counter to zero.
4) If ACK contains SACK blocks with previously unknown in-window 4) If ACK contains SACK blocks with previously unknown in-window
(i.e., between SND.UNA and HighData, assuming SND.UNA has been SACK information (i.e., between SND.UNA and HighData, assuming
updated from the acknowledgment number of the ACK) SACK SND.UNA has been updated from the acknowledgment number of the
information, increase duplicate ACK counter. ACK), increase duplicate ACK counter.
5) Determinate if a loss recovery should be initiated: 5) Determinate if a loss recovery should be initiated:
If IsLost(SND.UNA) returns false AND the sender has received If IsLost (SND.UNA) returns false AND the sender has received
less than DupThresh duplicate ACKs, goto step 6A. Otherwise goto less than DupThresh duplicate ACKs, goto step 6A. Otherwise goto
step 6B. step 6B.
6A) Invoke optional Limited Transmit: 6A) Invoke optional Limited Transmit:
Set HighRxt to SND.UNA and run SetPipe(). The TCP sender MAY Set HighRxt to SND.UNA and run SetPipe(). The TCP sender MAY
transmit previously unsent data segments according the transmit previously unsent data segments according the
guidelines of Limited Transmit [RFC3042], with the exception guidelines of Limited Transmit [RFC3042], with the exception
that the amount of octets that can be send is determined by Pipe that the amount of octets that can be send is determined by Pipe
and cwnd. and cwnd.
If cwnd - pipe >= 1 SMSS, the TCP sender can transmit one or If cwnd - Pipe >= 1 SMSS, the TCP sender can transmit one or
more segments as follows: more segments as follows:
Send Loop: Send Loop:
a) If available unsent data exists and the receiver's advertised a) If available unsent data exists and the receiver's advertised
window allows, transmit one segment of up to SMSS octets of window allows, transmit one segment of up to SMSS octets of
previously unsent data starting with sequence number previously unsent data starting with sequence number
HighData+1 and update HighData to reflect the transmission of HighData+1 and update HighData to reflect the transmission of
the data segment. Otherwise, exit Send Loop. the data segment. Otherwise, exit Send Loop.
b) Run SetPipe() to re-calculate the number of outstanding b) Run SetPipe() to re-calculate the number of outstanding
octets in the network. If cwnd - pipe >= 1 SMSS, go to step octets in the network. If cwnd - Pipe >= 1 SMSS, go to step
a) of Send Loop. Otherwise, exit Send Loop. a) of Send Loop. Otherwise, exit Send Loop.
6B) Invoke Fast Retransmit and enter loss recovery: 6B) Invoke Fast Retransmit and enter loss recovery:
Initiate a loss recovery phase, per the fast retransmit Initiate a loss recovery phase, per the fast retransmit
algorithm outlined in [RFC5681] and continue with a fast algorithm outlined in [RFC5681], and continue with a fast
recovery algorithm, such as the SACK-based loss recovery recovery algorithm such as the SACK-based loss recovery
algorithm outlined in [RFC3517]. algorithm outlined in [RFC3517]. This includes setting
RecoveryPoint to HighData as in step (1) of [RFC3517].
3. Discussion 3. Discussion
In scenarios where no ACK losses nor reordering occur and the first In scenarios where no ACK losses nor reordering occur and the first
acknowledgement with SACK information is not the ACK held due to acknowledgement with SACK information is not the ACK held due to
delayed acknowledgements mechanism, the new SACK information with delayed acknowledgements mechanism, the new SACK information with
each duplicate ACK covers a single segment. In such a case, this each duplicate ACK covers a single segment. Those duplicate ACKs
algorithm will trigger loss recovery after three duplicate cause this algorithm to trigger loss recovery after three duplicate
acknowledgements and will allow transmission of a single new segment acknowledgements and will allow transmission of new segments using
using Limited Transmit on the first and second duplicate ACK. This Limited Transmit on the first and second duplicate ACK. This is
is identical to the behavior that would occur without this algorithm identical to the behavior that would occur without this algorithm
(assuming DupThresh is 3 and that all segments are SMSS sized). This (assuming DupThresh is 3 and that all segments are SMSS sized). This
scenario together with other scenarios describing the behavior of scenario together with other typical scenarios describing the
the algorithm are depicted in Appendix A. behavior of the algorithm are depicted in Appendix A.
This algorithm SHOULD be used also with an ACK that contains a This algorithm SHOULD be used also with an ACK that contains a
window update or opposite direction data that could not be window update or opposite direction data that could not be
considered as a duplicate ACK in the traditional algorithm. Such considered as a duplicate ACK in the traditional algorithm. Such
behavior is safe because the SACK information can only add more behavior is safe because the SACK information can only add more
information to the current state of the sender; at worst, all information to the current state of the sender; at worst, all
received information is just redundant. received information is just redundant.
Setting HighRxt to SND.UNA in Step 6A has no direct relation to this Setting HighRxt to SND.UNA in Step 6A has no direct relation to this
algorithm. Yet it is included in the algorithm to avoid confusion in algorithm. Yet it is included in the algorithm to avoid confusion in
how to implement SetPipe() correctly because it depends on having a how to implement SetPipe() correctly because it depends on having a
valid HighRxt value [RFC3517]. valid HighRxt value [RFC3517].
A set of potential issues to consider with the algorithm are A set of potential issues to consider with the algorithm are
discussed in the following. discussed in the following.
3.1. Small Segment Sender 3.1. Small Segment Sender
If a TCP sender is sending small segments (usually intentionally If a TCP sender is sending small segments (usually intentionally
overriding Nagle algorithm [RFC896]), the IsLost(SND.UNA) used in overriding Nagle algorithm [RFC896]), the IsLost (SND.UNA) used in
step 5 of the algorithm might fail to detect the need for loss step 5 of the algorithm might fail to detect the need for loss
recovery on the third duplicate acknowledgement because not enough recovery on the third duplicate acknowledgement because not enough
octets have been SACKed to cover DupThresh * SMSS bytes above octets have been SACKed to cover more than (DupThresh - 1) * SMSS
SND.UNA. Therefore, the traditional duplicate ACK algorithm is bytes above SND.UNA. Therefore, an adapted duplicate ACK algorithm
needed as a fallback. Steps 3, 4 and the latter condition of step 5 is needed as a fallback. Steps 3, 4 and the latter condition of step
implement the traditional algorithm in paraller to the SACK block 5 implement the adapted duplicate ACK algorithm in parallel to the
based detection. SACK block based detection.
The number of duplicate ACKs is an artificial metric to estimate the The number of duplicate ACKs is an artificial metric to estimate the
number of segments the receiver has already in its receive buffer. number of segments the receiver has already in its receive buffer.
How accurately they match depends on the scenario. Because of that, How accurately they match depends on the scenario. Because of that,
the goal of the duplicate ACK counter included into this algorithm the goal of the duplicate ACK counter included into this algorithm
is not to achieve bug-to-bug compatibility with the plain duplicate is not to achieve bug-to-bug compatibility with the plain duplicate
ACK counter but to estimate how many out-of-order segments the ACK counter but to estimate how many out-of-order segments the
receiver has already queued in a more accurate way. Therefore, the receiver has already queued in a more accurate way. Therefore, the
duplicate ACK counter used as a fallback mechanism in this algorithm duplicate ACK counter used as a fallback mechanism in this algorithm
differs from the plain duplicate ACK counter. However, such differs from the plain duplicate ACK counter. However, such
skipping to change at page 9, line 31 skipping to change at page 10, line 18
to accurately keep track of the receiver state. to accurately keep track of the receiver state.
While the fallback algorithm itself does not look into While the fallback algorithm itself does not look into
acknowledgment field in order to make a decision whether ACK is a acknowledgment field in order to make a decision whether ACK is a
"duplicate ACK", the duplicate ACK counter is not renamed in this "duplicate ACK", the duplicate ACK counter is not renamed in this
document as in practice most of ACKs that increment the counter document as in practice most of ACKs that increment the counter
would still contain a duplicate acknowledgment number. In contrast would still contain a duplicate acknowledgment number. In contrast
to the traditional approach, only condition that must be satisfied to the traditional approach, only condition that must be satisfied
to increment the duplicate ACK counter with this algorithm is that to increment the duplicate ACK counter with this algorithm is that
the acknowledgement MUST contain at least one in-window SACK block the acknowledgement MUST contain at least one in-window SACK block
that covers octets that where not previously SACKed [RFC5681]. In that covers octets that were not previously SACKed [RFC5681]. In
cases with ACK losses or delayed ACKs this condition can also match cases with ACK losses or delayed ACKs this condition can also match
to cumulative ACKs, receiver window updates and opposite direction to cumulative ACKs, receiver window updates and opposite direction
data segments but still the counter can safely be incremented. data segments but still the counter can safely be incremented.
Alternatively to the fallback algorithm, a TCP sender that is able Alternatively to the fallback algorithm, a TCP sender that is able
to discern segment boundaries accurately can consider full segments to discern segment boundaries accurately can consider full segments
in IsLost() regardless of segment size. Therefore, such a TCP in IsLost (SeqNum) regardless of segment size. Therefore, such a
sender can avoid the problem with small segments using TCP sender can avoid the problem with small segments using IsLost
IsLost(SND.UNA) check alone which means that Steps 3, 4 and the (SND.UNA) check alone which means that Steps 3, 4 and the latter
latter condition of step 5 are redundant and do not have to be condition of step 5 are redundant and not required to be
implemented. implemented.
Note: the small segments problem is not unique to this algorithm but Note: the small segments problem is not unique to this algorithm but
also the SACK-based loss recovery [RFC3517] encounters it because of also the SACK-based loss recovery [RFC3517] encounters it because of
how IsLost() is defined. how IsLost (SeqNum) is defined.
3.2. One Segment is Small
A variant of small segment sender case is the case where only one of
the SACKed segments is smaller than SMSS (possible even with Nagle
enabled). If TCP sender lacks ability to use the improved method by
discerning segment boundaries but still wants robustness against ACK
losses in this case, it MAY extend the condition in Step 5 with the
test:
SACKed octets > SMSS * (DupThresh - 1)
3.3. SACK Capability Misbehavior 3.2. SACK Capability Misbehavior
If the receiver represents such a SACK misbehavior that it If the receiver represents such a SACK misbehavior that it
advertises SACK capability but never sends any SACK blocks when it advertises SACK capability but never sends any SACK blocks when it
should, this algorithm fails to enter loss recovery and should, this algorithm fails to enter loss recovery and
retransmission timeout is required for recovery. However, such retransmission timeout is required for recovery. However, such
misbehavior does not allow SACK-based loss recovery [RFC3517] to misbehavior does not allow SACK-based loss recovery [RFC3517] to
work either, and a TCP sender will anyway require a timeout to work either, and a TCP sender will anyway require a timeout to
recover. recover if there was more than one lost data segment within the
window.
3.4. Compatibility with Duplicate ACK based Loss Recovery Algorithms 3.3. Compatibility with Duplicate ACK based Loss Recovery Algorithms
This algorithm SHOULD NOT be used together with a fast recovery This algorithm SHOULD NOT be used together with a fast recovery
algorithm that determines the segments that have left the network algorithm that determines the segments that have left the network
based on the number of arriving duplicate acknowledgements (e.g., based on the number of arriving duplicate acknowledgements (e.g.,
NewReno [RFC3782]), instead of the actual segments reported by SACK. NewReno [RFC3782]), instead of the actual segments reported by SACK.
In presence of ACK reordering such an algorithm will count the In presence of ACK reordering such an algorithm will count the
delayed duplicate acknowledgements during the fast recovery delayed duplicate acknowledgements during the fast recovery
algorithm as extra while determining the number of packets that have algorithm as extra while determining the number of packets that have
left the network. left the network.
skipping to change at page 11, line 9 skipping to change at page 11, line 34
Fast Retransmit sooner. Such behavior would only be useful when out- Fast Retransmit sooner. Such behavior would only be useful when out-
of-order segments have arrived because otherwise the flow undergoes of-order segments have arrived because otherwise the flow undergoes
a loss recovery with a window reduction. This kind of lying involves a loss recovery with a window reduction. This kind of lying involves
guessing which segments will arrive later. In case the guess was guessing which segments will arrive later. In case the guess was
wrong, the performance of the flow is ruined because the TCP sender wrong, the performance of the flow is ruined because the TCP sender
will need a retransmission timeout as it will not retransmit the will need a retransmission timeout as it will not retransmit the
segments until it assumes SACK reneging. On a successful guess the segments until it assumes SACK reneging. On a successful guess the
attacker is able to trigger the recovery slightly earlier. The later attacker is able to trigger the recovery slightly earlier. The later
segments would have allowed reporting the very same regions with segments would have allowed reporting the very same regions with
SACK anyway. Therefore, the gain from this attack is small, hardly SACK anyway. Therefore, the gain from this attack is small, hardly
justifiable considering the drastic effect of a misguess. Also, a justifiable considering the drastic effect of a misguess.
similar attack can be made with the duplicate acknowledgment based Furthermore, a similar attack can be made with the duplicate
algorithm (even if the new SACK information rule is applied) by acknowledgment based algorithm (even if the new SACK information
sending false duplicate acknowledgements with false SACK ranges, and rule is applied) by sending false duplicate acknowledgements with
trivially without the new SACK information rule. false SACK ranges, and trivially without the new SACK information
rule.
A variation of the lying attack discards reliability of the flow but A variation of the lying attack discards reliability of the flow but
as soon as the reliability is not a concern of the receiver, a as soon as the reliability is not a concern of the receiver, a
number of simpler ways exist to attack TCP independently of this number of simpler ways exist to attack TCP independently of this
algorithm. Thus this algorithm is not considered to weaken TCP algorithm. Thus this algorithm is not considered to weaken TCP
security properties against false information. security properties against false information.
Splitting SACK blocks into a smaller than the received segment sized Splitting SACK blocks into a smaller than the received segment sized
chunks allows the receiver to enable recovery to start sooner chunks allows the receiver to enable recovery to start sooner
because of IsLost() discontiguous check. However, by doing so the because of IsLost (SeqNum) discontiguous check. However, by doing so
receiver neglects the possiblity of reordering for a little gain. If the receiver neglects the possiblity of reordering for a little
the segment was just reordered, the sender performs unnecessary gain. If the segment was just reordered, the sender performs
window reduction and unnecessary retransmission of the reordered unnecessary window reduction and unnecessary retransmission of the
segment. Another variant of SACK block splitting simply tries to reordered segment. Another variant of SACK block splitting simply
increase consumption of bandwidth but with small dupThresh value tries to increase consumption of bandwidth by triggering a burst of
such as three the difference between sending three duplicate ACKs retransmissions falsely. However, the difference between sending
(traditional algorithm) and a single ACK with SACK blocks will not three duplicate ACKs (traditional algorithm) and a single ACK with
offer significant benefits to make such attack practical. In case SACK blocks will not offer significant benefits to make such an
the sender keeps track of segment boundaries and applies them in attack practical with a small DupThresh value such as three. In
IsLost(), these attack will not succeed as the sender cannot be case the sender keeps track of segment boundaries and applies them
mislead to believe that a segment was split into multiple chunks. in IsLost (SeqNum), such attack will not succeed as the sender
cannot be mislead to believe that a segment was split into multiple
chunks.
5. IANA Considerations 5. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
6. Acknowledgements 6. Acknowledgements
The authors would like to thank Alexander Zimmermann and Anna The authors would like to thank Alexander Zimmermann and Anna
Brunstrom for the comments on this document. Brunstrom for the comments on this document.
skipping to change at page 12, line 20 skipping to change at page 12, line 43
SMSS sized. SMSS sized.
Once the TCP receiver gets first out-of-order segment, it sends a Once the TCP receiver gets first out-of-order segment, it sends a
duplicate ACK with SACK information about the received octets. The duplicate ACK with SACK information about the received octets. The
following two out-of-order segments trigger a duplicate ACK each, following two out-of-order segments trigger a duplicate ACK each,
with the corresponding range SACKed in addition to the previously with the corresponding range SACKed in addition to the previously
know information. The sender gets those duplicate ACKs in-order, know information. The sender gets those duplicate ACKs in-order,
each of them will SACK a new previously unknown segment. each of them will SACK a new previously unknown segment.
This algorithm triggers loss recovery on third duplicate ACK because This algorithm triggers loss recovery on third duplicate ACK because
IsLost returns true as DupThresh * SMSS bytes became SACKed above IsLost (SeqNum) returns true as more than (DupThresh - 1) * SMSS
the SND.UNA on the same acknowledgement, thus the behavior is bytes become SACKed on the same acknowledgement, thus the behavior
identical to that of a sender which is using duplicate is identical to that of a sender which is using duplicate
acknowledgments. If Limited Transmit is in use, two first duplicate acknowledgments. If Limited Transmit is in use, two first duplicate
ACKs allow a single segment to be sent with either of the algorithms ACKs allow a single segment to be sent with either of the algorithms
(Pipe is decremented by SMSS by the SACKed octets per ACK allowing (Pipe is decremented by SMSS by the SACKed octets per ACK allowing
SMSS worth of new octets). SMSS worth of new octets).
ACK Transmitted Received ACK Sent ACK Transmitted Received ACK Sent
Received Segment Segment (Including SACK Blocks) Received Segment Segment (Including SACK Blocks)
1000 1000
3000-3499 3000-3499 (delayed ACK) 3000-3499 3000-3499 (delayed ACK)
skipping to change at page 12, line 44 skipping to change at page 13, line 24
2000 2000
4000-4499 (dropped) 4000-4499 (dropped)
4500-4999 4500-4999 4000, SACK=4500-5000 4500-4999 4500-4999 4000, SACK=4500-5000
3000 3000
5000-5499 5000-5499 4000, SACK=4500-5500 5000-5499 5000-5499 4000, SACK=4500-5500
5500-5999 5500-5999 4000, SACK=4500-6000 5500-5999 5500-5999 4000, SACK=4500-6000
4000 4000
6000-6499 6000-6499 4000, SACK=4500-6500 6000-6499 6000-6499 4000, SACK=4500-6500
6500-6999 6500-6999 4000, SACK=4500-7000 6500-6999 6500-6999 4000, SACK=4500-7000
4000, SACK=4500-5000 4000, SACK=4500-5000
7000-7499 7000-7499 4000, SACK=4500-7500 (lim. tr.) 7000-7499 7000-7499 4000, SACK=4500-7500
4000, SACK=4500-5500 4000, SACK=4500-5500
7500-7999 7500-7999 4000, SACK=4500-8000 (lim. tr.) 7500-7999 7500-7999 4000, SACK=4500-8000
4000, SACK=4500-6000 4000, SACK=4500-6000
4000-4499 4000-4499 8000 (fast retr.) 4000-4499 4000-4499 8000
4000, SACK=4500-6500 4000, SACK=4500-6500
A.2. Delayed ACK A.2. Delayed ACK
A basic case with delayed ACK send the first ACK with SACK The case with delayed ACK occurs when the receiver sends the first
information but since the previous ACK was sent with a lower ACK with SACK information but since the previous ACK was sent with a
sequence number because an acknowledgment is held by delayed ACK, lower sequence number because an acknowledgment is held by delayed
the sender will not considered it as duplicate ACK. Because the ACK, the sender will not considered it as duplicate ACK. Because the
segment contains SACK information that is identical to the basic segment contains SACK information that is identical to the basic
case, the sender can use Limited Transmit with the same segments as case, the sender can use Limited Transmit with the same segments as
in the basic case and will start loss recovery at the third in the basic case and will start loss recovery at the third
acknowledgment, i.e., with the second duplicate acknowledgment. In acknowledgment, i.e., with the second duplicate acknowledgment. In
the same situation the duplicate ACK based sender will have to wait the same situation the duplicate ACK based sender will have to wait
for one more duplicate ACK to arrive to do the same as the first for one more duplicate ACK to arrive to do the same as the first
acknowledgment is fully "wasted". acknowledgment is fully "wasted".
Technically an acknowledgement with a sequence number higher than Technically an acknowledgement with a sequence number higher than
what was previously acknowledged is not a duplicate acknowledgement what was previously acknowledged is not a duplicate acknowledgement
skipping to change at page 13, line 40 skipping to change at page 14, line 19
1500 1500
3000-3499 3000-3499 3500 3000-3499 3000-3499 3500
3500-3999 3500-3999 (delayed ACK) 3500-3999 3500-3999 (delayed ACK)
2500 2500
4000-4499 (dropped) 4000-4499 (dropped)
4500-4999 4500-4999 4000, SACK=4500-5000 4500-4999 4500-4999 4000, SACK=4500-5000
3500 3500
5000-5499 5000-5499 4000, SACK=4500-5500 5000-5499 5000-5499 4000, SACK=4500-5500
5500-5999 5500-5999 4000, SACK=4500-6000 5500-5999 5500-5999 4000, SACK=4500-6000
4000, SACK=4500-5000 4000, SACK=4500-5000 (two segments left the network)
6000-6499 6000-6499 4000, SACK=4500-6500 6000-6499 6000-6499 4000, SACK=4500-6500
6500-6999 6500-6999 4000, SACK=4500-7000 (lim. tr.) 6500-6999 6500-6999 4000, SACK=4500-7000
4000, SACK=4500-5500 4000, SACK=4500-5500
7000-7499 7000-7499 4000, SACK=4500-7500 (lim. tr.) 7000-7499 7000-7499 4000, SACK=4500-7500
4000, SACK=4500-6000 4000, SACK=4500-6000
4000-4499 4000-4499 7500 (fast retr.) 4000-4499 4000-4499 7500
4000, SACK=4500-6500 4000, SACK=4500-6500
A.3. ACK Losses A.3. ACK Loss
This case with ACK loss shares much behavior with the case with This case with ACK loss shares much behavior with the case with
delayed ACK. If hole at rcv.nxt is filled, the sender will notice delayed ACK. If hole at RCV.NXT is filled, the sender will notice
that cumulative ACK advanced. In case of out-of-order segments the that cumulative ACK advanced. In case of out-of-order segments the
first ACK which gets through to the sender includes SACK blocks up first ACK which gets through to the sender includes SACK blocks up
to the quantity the SACK block redundancy is able to cover. With to the quantity the SACK block redundancy is able to cover. With
this algorithm the sender immediately takes use of all the this algorithm the sender immediately takes use of all the
information that is made available by the incoming ACK. information that is made available by the incoming ACK.
ACK Transmitted Received ACK Sent ACK Transmitted Received ACK Sent
Received Segment Segment (Including SACK Blocks) Received Segment Segment (Including SACK Blocks)
1000 1000
skipping to change at page 14, line 28 skipping to change at page 15, line 4
1000 1000
3000-3499 3000-3499 (delayed ACK) 3000-3499 3000-3499 (delayed ACK)
3500-3999 3500-3999 4000 3500-3999 3500-3999 4000
2000 2000
4000-4499 (dropped) 4000-4499 (dropped)
4500-4999 4500-4999 4000, SACK=4500-5000 4500-4999 4500-4999 4000, SACK=4500-5000
(dropped) (dropped)
3000 3000
5000-5499 5000-5499 4000, SACK=4500-5500 5000-5499 5000-5499 4000, SACK=4500-5500
5500-5999 5500-5999 4000, SACK=4500-6000 5500-5999 5500-5999 4000, SACK=4500-6000
4000 4000
6000-6499 6000-6499 4000, SACK=4500-6500 6000-6499 6000-6499 4000, SACK=4500-6500
6500-6999 6500-6999 4000, SACK=4500-7000 6500-6999 6500-6999 4000, SACK=4500-7000
4000, SACK=4500-5500 (two segments left the network) 4000, SACK=4500-5500 (two segments left the network)
7000-7499 7000-7499 4000, SACK=4500-7500 (lim. tr.) 7000-7499 7000-7499 4000, SACK=4500-7500
7500-7999 7500-7999 4000, SACK=4500-8000 (lim. tr.) 7500-7999 7500-7999 4000, SACK=4500-8000
4000, SACK=4500-6000 4000, SACK=4500-6000
4000-4499 4000-4499 8000 (fast retr.) 4000-4499 4000-4499 8000
4000, SACK=4500-6500 4000, SACK=4500-6500
A.4. ACK Reordering A.4. ACK Reordering
With ACK reordering an ACK is postponed. Due to redundancy the next With ACK reordering an ACK is postponed. Due to redundancy the next
ACK after postponed one contains not only its own information but ACK after postponed one contains not only its own information but
also the information of the reordered ACK (similar to the ACK losses also the information of the reordered ACK (similar to the ACK losses
case). Then when the reordered ACK arrives, the sender already knows case). When the reordered ACK arrives later, the sender already
about the information it provides and therefore no actions are taken knows the information it provides and therefore no actions are taken
with this algorithm. with this algorithm.
ACK Transmitted Received ACK Sent ACK Transmitted Received ACK Sent
Received Segment Segment (Including SACK Blocks) Received Segment Segment (Including SACK Blocks)
1000 1000
3000-3499 3000-3499 (delayed ACK) 3000-3499 3000-3499 (delayed ACK)
3500-3999 3500-3999 4000 3500-3999 3500-3999 4000
2000 2000
4000-4499 (dropped) 4000-4499 (dropped)
4500-4999 4500-4999 4000, SACK=4500-5000 4500-4999 4500-4999 4000, SACK=4500-5000
(delayed) (delayed)
3000 3000
5000-5499 5000-5499 4000, SACK=4500-5500 5000-5499 5000-5499 4000, SACK=4500-5500
5500-5999 5500-5999 4000, SACK=4500-6000 5500-5999 5500-5999 4000, SACK=4500-6000
4000 4000
6000-6499 6000-6499 4000, SACK=4500-6500 6000-6499 6000-6499 4000, SACK=4500-6500
6500-6999 6500-6999 4000, SACK=4500-7000 6500-6999 6500-6999 4000, SACK=4500-7000
4000, SACK=4500-5500 4000, SACK=4500-5500 (two segments left the network)
7000-7499 7000-7499 4000, SACK=4500-7500 (lim. tr.) 7000-7499 7000-7499 4000, SACK=4500-7500
7500-7999 7500-7999 4000, SACK=4500-8000 (lim. tr.) 7500-7999 7500-7999 4000, SACK=4500-8000
4000, SACK=4500-6000
4000-4499 4000-4499 8000
4000, SACK=4500-5000 (has only redundant information) 4000, SACK=4500-5000 (has only redundant information)
4000, SACK=4500-6000
(fast retr.) 4000-4499 4000-4499 8000
4000, SACK=4500-6500 4000, SACK=4500-6500
A.5. Packet Duplication A.5. Duplicated Packet
Packet duplication happens either due to unnecessary retransmission A duplicate packet is received either due to unnecessary
or hardware duplication. It adds a redundant ACK which has only retransmission or hardware duplication. It adds a redundant ACK
redundant information or a data segment to the stream which will which has only redundant information or a data segment to the stream
triggers a redundant duplicate ACK (possibly with SACK and/or DSACK which will trigger a redundant duplicate ACK (possibly with SACK
[RFC2883] information). Because neither adds any new SACKed octets and/or DSACK [RFC2883] information). Because neither adds any new
at the sender, this algorithm will not do anything while duplicate SACKed octets at the TCP sender, this algorithm will not do anything
ACK based receiver would falsely consider it as a duplicate ACK. whereas a duplicate ACK based receiver would falsely consider it as
a duplicate ACK.
If one of the redundant ACKs is lost, the effect of duplication is If one of the redundant ACKs is lost, the effect of duplication is
just negated. just cancelled.
It is possible for the sender to detect this case using DSACK alone. It would be possible for the sender to detect this case using DSACK
alone.
A.6. Mitigation of Blind Throughput Reduction Attack A.6. Mitigation of Blind Throughput Reduction Attack
In case an attacker knows or is able to guess 4-tuple of a TCP In case an attacker knows or is able to guess 4-tuple of a TCP
connection, it may apply a blind throughput reduction attack connection, it may apply a blind throughput reduction attack
[CPNI09]. In this attack TCP is tricked to send duplicate ACK to [CPNI09]. In this attack TCP is tricked to send duplicate ACKs to
the other endpoint using out-of-window segments which it is the other endpoint using segments likely residing out-of-window that
considerably easier to achieve than a match with sequence numbers. is considerably easier to achieve than a match with sequence
If more than dupThresh duplicate ACKs can be triggered in row numbers. If more than dupThresh duplicate ACKs can be triggered in a
without any legimate segment that advances acknowledged sequence row without any legimate segment that advances acknowledged sequence
number, the other end acts according that false congestion signal number, the other end acts according to the false congestion signal
and halves the window. and halves the window.
With this algorithm such duplicate ACKs are filtered because they do With this algorithm such duplicate ACKs are filtered because they do
not have any new in-window SACK blocks (DSACK [RFC2883] might be not have any new in-window SACK blocks (DSACK [RFC2883] might be
present though). present though, but it does not cover in-window octets).
References References
Normative References Normative References
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981. 793, September 1981.
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow,
"TCP Selective Acknowledgment Options", RFC 2018, "TCP Selective Acknowledgment Options", RFC 2018,
skipping to change at page 16, line 36 skipping to change at page 17, line 21
[RFC3517] Blanton, E., Allman, M., Fall, K., and L. Wang, [RFC3517] Blanton, E., Allman, M., Fall, K., and L. Wang,
"A Conservative Selective Acknowledgment (SACK)-based "A Conservative Selective Acknowledgment (SACK)-based
Loss Recovery Algorithm for TCP", RFC 3517, April 2003. Loss Recovery Algorithm for TCP", RFC 3517, April 2003.
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
Control", RFC 5681, September 2009. Control", RFC 5681, September 2009.
Informative References Informative References
[AAA+09] Allman, M., Avrachenkov, K., Ayesta, U., Blanton, J., [AAA+10] Allman, M., Avrachenkov, K., Ayesta, U., Blanton, J.,
and P. Hurtig, "Early Retransmit for TCP and SCTP", and P. Hurtig, "Early Retransmit for TCP and SCTP",
Internet-Draft, draft-ietf-tcpm-early-rexmt-01, January Internet-Draft, draft-ietf-tcpm-early-rexmt-04, January
2009. 2010.
[CPNI09] Security Assessment of the Transmission Control Protocol [CPNI09] Security Assessment of the Transmission Control Protocol
(TCP). Available at: (TCP). Available at:
http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment- http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-
TCP.pdf TCP.pdf
[FARI08] Floyd, S., Arcia, A., Ros, D., and J. Iyengar, "Adding
Acknowledgement Congestion Control to TCP",
Internet-Draft, draft-floyd-tcpm-ackcc-06, July 2009.
[Jac88] Jacobson, V., "Congestion Avoidance and Control", In [Jac88] Jacobson, V., "Congestion Avoidance and Control", In
Proc. ACM SIGCOMM 88. Proceedings of ACM SIGCOMM '88, August 1988.
[MM96] M. Mathis, J. Mahdavi, "Forward Acknowledgment: Refining [MM96] M. Mathis, J. Mahdavi, "Forward Acknowledgment: Refining
TCP Congestion Control," Proceedings of SIGCOMM'96, August TCP Congestion Control," In Proceedings of SIGCOMM '96,
1996, Stanford, CA. August 1996.
[RFC896] Nagle, J., "Congestion Control in IP/TCP Internetworks", [RFC896] Nagle, J., "Congestion Control in IP/TCP Internetworks",
RFC 896, January 1984. RFC 896, January 1984.
[RFC2883] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An [RFC2883] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An
Extension to the Selective Acknowledgement (SACK) Option Extension to the Selective Acknowledgement (SACK) Option
for TCP", RFC 2883, July 2000. for TCP", RFC 2883, July 2000.
[RFC3782] Floyd, S., Henderson, T., and A. Gurtov, "The NewReno [RFC3782] Floyd, S., Henderson, T., and A. Gurtov, "The NewReno
Modification to TCP's Fast Recovery Algorithm", RFC 3782, Modification to TCP's Fast Recovery Algorithm", RFC 3782,
April 2004. April 2004.
[RFC5690] Floyd, S., Arcia, A., Ros, D., and J. Iyengar, "Adding
Acknowledgement Congestion Control to TCP", RFC 5690,
February 2010.
AUTHORS' ADDRESSES AUTHORS' ADDRESSES
Ilpo Jarvinen Ilpo Jarvinen
University of Helsinki University of Helsinki
P.O. Box 68 P.O. Box 68
FI-00014 UNIVERSITY OF HELSINKI FI-00014 UNIVERSITY OF HELSINKI
Finland Finland
Email: ilpo.jarvinen@helsinki.fi Email: ilpo.jarvinen@helsinki.fi
Markku Kojo Markku Kojo
 End of changes. 69 change blocks. 
166 lines changed or deleted 200 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/