IETF Logo Mail Archive

Re: [tcpm] Comments on draft-blanton-tcpm-3517bis-01

"Scheffenegger, Richard" <rs@netapp.com> Thu, 14 April 2011 08:46 UTC

Return-Path: <rs@netapp.com>
X-Original-To: tcpm@ietfc.amsl.com
Delivered-To: tcpm@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 919BEE0698 for <tcpm@ietfc.amsl.com>; Thu, 14 Apr 2011 01:46:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.395
X-Spam-Level:
X-Spam-Status: No, score=-10.395 tagged_above=-999 required=5 tests=[AWL=-0.096, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fzdvzaQnK6QU for <tcpm@ietfc.amsl.com>; Thu, 14 Apr 2011 01:46:52 -0700 (PDT)
Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by ietfc.amsl.com (Postfix) with ESMTP id D265CE066A for <tcpm@ietf.org>; Thu, 14 Apr 2011 01:46:51 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.64,210,1301900400"; d="scan'208";a="250073225"
Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 14 Apr 2011 01:46:50 -0700
Received: from ldcrsexc2-prd.hq.netapp.com (webmail.europe.netapp.com [10.65.251.110]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id p3E8knEe021989; Thu, 14 Apr 2011 01:46:49 -0700 (PDT)
Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.107]) by ldcrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 Apr 2011 09:46:49 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 14 Apr 2011 09:46:26 +0100
Message-ID: <5FDC413D5FA246468C200652D63E627A0DDF2A05@LDCMVEXC1-PRD.hq.netapp.com>
In-Reply-To: <20110413204230.695F539907D3@lawyers.icir.org>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [tcpm] Comments on draft-blanton-tcpm-3517bis-01
Thread-Index: Acv6G1zwIbAgOWpbSR610190WfOh0QAZL91g
References: <alpine.DEB.2.00.1104132300590.27652@melkinpaasi.cs.helsinki.fi> <20110413204230.695F539907D3@lawyers.icir.org>
From: "Scheffenegger, Richard" <rs@netapp.com>
To: mallman@icir.org, Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
X-OriginalArrivalTime: 14 Apr 2011 08:46:49.0528 (UTC) FILETIME=[7E803380:01CBFA80]
Cc: tcpm@ietf.org
Subject: Re: [tcpm] Comments on draft-blanton-tcpm-3517bis-01
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 14 Apr 2011 08:46:52 -0000

I'm also in favor of having this note included - a full section like in draft-ietf-tcpm-sack-recovery-entry may be too much though...


Richard Scheffenegger


> -----Original Message-----
> From: Mark Allman [mailto:mallman@icir.org]
> Sent: Mittwoch, 13. April 2011 22:43
> To: Ilpo Järvinen
> Cc: tcpm@ietf.org Extensions
> Subject: Re: [tcpm] Comments on draft-blanton-tcpm-3517bis-01
> 
> 
> > ...I see, now we're back in discussing what this DupAcks counter is
> > for, right? It was added in sack-recovery-entry ID and had proper
> > explation of its purpose there in place. The DupAcks counter is to
> > handle case where the sender is sending smaller than SMSS sized
> segments.
> > ...Perhaps it would be useful to explain it like the
> > sack-recovery-entry did because otherwise this will just keep
> confusing people?
> 
> Thanks for the reminder... Ethan also noted that this is for the small
> packet case.  I forgot about that.  Why don't we just add a quick note
> to the document after the (1) test.  I.e., something like ...
> 
>    (1) If DupAcks >= DupThresh, go to step (4).
> 
>        Note: This check covers the case when a TCP is not sending
>        full-sized packets and therefore IsLost() (next step) may be
>        hard-pressed to declare a segment as lost.
> 
> allman
> 
>

v2.23.0 | Report a Bug | By Email