IETF Logo Mail Archive

Re: [tcpm] new version of 2988bis

"Scheffenegger, Richard" <rs@netapp.com> Wed, 22 December 2010 11:39 UTC

Return-Path: <rs@netapp.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 222743A6AD9 for <tcpm@core3.amsl.com>; Wed, 22 Dec 2010 03:39:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.284
X-Spam-Level:
X-Spam-Status: No, score=-10.284 tagged_above=-999 required=5 tests=[AWL=0.315, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 psoO-UwOtOJj for <tcpm@core3.amsl.com>; Wed, 22 Dec 2010 03:39:14 -0800 (PST)
Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by core3.amsl.com (Postfix) with ESMTP id D311C3A6846 for <tcpm@ietf.org>; Wed, 22 Dec 2010 03:39:13 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.60,212,1291622400"; d="scan'208";a="227756109"
Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 22 Dec 2010 03:41:10 -0800
Received: from amsrsexc1-prd.hq.netapp.com (webmail.europe.netapp.com [10.64.251.107]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id oBMBfArO012249; Wed, 22 Dec 2010 03:41:10 -0800 (PST)
Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.107]) by amsrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Dec 2010 12:41:09 +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: Wed, 22 Dec 2010 11:41:03 -0000
Message-ID: <5FDC413D5FA246468C200652D63E627A0C0A2FD4@LDCMVEXC1-PRD.hq.netapp.com>
In-Reply-To: <AANLkTimTJSGMOuay10krCjJbu6pPnoGFuirz_Q3_tk0F@mail.gmail.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [tcpm] new version of 2988bis
Thread-Index: AcuhuTjSTmoCrh2MRJmPQYbjcBwTzwAEsknw
References: <20101207033356.439642715136@lawyers.icir.org> <AANLkTimTJSGMOuay10krCjJbu6pPnoGFuirz_Q3_tk0F@mail.gmail.com>
From: "Scheffenegger, Richard" <rs@netapp.com>
To: "Per Hurtig (work)" <per.hurtig@kau.se>, tcpm@ietf.org
X-OriginalArrivalTime: 22 Dec 2010 11:41:09.0995 (UTC) FILETIME=[20BF0BB0:01CBA1CD]
Cc: mallman@icir.org
Subject: Re: [tcpm] new version of 2988bis
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, 22 Dec 2010 11:39:15 -0000

Hmm...

How do you deal with multiple lost segments in the same window? Your draft says

  2.  Proposed Modifications

   The document proposes an update of step 5.3 in Section 5 of [RFC2988]
   to (and a similar update of step R3 in section 6.3.2 of [RFC4960]):

      When an ACK is received that acknowledges new data, restart the
      retransmission timer so that it will expire RTO seconds after the
      earliest outstanding segment was transmitted (for the current
      value of RTO).

   The update requires TCP implementations to track the time elapsed
   since sending the last unacknowledged segment.  In practice, this
   could be achieved by adding one variable to the transmission control
   block.

But wouldn't you really need to track the sending time of *each* segment, to always be able to calculate the true T_earliest? I can not see how a singular, global TCPCB variable addresses this - perhaps I'm missing something?

Wouldn't there be an opportunity to use this feature synergistically with RFC1323 Timestamps also? (The ACK with new data should reflect the sender's TCP clock (or a well derived value thereof) at the time the segment was sent. Perhaps that information can help reducing additional per-segment state in the sender?)

Best regards,
   Richard Scheffenegger


> -----Original Message-----
> From: Per Hurtig (work) [mailto:per.hurtig@kau.se]
> Sent: Mittwoch, 22. Dezember 2010 10:16
> To: tcpm@ietf.org
> Cc: mallman@icir.org
> Subject: Re: [tcpm] new version of 2988bis
> 
> Hi all,
> 
> we have submitted an I-D that summarizes an alternate way to restart
> the TCP/SCTP RTO timer:
> 
> http://www.ietf.org/id/draft-hurtig-tcpm-rtorestart-00.txt
> 
> The difference between this approach and RFC2988(bis)'s approach is
> the way outstanding segments are
> considered. We're happy to receive any comments on the draft.
> 
> 
> Regards, Per H
> 
> 
> 
> 
> On Tue, Dec 7, 2010 at 04:33, Mark Allman <mallman@icir.org> wrote:
> >
> > Folks-
> >
> > We posted a new version of the 2988bis I-D today.  It is:
> >
> >  draft-paxson-tcpm-rfc2988bis-01.txt
> >
> > The big change is a new set of empirical results that pertain to
> > dropping the initial RTO from 3sec to 1sec is now given (along with
> the
> > previous results from Google) in the appendix.  Generally speaking,
> > these results show it is pretty safe to drop the initial RTO.
> >
> > Have a look.  I believe the authors are pretty happy with this
> document
> > at this point.
> >
> > allman
> >
> >
> >
> >
> >
> > _______________________________________________
> > tcpm mailing list
> > tcpm@ietf.org
> > https://www.ietf.org/mailman/listinfo/tcpm
> >
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

v2.23.0 | Report a Bug | By Email