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 > > >
- [tcpm] RFC 2581 Clarification Leino, Tammy
- Re: [tcpm] RFC 2581 Clarification Yoshifumi Nishida