--- 1/draft-ietf-tcpm-3517bis-01.txt 2012-03-26 17:13:56.842671076 +0200 +++ 2/draft-ietf-tcpm-3517bis-02.txt 2012-03-26 17:13:56.870670952 +0200 @@ -1,23 +1,23 @@ -Internet Engineering Task Force E. Blanton +TCPM Working Group E. Blanton INTERNET-DRAFT Purdue University -draft-ietf-tcpm-3517bis-01.txt M. Allman - ICSI - L. Wang - Juniper Networks +draft-ietf-tcpm-3517bis-02.txt M. Allman +Obsoletes: 3517 ICSI +Intended status: Standards Track L. Wang +Expires: September 2012 Juniper Networks I. Jarvinen M. Kojo University of Helsinki Y. Nishida WIDE Project - January 26, 2012 + March 26, 2012 A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering @@ -29,21 +29,21 @@ 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 http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at 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 (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -85,28 +85,34 @@ straightforward SACK-based loss recovery strategy that follows the guidelines set in [RFC5681] and can safely be used in TCP implementations. Alternate SACK-based loss recovery methods can be used in TCP as implementers see fit (as long as the alternate algorithms follow the guidelines provided in [RFC5681]). Please note, however, that the SACK-based decisions in this document (such 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 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", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. 2 Definitions The reader is expected to be familiar with the definitions given in + [RFC5681]. The reader is assumed to be familiar with selective acknowledgments as specified in [RFC2018]. For the purposes of explaining the SACK-based loss recovery algorithm we define six variables that a TCP sender stores: "HighACK" is the sequence number of the highest byte of data that has been cumulatively ACKed at a given point. @@ -126,21 +132,21 @@ in the network. This is used during recovery for limiting the sender's sending rate. The pipe variable allows TCP to use a fundamentally different congestion control than specified in [RFC5681]. The algorithm is often referred to as the "pipe algorithm". "DupAcks" is the number of duplicate acknowledgments received since the last cumulative acknowledgment. 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 HighACK and HighData. Note that an ACK which carries new SACK data is counted as a duplicate acknowledgment under this definition even if it carries new data, changes the advertised window, or moves the cumulative acknowledgment point, which is different from the definition of duplicate acknowledgment in [RFC5681]. We define a variable "DupThresh" that holds the number of duplicate acknowledgments required to trigger a retransmission. Per [RFC5681] @@ -300,23 +305,23 @@ 5 Algorithm Details Upon the receipt of any ACK containing SACK information, the scoreboard MUST be updated via the Update () routine. If the incoming ACK is a cumulative acknowledgment, the TCP MUST reset DupAcks to zero. If the incoming ACK is a duplicate acknowledgment per the definition - in Section 2 (regardless of its status as a cumulative acknowledgment), - and the TCP is not currently in loss recovery, the TCP MUST increase - DupAcks by one and take the following steps: + in Section 2 (regardless of its status as a cumulative + acknowledgment), and the TCP is not currently in loss recovery, the + TCP MUST increase DupAcks by one and take the following steps: (1) If DupAcks >= DupThresh, go to step (4). Note: This check covers the case when a TCP receives SACK information for multiple segments smaller than SMSS, which can potentially prevent IsLost() (next step) from declaring a segment as lost. (2) If DupAcks < DupThresh but IsLost (HighACK + 1) returns true---indicating at least three segments have arrived above @@ -555,20 +559,24 @@ loss recovery, in order to keep the ACK clock going under certain circumstances involving loss at the end of the window. This mechanism allows for no more than one segment of no larger than 1 SMSS to be optimistically retransmitted per loss recovery. Rule (3) of NextSeg() has been changed from MAY to SHOULD, to appropriately reflect the opinion of the authors and working group that it should be left in, rather than out, if an implementor does not have a compelling reason to do otherwise. +10 IANA Considerations + + This document has no actions for IANA. + Acknowledgments The authors wish to thank Sally Floyd for encouraging [RFC3517] and commenting on early drafts. The algorithm described in this document is loosely based on an algorithm outlined by Kevin Fall and Sally Floyd in [FF96], although the authors of this document assume responsibility for any mistakes in the above text. [RFC3517] was co-authored by Kevin Fall, who provided crucial input to that document and hence this follow-on work. @@ -577,21 +585,21 @@ Jamshid Mahdavi, Matt Mathis, Shawn Ostermann, Vern Paxson and Venkat Venkatsubra provided valuable feedback on earlier versions of this document. We thank Matt Mathis and Jamshid Mahdavi for implementing the scoreboard in ns and hence guiding our thinking in keeping track of SACK state. The first author would like to thank Ohio University and the Ohio 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 [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC2018] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996. [RFC2026] Bradner, S., "The Internet Standards Process -- Revision @@ -619,56 +627,52 @@ February 2009. [Errata1610] Matt Mathis, "RFC Errata Report 1610 for RFC 2018", http://www.rfc-editor.org/errata_search.php?eid=1610, Verified 2008-12-09. [FF96] Kevin Fall and Sally Floyd, "Simulation-based Comparisons of Tahoe, Reno and SACK TCP", Computer Communication Review, July 1996. - [Jac90] Van Jacobson, "Modified TCP Congestion Avoidance Algorithm", - Technical Report, LBL, April 1990. + [Jac90] Van Jacobson, "Modified TCP Congestion Avoidance + Algorithm", Technical Report, LBL, April 1990. [PF01] Jitendra Padhye, Sally Floyd "Identifying the TCP Behavior of Web Servers", ACM SIGCOMM, August 2001. [RFC3782] Floyd, S., Henderson, T., and A. Gurtov, "The NewReno Modification to TCP's Fast Recovery Algorithm", RFC 3782, April 2004. [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000. [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, "Computing 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 Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP", RFC 3517, April 2003. [RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's Robustness to Blind In-Window Attacks", RFC 5961, August 2010. Authors' Addresses Ethan Blanton Purdue University Computer Sciences 305 N. University St. West Lafayette, IN 47907 - EMail: eblanton@cs.purdue.edu + EMail: elb@psg.com Mark Allman International Computer Science Institute 1947 Center St. Suite 600 Berkeley, CA 94704 Phone: 440-235-1792 EMail: mallman@icir.org http://www.icir.org/mallman