Protocol Action: A Conservative SACK-based Loss Recovery Algorithm for TCP to Proposed Standard

The IESG <iesg-secretary@ietf.org> Wed, 12 February 2003 00:56 UTC

Received: from ran.ietf.org (ran.ietf.org [10.27.6.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23342; Tue, 11 Feb 2003 19:56:41 -0500 (EST)
Received: from majordomo by ran.ietf.org with local (Exim 4.10) id 18ilBT-0005pl-00 for ietf-announce-list@ran.ietf.org; Tue, 11 Feb 2003 19:55:31 -0500
Received: from odin.ietf.org ([10.27.2.28] helo=ietf.org) by ran.ietf.org with esmtp (Exim 4.10) id 18ilBD-0005nN-00 for all-ietf@ran.ietf.org; Tue, 11 Feb 2003 19:55:15 -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23212; Tue, 11 Feb 2003 19:48:39 -0500 (EST)
Message-Id: <200302120048.TAA23212@ietf.org>
To: IETF-Announce:;
Cc: RFC Editor <rfc-editor@isi.edu>, Internet Architecture Board <iab@iab.org>, tsvwg@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: A Conservative SACK-based Loss Recovery Algorithm for TCP to Proposed Standard
Date: Tue, 11 Feb 2003 19:48:39 -0500
Sender: owner-ietf-announce@ietf.org
Precedence: bulk


The IESG has approved the Internet-Draft 'A Conservative SACK-based 
Loss Recovery Algorithm for TCP' <draft-allman-tcp-sack-13.txt> as a 
Proposed Standard. This document is the product of the Transport Area 
Working Group. The IESG contact persons are Scott Bradner and Allison 
Mankin.
   
Technical Summary
   
This document presents a conservative loss recovery algorithm for TCP
that is based on the use of the selective acknowledgment TCP option. 
The algorithm presented in this document conforms to the spirit of the 
current congestion control specification RFC2581, but allows TCP 
senders to recover more effectively when multiple segments are lost 
from a single flight of data.

Working Group Summary
   
The working group supported publishing of this document.
   
Protocol Quality
   
This document was reviewed for the IESG by Allison Mankin and Scott
Bradner.


RFC Editor Note:

 Please replace the following paragraph in section 2:
 For the purposes of this specification we define a ``duplicate
 acknowledgment'' as an acknowledgment (ACK) whose cumulative ACK
 number is equal to the current value of HighACK, as described in
 [RFC2581].

 with

 For the purposes of this specification we define a ``duplicate
 acknowledgment'' as a segment that arrives with no data and an
 acknowledgment (ACK) number that is equal to the current value
 of HighACK, as described in [RFC2581].

 also - please add the IPR notices from Sec 10.4(A) and 10.4(B)
 before the author's addresses