draft-ietf-tsvwg-dsack-use-02.txt   rfc3708.txt 
Internet Engineering Task Force Ethan Blanton Network Working Group E. Blanton
INTERNET DRAFT Purdue University Request for Comments: 3708 Purdue University
File: draft-ietf-tsvwg-dsack-use-02.txt Mark Allman Category: Experimental M. Allman
ICIR ICIR
October, 2003 February 2004
Expires: April, 2004
Using TCP DSACKs and SCTP Duplicate TSNs Using TCP Duplicate Selective Acknowledgement (DSACKs) and
to Detect Spurious Retransmissions Stream Control Transmission Protocol (SCTP) Duplicate
Transmission Sequence Numbers (TSNs) to Detect Spurious
Retransmissions
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This memo defines an Experimental Protocol for the Internet
all provisions of Section 10 of [RFC2026]. community. It does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Internet-Drafts are working documents of the Internet Engineering Distribution of this memo is unlimited.
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The Internet Society (2004). All Rights Reserved.
http://www.ietf.org/shadow.html.
Abstract Abstract
TCP and SCTP provide notification of duplicate segment receipt TCP and Stream Control Transmission Protocol (SCTP) provide
through DSACK and Duplicate TSN notification, respectively. This notification of duplicate segment receipt through Duplicate Selective
document presents conservative methods of using this information to Acknowledgement (DSACKs) and Duplicate Transmission Sequence Number
identify unnecessary retransmissions for various applications. (TSN) notification, respectively. This document presents
conservative methods of using this information to identify
Terminology unnecessary retransmissions for various applications.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
1 Introduction 1. Introduction
TCP [RFC793] and SCTP [RFC2960] provide notification of duplicate TCP [RFC793] and SCTP [RFC2960] provide notification of duplicate
segment receipt through duplicate selective acknowledgment (DSACK) segment receipt through duplicate selective acknowledgment (DSACK)
[RFC2883] and Duplicate TSN notifications, respectively. Using this [RFC2883] and Duplicate TSN notifications, respectively. Using this
information, a TCP or SCTP sender can generally determine when a information, a TCP or SCTP sender can generally determine when a
retransmission was sent in error. This document presents two retransmission was sent in error. This document presents two methods
methods for using duplicate notifications. The first method is for using duplicate notifications. The first method is simple and
simple and can be used for accounting applications. The second can be used for accounting applications. The second method is a
method is a conservative algorithm to disambiguate unnecessary conservative algorithm to disambiguate unnecessary retransmissions
retransmissions from loss events for the purpose of undoing from loss events for the purpose of undoing unnecessary congestion
unnecessary congestion control changes. control changes.
This document is intended to outline reasonable and safe algorithms This document is intended to outline reasonable and safe algorithms
for detecting spurious retransmissions and discuss some of the for detecting spurious retransmissions and discuss some of the
considerations involved. It is not intended to describe the only considerations involved. It is not intended to describe the only
possible method for achieving the goal, although the guidelines in possible method for achieving the goal, although the guidelines in
this document should be taken into consideration when designing this document should be taken into consideration when designing
alternate algorithms. Additionally, this document does not outline alternate algorithms. Additionally, this document does not outline
what a TCP or SCTP sender may do after a spurious retransmission is what a TCP or SCTP sender may do after a spurious retransmission is
detected. A number of proposals have been developed (e.g., detected. A number of proposals have been developed (e.g.,
[RFC3522], [SK03], [BDA03]), but it is not yet clear which of these [RFC3522], [SK03], [BDA03]), but it is not yet clear which of these
proposals are appropriate. In addition, they all rely on detecting proposals are appropriate. In addition, they all rely on detecting
spurious retransmits and so can share the algorithm specified in spurious retransmits and so can share the algorithm specified in this
this document. document.
Finally, we note that to simplify the text much of the following Finally, we note that to simplify the text much of the following
discussion is in terms of TCP DSACKs, while applying to both TCP and discussion is in terms of TCP DSACKs, while applying to both TCP and
SCTP. SCTP.
2 Counting Duplicate Notifications Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Counting Duplicate Notifications
For certain applications a straight count of duplicate notifications For certain applications a straight count of duplicate notifications
will suffice. For instance, if a stack simply wants to know (for will suffice. For instance, if a stack simply wants to know (for
some reason) the number of spuriously retransmitted segments, some reason) the number of spuriously retransmitted segments,
counting all duplicate notifications for retransmitted segments counting all duplicate notifications for retransmitted segments
should work well. Another application of this strategy is to should work well. Another application of this strategy is to monitor
monitor and adapt transport algorithms so that the transport is not and adapt transport algorithms so that the transport is not sending
sending large amounts of spurious data into the network. For large amounts of spurious data into the network. For instance,
instance, monitoring duplicate notifications could be used by the monitoring duplicate notifications could be used by the Early
Early Retransmit [AAAB03] algorithm to determine whether fast Retransmit [AAAB03] algorithm to determine whether fast
retransmitting [RFC2581] segments with a lower than normal duplicate retransmitting [RFC2581] segments with a lower than normal duplicate
ACK threshold is working, or if segment reordering is causing ACK threshold is working, or if segment reordering is causing
spurious retransmits. spurious retransmits.
More speculatively, duplicate notification has been proposed as an More speculatively, duplicate notification has been proposed as an
integral part of estimating TCP's total loss rate [AEO03] for the integral part of estimating TCP's total loss rate [AEO03] for the
purposes of mitigating the impact of corruption-based losses on purposes of mitigating the impact of corruption-based losses on
transport protocol performance. [EOA03] proposes altering the transport protocol performance. [EOA03] proposes altering the
transport's congestion response to the fraction of losses that are transport's congestion response to the fraction of losses that are
actually due to congestion by requiring the network to provide the actually due to congestion by requiring the network to provide the
corruption-based loss rate and making the transport sender estimate corruption-based loss rate and making the transport sender estimate
the total loss rate. Duplicate notifications are a key part of the total loss rate. Duplicate notifications are a key part of
estimating the total loss rate accurately [AEO03]. estimating the total loss rate accurately [AEO03].
3 Congestion/Duplicate Disambiguation Algorithm 3. Congestion/Duplicate Disambiguation Algorithm
When the purpose of detecting spurious retransmissions is to When the purpose of detecting spurious retransmissions is to "undo"
``undo'' unnecessary changes made to the congestion control state, unnecessary changes made to the congestion control state, as
as suggested in [RFC2883], the data sender ideally needs to suggested in [RFC2883], the data sender ideally needs to determine:
determine:
(a) That spurious retransmissions in a particular window of data do (a) That spurious retransmissions in a particular window of data do
not mask real segment loss (congestion). not mask real segment loss (congestion).
For example, assume segments N and N+1 are retransmitted even For example, assume segments N and N+1 are retransmitted even
though only segment N was dropped by the network (thus, segment though only segment N was dropped by the network (thus, segment
N+1 was needlessly retransmitted). When the sender receives the N+1 was needlessly retransmitted). When the sender receives the
notification that segment N+1 arrived more than once it can notification that segment N+1 arrived more than once it can
conclude that segment N+1 was needlessly resent. However, it conclude that segment N+1 was needlessly resent. However, it
cannot conclude that it is appropriate to revert the congestion cannot conclude that it is appropriate to revert the congestion
control state because the window of data contained at least one control state because the window of data contained at least one
valid congestion indication (i.e., segment N was lost). valid congestion indication (i.e., segment N was lost).
(b) That network duplication is not the cause of the duplicate (b) That network duplication is not the cause of the duplicate
notification. notification.
Determining whether a duplicate notification is caused by Determining whether a duplicate notification is caused by network
network duplication of a packet or a spurious retransmit is a duplication of a packet or a spurious retransmit is a nearly
nearly impossible task in theory. Since [Pax97] shows that impossible task in theory. Since [Pax97] shows that packet
packet duplication by the network is rare, the algorithm in this duplication by the network is rare, the algorithm in this section
section simply ceases to function when network duplication is simply ceases to function when network duplication is detected
detected (by receiving a duplication notification for a segment (by receiving a duplication notification for a segment that was
that was not retransmitted by the sender). not retransmitted by the sender).
The algorithm specified below gives reasonable, but not complete, The algorithm specified below gives reasonable, but not complete,
protection against both of these cases. protection against both of these cases.
We assume the TCP sender has a data structure to hold selective We assume the TCP sender has a data structure to hold selective
acknowledgment information (e.g., as outlined in [RFC3517]). The acknowledgment information (e.g., as outlined in [RFC3517]). The
following steps require an extension of such a 'scoreboard' to following steps require an extension of such a 'scoreboard' to
incorporate a slightly longer history of retransmissions than called incorporate a slightly longer history of retransmissions than called
for in [RFC3517]. The following steps MUST be taken upon the for in [RFC3517]. The following steps MUST be taken upon the receipt
receipt of each DSACK or duplicate TSN notification: of each DSACK or duplicate TSN notification:
(A) Check the corresponding sequence range or TSN to determine (A) Check the corresponding sequence range or TSN to determine
whether the segment has been retransmitted. whether the segment has been retransmitted.
(A.1) If the SACK scoreboard is empty (i.e., the TCP sender has (A.1) If the SACK scoreboard is empty (i.e., the TCP sender has
received no SACK information from the receiver) processing received no SACK information from the receiver) and the
of this DSACK MUST be terminated and the congestion control left edge of the incoming DSACK is equal to SND.UNA,
state MUST NOT be reverted during the current window of processing of this DSACK MUST be terminated and the
data. This clause intends to cover the case when an entire congestion control state MUST NOT be reverted during the
window of acknowledgments have been dropped by the network. current window of data. This clause intends to cover the
In such a case, the reverse path seems to be in a congested case when an entire window of acknowledgments have been
state and so reducing TCP's sending rate is the conservative dropped by the network. In such a case, the reverse path
approach. seems to be in a congested state and so reducing TCP's
sending rate is the conservative approach.
(A.2) If the segment was retransmitted exactly one time, mark it (A.2) If the segment was retransmitted exactly one time, mark it
as a duplicate. as a duplicate.
(A.3) If the segment was retransmitted more than once processing (A.3) If the segment was retransmitted more than once processing
of this DSACK MUST be terminated and the congestion control of this DSACK MUST be terminated and the congestion control
state MUST NOT be reverted to its previous state during the state MUST NOT be reverted to its previous state during the
current window of data. current window of data.
(A.4) If the segment was not retransmitted the incoming DSACK (A.4) If the segment was not retransmitted the incoming DSACK
indicates that the network duplicated the segment in indicates that the network duplicated the segment in
question. Processing of this DSACK MUST be terminated. In question. Processing of this DSACK MUST be terminated. In
addition, the algorithm specified in this document MUST NOT addition, the algorithm specified in this document MUST NOT
be used for the remainder of the connection, as future DSACK be used for the remainder of the connection, as future
reports may be indicating network duplication rather than DSACK reports may be indicating network duplication rather
unnecessary retransmission. Note that some techniques to than unnecessary retransmission. Note that some techniques
further disambiguate network duplication from unnecessary to further disambiguate network duplication from
retransmission (e.g., the TCP timestamp option [RFC1323]) unnecessary retransmission (e.g., the TCP timestamp option
may be used to refine the algorithm in this document [RFC1323]) may be used to refine the algorithm in this
further. Using such a technique in conjunction with an document further. Using such a technique in conjunction
algorithm similar to the one presented herein may allow for with an algorithm similar to the one presented herein may
the continued use of the algorithm in the face of duplicated allow for the continued use of the algorithm in the face of
segments. We do not delve into such an algorithm in this duplicated segments. We do not delve into such an
document due the current rarity of network duplication. algorithm in this document due the current rarity of
However, future work should include tackling this problem. network duplication. However, future work should include
tackling this problem.
(B) Assuming processing is allowed to continue (per the (A) rules), (B) Assuming processing is allowed to continue (per the (A) rules),
check all retransmitted segments in the previous window of data. check all retransmitted segments in the previous window of data.
(B.1) If all segments or chunks marked as retransmitted have (B.1) If all segments or chunks marked as retransmitted have also
also been marked as acknowledged and duplicated, we conclude been marked as acknowledged and duplicated, we conclude
that all retransmissions in the previous window of data were that all retransmissions in the previous window of data
spurious and no loss occurred. were spurious and no loss occurred.
(B.2) If any segment or chunk is still marked as retransmitted (B.2) If any segment or chunk is still marked as retransmitted
but not marked as duplicate, there are outstanding but not marked as duplicate, there are outstanding
retransmissions that could indicate loss within this window retransmissions that could indicate loss within this window
of data. We can make no conclusions based on this of data. We can make no conclusions based on this
particular DSACK/duplicate TSN notification. particular DSACK/duplicate TSN notification.
In addition to keeping the state mentioned in [RFC3517] (for TCP) In addition to keeping the state mentioned in [RFC3517] (for TCP) and
and [RFC2960] (for SCTP), an implementation of this algorithm must [RFC2960] (for SCTP), an implementation of this algorithm must track
track all sequence numbers or TSNs that have been acknowledged as all sequence numbers or TSNs that have been acknowledged as
duplicates. duplicates.
4 Related Work 4. Related Work
In addition to the mechanism for detecting spurious retransmits In addition to the mechanism for detecting spurious retransmits
outlined in this document, several other proposals for finding outlined in this document, several other proposals for finding
needless retransmits have been developed. needless retransmits have been developed.
[BA02] uses the algorithm outlined in this document as the basis for [BA02] uses the algorithm outlined in this document as the basis for
investigating several methods to make TCP more robust to reordered investigating several methods to make TCP more robust to reordered
packets. packets.
The Eifel detection algorithm [RFC3522] uses the TCP timestamp The Eifel detection algorithm [RFC3522] uses the TCP timestamp option
option [RFC1323] to determine whether the ACK for a given retransmit [RFC1323] to determine whether the ACK for a given retransmit is for
is for the original transmission or a retransmission. More the original transmission or a retransmission. More generally,
generally, [LK00] outlines the benefits of detecting spurious [LK00] outlines the benefits of detecting spurious retransmits and
retransmits and reverting from needless congestion control changes reverting from needless congestion control changes using the
using the timestamp-based scheme or a mechanism that uses a timestamp-based scheme or a mechanism that uses a "retransmit bit" to
"retransmit bit" to flag retransmits (and ACKs of retransmits). The flag retransmits (and ACKs of retransmits). The Eifel detection
Eifel detection algorithm can detect spurious retransmits more algorithm can detect spurious retransmits more rapidly than a DSACK-
rapidly than a DSACK-based scheme. However, the tradeoff is that based scheme. However, the tradeoff is that the overhead of the 12-
the overhead of the 12-byte timestamp option must be incurred in byte timestamp option must be incurred in every packet transmitted
every packet transmitted for Eifel to function. for Eifel to function.
The F-RTO scheme [SK03] slightly alters TCP's sending pattern The F-RTO scheme [SK03] slightly alters TCP's sending pattern
immediately following a retransmission timeout and then observes the immediately following a retransmission timeout and then observes the
pattern of the returning ACKs. This pattern can indicate whether pattern of the returning ACKs. This pattern can indicate whether the
the retransmitted segment was needed. The advantage of F-RTO is retransmitted segment was needed. The advantage of F-RTO is that the
that the algorithm only needs to be implemented on the sender side algorithm only needs to be implemented on the sender side of the TCP
of the TCP connection and that nothing extra needs to cross the connection and that nothing extra needs to cross the network (e.g.,
network (e.g., DSACKs, timestamps, special flags, etc.). The DSACKs, timestamps, special flags, etc.). The downside is that the
downside is that the algorithm is a heuristic that can be confused algorithm is a heuristic that can be confused by network pathologies
by network pathologies (e.g., duplication or reordering of key (e.g., duplication or reordering of key packets). Finally, note that
packets). Finally, note that F-RTO only works for spurious F-RTO only works for spurious retransmits triggered by the
retransmits triggered by the transport's retransmission timer. transport's retransmission timer.
Finally, [AP99] briefly investigates using the time between Finally, [AP99] briefly investigates using the time between
retransmitting a segment via the retransmission timeout and the retransmitting a segment via the retransmission timeout and the
arrival of the next ACK as an indicator of whether the retransmit arrival of the next ACK as an indicator of whether the retransmit was
was needed. The scheme compares this time delta with a fraction (f) needed. The scheme compares this time delta with a fraction (f) of
of the minimum RTT observed thus far on the connection. If the time the minimum RTT observed thus far on the connection. If the time
delta is less than f*minRTT then the retransmit is labeled delta is less than f*minRTT then the retransmit is labeled spurious.
spurious. When f=1/2 the algorithm identifies roughly 59% of the When f=1/2 the algorithm identifies roughly 59% of the needless
needless retransmission timeouts and identifies needed retransmits retransmission timeouts and identifies needed retransmits only 2.5%
only 2.5% of the time. As with F-RTO, this scheme only detects of the time. As with F-RTO, this scheme only detects spurious
spurious retransmits sent by the transport's retransmission timer. retransmits sent by the transport's retransmission timer.
5 Security Considerations 5. Security Considerations
It is possible for the receiver to falsely indicate spurious It is possible for the receiver to falsely indicate spurious
retransmissions in the case of actual loss, potentially causing a retransmissions in the case of actual loss, potentially causing a TCP
TCP or SCTP sender to inaccurately conclude that no loss took place or SCTP sender to inaccurately conclude that no loss took place (and
(and possibly cause inappropriate changes to the senders congestion possibly cause inappropriate changes to the senders congestion
control state). control state).
Consider the following scenario: A receiver watches every segment or Consider the following scenario: A receiver watches every segment or
chunk that arrives and acknowledges any segment that arrives out of chunk that arrives and acknowledges any segment that arrives out of
order by more than some threshold amount as a duplicate, assuming order by more than some threshold amount as a duplicate, assuming
that it is a retransmission. A sender using the above algorithm that it is a retransmission. A sender using the above algorithm will
will assume that the retransmission was spurious. assume that the retransmission was spurious.
The ECN nonce sum proposal [RFC3540] could possibly help mitigate The ECN nonce sum proposal [RFC3540] could possibly help mitigate the
the ability of the receiver to hide real losses from the sender with ability of the receiver to hide real losses from the sender with
modest extension. In the common case of receiving an original modest extension. In the common case of receiving an original
transmission and a spurious retransmit a receiver will have received transmission and a spurious retransmit a receiver will have received
the nonce from the original transmission and therefore can "prove" the nonce from the original transmission and therefore can "prove" to
to the sender that the duplication notification is valid. In the the sender that the duplication notification is valid. In the case
case when the receiver did not receive the original and is trying to when the receiver did not receive the original and is trying to
improperly induce the sender into transmitting at an inappropriately improperly induce the sender into transmitting at an inappropriately
high rate, the receiver will not know the ECN nonce from the high rate, the receiver will not know the ECN nonce from the original
original segment and therefore will probabilistically not be able to segment and therefore will probabilistically not be able to fool the
fool the sender for long. [RFC3540] calls for disabling nonce sums sender for long. [RFC3540] calls for disabling nonce sums on
on duplicate ACKs, which means that the nonce sum is not directly duplicate ACKs, which means that the nonce sum is not directly
suitable for use as a mitigation to the problem of receivers lying suitable for use as a mitigation to the problem of receivers lying
about DSACK information. However, future efforts may be able to use about DSACK information. However, future efforts may be able to use
[RFC3540] as a starting point for building protection should it be [RFC3540] as a starting point for building protection should it be
needed. needed.
Acknowledgments 6. Acknowledgments
Sourabh Ladha and Reiner Ludwig made several useful comments on an Sourabh Ladha and Reiner Ludwig made several useful comments on an
earlier version of this document. The second author thanks BBN earlier version of this document. The second author thanks BBN
Technologies and NASA's Glenn Research Center for supporting this Technologies and NASA's Glenn Research Center for supporting this
work. work.
Normative References 7. References
[RFC793] Jon Postel. Transmission Control Protocol. Std 7, RFC 7.1. Normative References
793. September 1981.
[RFC2960] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, V. 793, September 1981.
Paxson. Stream Control Transmission Protocol. October 2000.
[RFC2883] S. Floyd, J. Mahdavi, M. Mathis, M. Podolsky. An [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Extension to the Selective Acknowledgement (SACK) Option for Requirement Levels", BCP 14, RFC 2119, March 1997.
TCP. RFC 2883, July 2000.
Non-Normative References [RFC2883] Floyd, S., Mahdavi, J., Mathis, M. and M. Podolsky, "An
Extension to the Selective Acknowledgement (SACK) Option
for TCP", RFC 2883, July 2000.
[AAAB03] M. Allman, K. Avrachenkov, U. Ayesta, J. Blanton. Early [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Retransmit for TCP. Internet-Draft Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang,
draft-allman-tcp-early-rexmt-01.txt, June 2003. Work in L. and V. Paxson, "Stream Control Transmission Protocol",
progress. RFC 2960, October 2000.
[AEO03] Mark Allman, Wesley Eddy, Shawn Ostermann. Estimating Loss 7.2. Informative References
Rates With TCP. August 2003. Under submission.
[AAAB03] Allman, M., Avrachenkov, K., Ayesta, U. and J. Blanton,
"Early Retransmit for TCP", Work in Progress, June 2003.
[AEO03] Allman, M., Eddy, E. and S. Ostermann, "Estimating Loss
Rates With TCP", Work in Progress, August 2003.
[AP99] Allman, M. and V. Paxson, "On Estimating End-to-End Network [AP99] Allman, M. and V. Paxson, "On Estimating End-to-End Network
Path Properties", SIGCOMM 99. Path Properties", SIGCOMM 99.
[BA02] E. Blanton, M. Allman. On Making TCP More Robust to Packet [BA02] Blanton, E. and M. Allman. On Making TCP More Robust to
Reordering. ACM Computer Communication Review, 32(1), January Packet Reordering. ACM Computer Communication Review,
2002. 32(1), January 2002.
[BDA03] Ethan Blanton, Robert Dimond, Mark Allman. Practices for TCP [BDA03] Blanton, E., Dimond, R. and M. Allman, "Practices for TCP
Senders in the Face of Segment Reordering, February Senders in the Face of Segment Reordering", Work in
2003. Internet-Draft draft-blanton-tcp-reordering-00.txt (work Progress, February 2003.
in progress).
[EOA03] Wesley Eddy, Shawn Ostermann, Mark Allman. New Techniques [EOA03] Eddy, W., Ostermann, S. and M. Allman, "New Techniques for
for Making Transport Protocols Robust to Corruption-Based Making Transport Protocols Robust to Corruption-Based
Loss. July 2003. Under submission. Loss", Work in Progress, July 2003.
[LK00] R. Ludwig, R. H. Katz. The Eifel Algorithm: Making TCP [LK00] R. Ludwig, R. H. Katz. The Eifel Algorithm: Making TCP
Robust Against Spurious Retransmissions. ACM Computer Robust Against Spurious Retransmissions. ACM Computer
Communication Review, 30(1), January 2000. Communication Review, 30(1), January 2000.
[Pax97] V. Paxson. End-to-End Internet Packet Dynamics. In ACM [Pax97] V. Paxson. End-to-End Internet Packet Dynamics. In ACM
SIGCOMM, September 1997. SIGCOMM, September 1997.
[RFC1323] Van Jacobson, Robert Braden, David Borman. TCP Extensions [RFC1323] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions
for High Performance. RFC 1323. May 1992. for High Performance", RFC 1323, May 1992.
[RFC3517] Ethan Blanton, Mark Allman, Kevin Fall, Lili Wang. A [RFC3517] Blanton, E., Allman, M., Fall, K. and L. Wang, "A
Conservative Selective Acknowledgment (SACK)-based Loss Recovery Conservative Selective Acknowledgment (SACK)-based Loss
Algorithm for TCP, April 2003. RFC 3517. Recovery Algorithm for TCP", RFC 3517, April 2003.
[RFC3522] R. Ludwig, M. Meyer. The Eifel Detection Algorithm for [RFC3522] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm for
TCP, April 2003. RFC 3522. TCP," RFC 3522, April 2003.
[RFC3540] N. Spring, D. Wetherall, D. Ely. Robust Explicit [RFC3540] Spring, N., Wetherall, D. and D. Ely, "Robust Explicit
Congestion Notification (ECN) Signaling with Nonces, June 2003. Congestion Notification (ECN) Signaling with Nonces", RFC
RFC 3540. 3540, June 2003.
[SK03] P. Sarolahti, M. Kojo. F-RTO: An Algorithm for Detecting [SK03] Sarolahti, P. and M. Kojo, "F-RTO: An Algorithm for
Spurious Retransmission Timeouts with TCP and SCTP. Detecting Spurious Retransmission Timeouts with TCP and
Internet-Draft draft-sarolahti-tsvwg-tcp-frto-04.txt, June 2003. SCTP", Work in Progress, June 2003.
Work in progress.
Authors' Addresses: 8. Authors' Addresses
Ethan Blanton Ethan Blanton
Purdue University Computer Sciences Purdue University Computer Sciences
1398 Computer Science Building 1398 Computer Science Building
West Lafayette, IN 47907 West Lafayette, IN 47907
eblanton@cs.purdue.edu
EMail: eblanton@cs.purdue.edu
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
mallman@icir.org
EMail: mallman@icir.org
http://www.icir.org/mallman/ http://www.icir.org/mallman/
9. Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78 and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to
rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 

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