[tcpm] RFC 2581 Clarification

"Leino, Tammy" <tammy_leino@mentor.com> Wed, 01 April 2009 20:27 UTC

Return-Path: <tammy_leino@mentor.com>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48B543A6C1E for <tcpm@core3.amsl.com>; Wed, 1 Apr 2009 13:27:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.002
X-Spam-Level:
X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vtf5ZBXbVH6t for <tcpm@core3.amsl.com>; Wed, 1 Apr 2009 13:27:30 -0700 (PDT)
Received: from relay1.mentorg.com (relay1.mentorg.com [192.94.38.131]) by core3.amsl.com (Postfix) with ESMTP id C85903A6AA5 for <tcpm@ietf.org>; Wed, 1 Apr 2009 13:27:30 -0700 (PDT)
Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1Lp730-0007cZ-RY from tammy_leino@mentor.com for tcpm@ietf.org; Wed, 01 Apr 2009 13:28:30 -0700
Received: from na2-mail.mgc.mentorg.com ([134.86.114.213]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 1 Apr 2009 13:28:30 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9B308.5E79C0AA"
Date: Wed, 01 Apr 2009 14:29:06 -0600
Message-ID: <2F83EB16CD718C43889CBCD31ECFD7F80215AA1C@na2-mail.mgc.mentorg.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: RFC 2581 Clarification
Thread-Index: AcmzCIEdWOEaUcnQTbGGwjl94osyWQ==
From: "Leino, Tammy" <tammy_leino@mentor.com>
To: tcpm@ietf.org
X-OriginalArrivalTime: 01 Apr 2009 20:28:30.0941 (UTC) FILETIME=[6BF9C0D0:01C9B308]
X-Mailman-Approved-At: Thu, 02 Apr 2009 08:04:09 -0700
Subject: [tcpm] RFC 2581 Clarification
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Apr 2009 20:27:34 -0000

Hello All,

 

Can someone please clarify what is meant by "a segment" in step 4 of
section 3.2 when discussing Fast Recovery:

 

   4.  Transmit a segment, if allowed by the new value of cwnd and the
       receiver's advertised window.

 

Specifically, could this "segment" be data on the retransmission queue
that has not been ACKed (or retransmitted by Fast Retransmit) or is this
"segment" only new data that has not yet been queued for retransmission?

 

I had always interpreted this as new data that has not been queued for
retransmission, but in reading RFC 2018 regarding SACK, it seems that
data on the retransmission queue is expected to be retransmitted in Fast
Recovery as this section is outside the scope of the retransmission
timer:

 
   After the SACKed bit is turned on (as the result of processing a
   received SACK option), the data sender will skip that segment during
   any later retransmission. 

 

Your insight is greatly appreciated.

 

Best Regards,
Tammy Leino