draft-ietf-tcpm-3517bis-01.txt   draft-ietf-tcpm-3517bis-02.txt 
Internet Engineering Task Force E. Blanton TCPM Working Group E. Blanton
INTERNET-DRAFT Purdue University INTERNET-DRAFT Purdue University
draft-ietf-tcpm-3517bis-01.txt M. Allman draft-ietf-tcpm-3517bis-02.txt M. Allman
ICSI Obsoletes: 3517 ICSI
L. Wang Intended status: Standards Track L. Wang
Juniper Networks Expires: September 2012 Juniper Networks
I. Jarvinen I. Jarvinen
M. Kojo M. Kojo
University of Helsinki University of Helsinki
Y. Nishida Y. Nishida
WIDE Project WIDE Project
January 26, 2012 March 26, 2012
A Conservative Selective Acknowledgment (SACK)-based A Conservative Selective Acknowledgment (SACK)-based
Loss Recovery Algorithm for TCP Loss Recovery Algorithm for TCP
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 40 skipping to change at page 1, line 40
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 May 22, 2012. This Internet-Draft will expire on September 23, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 44 skipping to change at page 2, line 44
straightforward SACK-based loss recovery strategy that follows the straightforward SACK-based loss recovery strategy that follows the
guidelines set in [RFC5681] and can safely be used in TCP guidelines set in [RFC5681] and can safely be used in TCP
implementations. Alternate SACK-based loss recovery methods can be implementations. Alternate SACK-based loss recovery methods can be
used in TCP as implementers see fit (as long as the alternate used in TCP as implementers see fit (as long as the alternate
algorithms follow the guidelines provided in [RFC5681]). Please algorithms follow the guidelines provided in [RFC5681]). Please
note, however, that the SACK-based decisions in this document (such note, however, that the SACK-based decisions in this document (such
as what segments are to be sent at what time) are largely decoupled as what segments are to be sent at what time) are largely decoupled
from the congestion control algorithms, and as such can be treated as from the congestion control algorithms, and as such can be treated as
separate issues if so desired. separate issues if so desired.
This document represents a revision of [RFC3517] to address several
situations that are not handled explicitly in that document. A
summary of the changes between this document and [RFC3517] can be
found in Section 9.
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]. [RFC2119].
2 Definitions 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]. [RFC5681].
The reader is assumed to be familiar with selective acknowledgments The reader is assumed to be familiar with selective acknowledgments
as specified in [RFC2018]. as specified in [RFC2018].
For the purposes of explaining the SACK-based loss recovery algorithm For the purposes of explaining the SACK-based loss recovery algorithm
we define six variables that a TCP sender stores: we define six variables that a TCP sender stores:
"HighACK" is the sequence number of the highest byte of data that "HighACK" is the sequence number of the highest byte of data that
has been cumulatively ACKed at a given point. has been cumulatively ACKed at a given point.
skipping to change at page 3, line 33 skipping to change at page 3, line 38
in the network. This is used during recovery for limiting the in the network. This is used during recovery for limiting the
sender's sending rate. The pipe variable allows TCP to use a sender's sending rate. The pipe variable allows TCP to use a
fundamentally different congestion control than specified in fundamentally different congestion control than specified in
[RFC5681]. The algorithm is often referred to as the "pipe [RFC5681]. The algorithm is often referred to as the "pipe
algorithm". algorithm".
"DupAcks" is the number of duplicate acknowledgments received "DupAcks" is the number of duplicate acknowledgments received
since the last cumulative acknowledgment. since the last cumulative acknowledgment.
For the purposes of this specification we define a "duplicate For the purposes of this specification we define a "duplicate
acknowledgment" as a segment that arrives carrying a SACK block which acknowledgment" as a segment that arrives carrying a SACK block that
identifies previously unacknowledged and un-SACKed octets between identifies previously unacknowledged and un-SACKed octets between
HighACK and HighData. Note that an ACK which carries new HighACK and HighData. Note that an ACK which carries new
SACK data is counted as a duplicate acknowledgment under this SACK data is counted as a duplicate acknowledgment under this
definition even if it carries new data, changes the advertised definition even if it carries new data, changes the advertised
window, or moves the cumulative acknowledgment point, which is window, or moves the cumulative acknowledgment point, which is
different from the definition of duplicate acknowledgment different from the definition of duplicate acknowledgment
in [RFC5681]. in [RFC5681].
We define a variable "DupThresh" that holds the number of duplicate We define a variable "DupThresh" that holds the number of duplicate
acknowledgments required to trigger a retransmission. Per [RFC5681] acknowledgments required to trigger a retransmission. Per [RFC5681]
skipping to change at page 6, line 44 skipping to change at page 6, line 50
5 Algorithm Details 5 Algorithm Details
Upon the receipt of any ACK containing SACK information, the Upon the receipt of any ACK containing SACK information, the
scoreboard MUST be updated via the Update () routine. scoreboard MUST be updated via the Update () routine.
If the incoming ACK is a cumulative acknowledgment, the TCP MUST If the incoming ACK is a cumulative acknowledgment, the TCP MUST
reset DupAcks to zero. reset DupAcks to zero.
If the incoming ACK is a duplicate acknowledgment per the definition If the incoming ACK is a duplicate acknowledgment per the definition
in Section 2 (regardless of its status as a cumulative acknowledgment), in Section 2 (regardless of its status as a cumulative
and the TCP is not currently in loss recovery, the TCP MUST increase acknowledgment), and the TCP is not currently in loss recovery, the
DupAcks by one and take the following steps: TCP MUST increase DupAcks by one and take the following steps:
(1) If DupAcks >= DupThresh, go to step (4). (1) If DupAcks >= DupThresh, go to step (4).
Note: This check covers the case when a TCP receives SACK Note: This check covers the case when a TCP receives SACK
information for multiple segments smaller than SMSS, which can information for multiple segments smaller than SMSS, which can
potentially prevent IsLost() (next step) from declaring a segment potentially prevent IsLost() (next step) from declaring a segment
as lost. as lost.
(2) If DupAcks < DupThresh but IsLost (HighACK + 1) returns (2) If DupAcks < DupThresh but IsLost (HighACK + 1) returns
true---indicating at least three segments have arrived above true---indicating at least three segments have arrived above
skipping to change at page 11, line 28 skipping to change at page 11, line 33
loss recovery, in order to keep the ACK clock going under certain loss recovery, in order to keep the ACK clock going under certain
circumstances involving loss at the end of the window. This circumstances involving loss at the end of the window. This
mechanism allows for no more than one segment of no larger than 1 mechanism allows for no more than one segment of no larger than 1
SMSS to be optimistically retransmitted per loss recovery. SMSS to be optimistically retransmitted per loss recovery.
Rule (3) of NextSeg() has been changed from MAY to SHOULD, to Rule (3) of NextSeg() has been changed from MAY to SHOULD, to
appropriately reflect the opinion of the authors and working group appropriately reflect the opinion of the authors and working group
that it should be left in, rather than out, if an implementor does that it should be left in, rather than out, if an implementor does
not have a compelling reason to do otherwise. not have a compelling reason to do otherwise.
10 IANA Considerations
This document has no actions for IANA.
Acknowledgments Acknowledgments
The authors wish to thank Sally Floyd for encouraging [RFC3517] The authors wish to thank Sally Floyd for encouraging [RFC3517]
and commenting on early drafts. The algorithm described in this and commenting on early drafts. The algorithm described in this
document is loosely based on an algorithm outlined by Kevin Fall document is loosely based on an algorithm outlined by Kevin Fall
and Sally Floyd in [FF96], although the authors of this document and Sally Floyd in [FF96], although the authors of this document
assume responsibility for any mistakes in the above text. assume responsibility for any mistakes in the above text.
[RFC3517] was co-authored by Kevin Fall, who provided crucial input [RFC3517] was co-authored by Kevin Fall, who provided crucial input
to that document and hence this follow-on work. to that document and hence this follow-on work.
skipping to change at page 11, line 50 skipping to change at page 12, line 5
Jamshid Mahdavi, Matt Mathis, Shawn Ostermann, Vern Paxson and Jamshid Mahdavi, Matt Mathis, Shawn Ostermann, Vern Paxson and
Venkat Venkatsubra provided valuable feedback on earlier versions Venkat Venkatsubra provided valuable feedback on earlier versions
of this document. of this document.
We thank Matt Mathis and Jamshid Mahdavi for implementing the We thank Matt Mathis and Jamshid Mahdavi for implementing the
scoreboard in ns and hence guiding our thinking in keeping track scoreboard in ns and hence guiding our thinking in keeping track
of SACK state. of SACK state.
The first author would like to thank Ohio University and the Ohio The first author would like to thank Ohio University and the Ohio
University Internetworking Research Group for supporting the bulk of University Internetworking Research Group for supporting the bulk of
his work on this project. his work on RFC 3517, from which this document is derived.
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, "TCP [RFC2018] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018, October 1996. Selective Acknowledgment Options", RFC 2018, October 1996.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
skipping to change at page 12, line 18 skipping to change at page 12, line 27
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[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
[AHKO97] Mark Allman, Chris Hayes, Hans Kruse, Shawn Ostermann, "TCP [AHKO97] Mark Allman, Chris Hayes, Hans Kruse, Shawn Ostermann, "TCP
Performance Over Satellite Links", Proceedings of the Fifth Performance Over Satellite Links", Proceedings of the Fifth
International Conference on Telecommunications Systems, International Conference on Telecommunications Systems,
Nashville, TN, March, 1997. Nashville, TN, March, 1997.
[All00] Mark Allman, "A Web Server's View of the Transport Layer", [All00] Mark Allman, "A Web Server's View of the Transport Layer",
ACM Computer Communication Review, 30(5), October 2000. ACM Computer Communication Review, 30(5), October 2000.
[CPNI309] Fernando Gont, "Security Assessment of the Transmission [CPNI309] Fernando Gont, "Security Assessment of the Transmission
Control Protocol (TCP)", CPNI Technical Note 3/2009, Control Protocol (TCP)", CPNI Technical Note 3/2009,
http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf, http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf,
February 2009. February 2009.
[Errata1610] Matt Mathis, "RFC Errata Report 1610 for RFC 2018", [Errata1610] Matt Mathis, "RFC Errata Report 1610 for RFC 2018",
http://www.rfc-editor.org/errata_search.php?eid=1610, http://www.rfc-editor.org/errata_search.php?eid=1610,
Verified 2008-12-09. Verified 2008-12-09.
[FF96] Kevin Fall and Sally Floyd, "Simulation-based Comparisons [FF96] Kevin Fall and Sally Floyd, "Simulation-based Comparisons
of Tahoe, Reno and SACK TCP", Computer Communication of Tahoe, Reno and SACK TCP", Computer Communication
Review, July 1996. Review, July 1996.
[Jac90] Van Jacobson, "Modified TCP Congestion Avoidance Algorithm", [Jac90] Van Jacobson, "Modified TCP Congestion Avoidance
Technical Report, LBL, April 1990. Algorithm", Technical Report, LBL, April 1990.
[PF01] Jitendra Padhye, Sally Floyd "Identifying the TCP Behavior [PF01] Jitendra Padhye, Sally Floyd "Identifying the TCP Behavior
of Web Servers", ACM SIGCOMM, August 2001. of Web Servers", ACM SIGCOMM, August 2001.
[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.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC
2914, September 2000. 2914, September 2000.
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, "Computing [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, "Computing
TCP's Retransmission Timer", RFC 6298, June 2011. TCP's Retransmission Timer", RFC 6298, June 2011.
[RFC3042] Allman, M., Balakrishnan, H, and S. Floyd, "Enhancing TCP's
Loss Recovery Using Limited Transmit", RFC 3042, January
2001.
[RFC3517] Blanton, E., Allman, M., Fall, K., and L. Wang, "A [RFC3517] Blanton, E., Allman, M., Fall, K., and L. Wang, "A
Conservative Selective Acknowledgment (SACK)-based Loss Conservative Selective Acknowledgment (SACK)-based Loss
Recovery Algorithm for TCP", RFC 3517, April 2003. Recovery Algorithm for TCP", RFC 3517, April 2003.
[RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's [RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's
Robustness to Blind In-Window Attacks", RFC 5961, August Robustness to Blind In-Window Attacks", RFC 5961, August
2010. 2010.
Authors' Addresses Authors' Addresses
Ethan Blanton Ethan Blanton
Purdue University Computer Sciences Purdue University Computer Sciences
305 N. University St. 305 N. University St.
West Lafayette, IN 47907 West Lafayette, IN 47907
EMail: eblanton@cs.purdue.edu EMail: elb@psg.com
Mark Allman Mark Allman
International Computer Science Institute International Computer Science Institute
1947 Center St. Suite 600 1947 Center St. Suite 600
Berkeley, CA 94704 Berkeley, CA 94704
Phone: 440-235-1792 Phone: 440-235-1792
EMail: mallman@icir.org EMail: mallman@icir.org
http://www.icir.org/mallman http://www.icir.org/mallman
 End of changes. 15 change blocks. 
21 lines changed or deleted 27 lines changed or added

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