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

Mark Allman <> Thu, 30 July 2009 11:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 77A8728C156 for <>; Thu, 30 Jul 2009 04:41:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.499
X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 93xFlU9lALon for <>; Thu, 30 Jul 2009 04:41:27 -0700 (PDT)
Received: from pork.ICSI.Berkeley.EDU (pork.ICSI.Berkeley.EDU []) by (Postfix) with ESMTP id 7797B28C155 for <>; Thu, 30 Jul 2009 04:41:27 -0700 (PDT)
Received: from ( []) by pork.ICSI.Berkeley.EDU ( with ESMTP id n6UBfQpf004950; Thu, 30 Jul 2009 04:41:26 -0700
Received: from ( []) by (Postfix) with ESMTP id 664913BDC503; Thu, 30 Jul 2009 07:41:18 -0400 (EDT)
Received: from (localhost []) by (Postfix) with ESMTP id F0DA138A214; Thu, 30 Jul 2009 07:41:19 -0400 (EDT)
From: Mark Allman <>
In-Reply-To: <>
Organization: International Computer Science Institute (ICSI)
Song-of-the-Day: Sweet Emotion
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="--------ma34525-1"; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Thu, 30 Jul 2009 07:41:19 -0400
Message-Id: <>
Subject: Re: [tcpm] initial RTO (was Re: Tuning TCP parameters for the 21st century)
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 30 Jul 2009 11:41:28 -0000

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


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.