IETF Logo Mail Archive

Re: [tcpm] initial RTO (was Re: Tuning TCP parameters for the 21st century)

<L.Wood@surrey.ac.uk> Thu, 30 July 2009 11:51 UTC

Return-Path: <L.Wood@surrey.ac.uk>
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 5745C28C1FE for <tcpm@core3.amsl.com>; Thu, 30 Jul 2009 04:51:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.298
X-Spam-Level:
X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 vF67ThmlLufk for <tcpm@core3.amsl.com>; Thu, 30 Jul 2009 04:51:54 -0700 (PDT)
Received: from mail83.messagelabs.com (mail83.messagelabs.com [195.245.231.83]) by core3.amsl.com (Postfix) with SMTP id 0DC9428C1D8 for <tcpm@ietf.org>; Thu, 30 Jul 2009 04:51:53 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: L.Wood@surrey.ac.uk
X-Msg-Ref: server-11.tower-83.messagelabs.com!1248954714!50589405!1
X-StarScan-Version: 6.1.2; banners=-,-,-
X-Originating-IP: [131.227.102.140]
Received: (qmail 6098 invoked from network); 30 Jul 2009 11:51:54 -0000
Received: from ads40.surrey.ac.uk (HELO ads40.surrey.ac.uk) (131.227.102.140) by server-11.tower-83.messagelabs.com with SMTP; 30 Jul 2009 11:51:54 -0000
Received: from EVS-EC1-NODE4.surrey.ac.uk ([131.227.102.145]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Jul 2009 12:51:53 +0100
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_01CA110C.21AA0B0F"
Date: Thu, 30 Jul 2009 12:51:40 +0100
Message-ID: <4835AFD53A246A40A3B8DA85D658C4BE0136891C@EVS-EC1-NODE4.surrey.ac.uk>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [tcpm] initial RTO (was Re: Tuning TCP parameters for the 21st century)
Thread-Index: AcoRCrEyfIeOfuvURNGGvYW6nTd3uAAAWiC+
References: <20090730114119.F0DA138A214@lawyers.icir.org>
From: L.Wood@surrey.ac.uk
To: mallman@icir.org
X-OriginalArrivalTime: 30 Jul 2009 11:51:53.0913 (UTC) FILETIME=[21E0A290:01CA110C]
Cc: tcpm@ietf.org
Subject: Re: [tcpm] initial RTO (was Re: Tuning TCP parameters for the 21st century)
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, 30 Jul 2009 11:51:55 -0000

SYN timestamps benefit _all_ cases...

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><L.Wood@surrey.ac.uk>



-----Original Message-----
From: Mark Allman [mailto:mallman@icir.org]
Sent: Thu 2009-07-30 12:41
To: Wood L Dr (Electronic Eng)
Cc: hkchu@google.com; tcpm@ietf.org
Subject: Re: [tcpm] initial RTO (was Re: Tuning TCP parameters for the 21st century) 
 

> It's necessary to disambiguate which ACK is for which SYN - i.e. if
> you have a _very_ long-delay path, you might send out three SYNs
> before an ACK to the first SYN comes in. But it appears at the time to
> be an ACK to the third SYN, with other responses lost in transit. So
> SYN timestamps really are necessary to disambiguate in this
> situation. I can see a cascading sequence where the first ACK comes in
> just after say the fifth SYN goes out, and it's immediately necessary
> to bump the RTO up to tens of seconds.

Sure.

I guess Jerry and I are talking about the case where with exceedingly
high probability the RTT is covered by the current 3sec RTO and the vast
majority of the connections have an RTT of less than 1sec.  (So, say,
99.99999% < 3sec and 98% < 1sec.)  So, how then do we use 1sec for the
common case, but still reasonably accommodate the fraction that have
RTTs > 1sec but < 3sec?

Would it be nice to keep pushing and accommodate connections with even
larger RTTs?  Ideally, yeah.  But, I am not sure imposing timestamps or
other mechanisms on everyone to deal with that case is useful.  At some
point you have to engineer your edge case for what it is.

allman

v2.23.0 | Report a Bug | By Email