Protocol Action: 'A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP' to Proposed Standard (draft-ietf-tcpm-3517bis-02.txt)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <pasi.sarolahti@iki.fi>.
Responsible Area Director is Wesley Eddy <wes@mti-systems.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]."



[Index of Archives]     [IETF]     [IETF Discussion]     [Linux Kernel]

  Powered by Linux