draft-ietf-tsvwg-dsack-use-01.txt   draft-ietf-tsvwg-dsack-use-02.txt 
Internet Engineering Task Force Ethan Blanton Internet Engineering Task Force Ethan Blanton
INTERNET DRAFT Purdue University INTERNET DRAFT Purdue University
File: draft-ietf-tsvwg-dsack-use-01.txt Mark Allman File: draft-ietf-tsvwg-dsack-use-02.txt Mark Allman
BBN/NASA GRC ICIR
August, 2003 October, 2003
Expires: February, 2004 Expires: April, 2004
Using TCP DSACKs and SCTP Duplicate TSNs Using TCP DSACKs and SCTP Duplicate TSNs
to Detect Spurious Retransmissions 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 document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of [RFC2026]. all provisions of Section 10 of [RFC2026].
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 3, line 30 skipping to change at page 3, line 30
packet duplication by the network is rare, the algorithm in this packet duplication by the network is rare, the algorithm in this
section simply ceases to function when network duplication is section simply ceases to function when network duplication is
detected (by receiving a duplication notification for a segment detected (by receiving a duplication notification for a segment
that was not retransmitted by the sender). that was 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 MUST be taken upon the receipt of each DSACK or following steps require an extension of such a 'scoreboard' to
duplicate TSN notification: incorporate a slightly longer history of retransmissions than called
for in [RFC3517]. The following steps MUST be taken upon the
receipt 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) 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 during the current window of state MUST NOT be reverted during the current window of
data. This clause intends to cover the case when an entire data. This clause intends to cover the case when an entire
window of acknowledgments have been dropped by the network. window of acknowledgments have been dropped by the network.
skipping to change at page 5, line 40 skipping to change at page 5, line 42
TCP or SCTP sender to inaccurately conclude that no loss took place TCP or SCTP sender to inaccurately conclude that no loss took place
(and possibly cause inappropriate changes to the senders congestion (and 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 assume that the retransmission was spurious. will assume that the retransmission was spurious.
The ECN nonce sum proposal [RFC3540] would help mitigate the ability The ECN nonce sum proposal [RFC3540] could possibly help mitigate
of the receiver to hide real losses from the sender. In the common the ability of the receiver to hide real losses from the sender with
case of receiving an original transmission and a spurious retransmit modest extension. In the common case of receiving an original
a receiver will have received the nonce from the original transmission and a spurious retransmit a receiver will have received
transmission and therefore can "prove" to the sender that the the nonce from the original transmission and therefore can "prove"
duplication notification is valid. In the case when the receiver to the sender that the duplication notification is valid. In the
did not receive the original and is trying to improperly induce case when the receiver did not receive the original and is trying to
the sender into transmitting at an inappropriately high rate, the improperly induce the sender into transmitting at an inappropriately
receiver will not know the ECN nonce from the original segment and high rate, the receiver will not know the ECN nonce from the
therefore will probabilistically not be able to fool the sender for original segment and therefore will probabilistically not be able to
long. fool the sender for long. [RFC3540] calls for disabling nonce sums
on duplicate ACKs, which means that the nonce sum is not directly
suitable for use as a mitigation to the problem of receivers lying
about DSACK information. However, future efforts may be able to use
[RFC3540] as a starting point for building protection should it be
needed.
Acknowledgments Acknowledgments
Reiner Ludwig made several useful comments on an earlier version of Sourabh Ladha and Reiner Ludwig made several useful comments on an
this document. earlier version of this document. The second author thanks BBN
Technologies and NASA's Glenn Research Center for supporting this
work.
Normative References
[RFC793] Jon Postel. Transmission Control Protocol. Std 7, RFC
793. September 1981.
[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.
[RFC2883] S. Floyd, J. Mahdavi, M. Mathis, M. Podolsky. An
Extension to the Selective Acknowledgement (SACK) Option for
TCP. RFC 2883, July 2000.
Non-Normative References
References
[AAAB03] M. Allman, K. Avrachenkov, U. Ayesta, J. Blanton. Early [AAAB03] M. Allman, K. Avrachenkov, U. Ayesta, J. Blanton. Early
Retransmit for TCP. Internet-Draft Retransmit for TCP. Internet-Draft
draft-allman-tcp-early-rexmt-01.txt, June 2003. Work in draft-allman-tcp-early-rexmt-01.txt, June 2003. Work in
progress. progress.
[AEO03] Mark Allman, Wesley Eddy, Shawn Ostermann. Estimating Loss [AEO03] Mark Allman, Wesley Eddy, Shawn Ostermann. Estimating Loss
Rates With TCP. August 2003. Under submission. Rates With TCP. August 2003. Under submission.
[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.
skipping to change at page 6, line 35 skipping to change at page 7, line 5
for Making Transport Protocols Robust to Corruption-Based for Making Transport Protocols Robust to Corruption-Based
Loss. July 2003. Under submission. Loss. July 2003. Under submission.
[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.
[RFC793] Jon Postel. Transmission Control Protocol. Std 7, RFC
793. September 1981.
[RFC1323] Van Jacobson, Robert Braden, David Borman. TCP Extensions [RFC1323] Van Jacobson, Robert Braden, David Borman. TCP Extensions
for High Performance. RFC 1323. May 1992. for High Performance. RFC 1323. May 1992.
[RFC2883] S. Floyd, J. Mahdavi, M. Mathis, M. Podolsky. An
Extension to the Selective Acknowledgement (SACK) 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.
[RFC3517] Ethan Blanton, Mark Allman, Kevin Fall, Lili Wang. A [RFC3517] Ethan Blanton, Mark Allman, Kevin Fall, Lili Wang. A
Conservative Selective Acknowledgment (SACK)-based Loss Recovery Conservative Selective Acknowledgment (SACK)-based Loss Recovery
Algorithm for TCP, April 2003. RFC 3517. Algorithm for TCP, April 2003. RFC 3517.
[RFC3522] R. Ludwig, M. Meyer. The Eifel Detection Algorithm for [RFC3522] R. Ludwig, M. Meyer. The Eifel Detection Algorithm for
TCP, April 2003. RFC 3522. TCP, April 2003. RFC 3522.
[RFC3540] N. Spring, D. Wetherall, D. Ely. Robust Explicit [RFC3540] N. Spring, D. Wetherall, D. Ely. Robust Explicit
Congestion Notification (ECN) Signaling with Nonces, June 2003. Congestion Notification (ECN) Signaling with Nonces, June 2003.
RFC 3540. RFC 3540.
skipping to change at page 7, line 21 skipping to change at page 7, line 33
Authors' Addresses: 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 eblanton@cs.purdue.edu
Mark Allman Mark Allman
BBN Technologies/NASA Glenn Research Center ICSI Center for Internet Research
Lewis Field 1947 Center Street, Suite 600
21000 Brookpark Rd. MS 54-5 Berkeley, CA 94704-1198
Cleveland, OH 44135 Phone: 216-243-7361
Phone: 216-433-6586 mallman@icir.org
Fax: 216-433-8705 http://www.icir.org/mallman/
mallman@bbn.com
http://roland.grc.nasa.gov/~mallman
 End of changes. 

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