A Conservative Loss Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCP
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: IETF-Announce <firstname.lastname@example.org> Cc: RFC Editor <email@example.com>, tcpm mailing list <firstname.lastname@example.org>, tcpm chair <email@example.com> Subject: Protocol Action: 'A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP' to Proposed Standard (draft-ietf-tcpm-3517bis-02.txt) The IESG has approved the following document: - 'A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP' (draft-ietf-tcpm-3517bis-02.txt) as Proposed Standard This document is the product of the TCP Maintenance and Minor Extensions Working Group. The IESG contact persons are Wesley Eddy and Martin Stiemerling. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-tcpm-3517bis/
Technical Summary This document specifies a loss recovery algorithm based on the use of TCP SACK option that conforms to the current TCP congestion control requirements. It is a revision of Proposed Standard RFC 3517, to provide clarifications and certain performance enhancements to the earlier specified algorithm. Working Group Summary The document was accepted for publication by the TCPM working group by clear consensus. The working group has extensively reviewed the earlier versions of the document, and the result represents the working group consensus. During the working group last call, there were no requests for changes and only comments were supportive of publication. Document Quality The document has employed the long-standing experience of various people working closely with simulated and native TCP SACK implementations. The current TCP SACK implementations are believed to apply closely similar algorithm than what described in this document, even though there may be implementation-specific variations. Personnel Document Shepherd is Pasi Sarolahti <firstname.lastname@example.org>. Responsible Area Director is Wesley Eddy <email@example.com>. RFC Editor Note (1) Please append to the abstract: "This document obsoletes RFC 3517 and describes changes from it." (2) Please generate a table of contents for the document; the authors did not use XML2RFC and have not attempted to generate one. (3) In Section 2's definition of "pipe", please change "The algorithm" to the "The algorithm for computing the value of pipe" (4) Please insert at the beginning of Section 4, two paragraphs that say: "This section describes a specific structure and control flow for implementing the TCP behavior described by this standard. The behavior is what is standardized, and this particular collection of functions is the strongly recommended means of implementing that behavior, though other approaches to achieving that behavior are feasible." "The definition of Sender Maximum Segment Size (SMSS) used in this section is provided in [RFC5681]."