Re: [tcpm] RFC 2581 Clarification

Yoshifumi Nishida <nishida@sfc.wide.ad.jp> Thu, 02 April 2009 22:50 UTC

Return-Path: <nishida@sfc.wide.ad.jp>
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 7A2113A6D53 for <tcpm@core3.amsl.com>; Thu, 2 Apr 2009 15:50:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.585
X-Spam-Level: *
X-Spam-Status: No, score=1.585 tagged_above=-999 required=5 tests=[AWL=0.681, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994]
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 Xl1k9vNI2sLW for <tcpm@core3.amsl.com>; Thu, 2 Apr 2009 15:50:13 -0700 (PDT)
Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id AFA9F3A6824 for <tcpm@ietf.org>; Thu, 2 Apr 2009 15:50:13 -0700 (PDT)
Received: from localhost (cpu.sfc.wide.ad.jp [203.178.142.143]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id B60C94C09C; Fri, 3 Apr 2009 07:51:10 +0900 (JST)
Date: Fri, 03 Apr 2009 07:51:10 +0900
Message-Id: <20090403.075110.183124339.nishida@sfc.wide.ad.jp>
To: tammy_leino@mentor.com
From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
In-Reply-To: <2F83EB16CD718C43889CBCD31ECFD7F80215AA1C@na2-mail.mgc.mentorg.com>
References: <2F83EB16CD718C43889CBCD31ECFD7F80215AA1C@na2-mail.mgc.mentorg.com>
X-Mailer: Mew version 6.2 on Emacs 22.1 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Cc: tcpm@ietf.org
Subject: Re: [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: Thu, 02 Apr 2009 22:50:14 -0000

Hello Leino,

I think you had better refer rfc3517 instead of rfc2581 for this.

Thanks,
--
Yoshifumi Nishida
nishida@sfc.wide.ad.jp

From: "Leino, Tammy" <tammy_leino@mentor.com>
Subject: [tcpm] RFC 2581 Clarification
Date: Wed, 1 Apr 2009 14:29:06 -0600
Message-ID: <2F83EB16CD718C43889CBCD31ECFD7F80215AA1C@na2-mail.mgc.mentorg.com>

 > 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
 > 
 >  
 >