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

<> Thu, 30 July 2009 08:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D454D28C1E6 for <>; Thu, 30 Jul 2009 01:27:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.998
X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wQWMjogNpyKI for <>; Thu, 30 Jul 2009 01:27:58 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 16EFB28C218 for <>; Thu, 30 Jul 2009 01:27:57 -0700 (PDT)
X-VirusChecked: Checked
X-StarScan-Version: 6.1.2; banners=-,-,-
X-Originating-IP: []
Received: (qmail 31697 invoked from network); 30 Jul 2009 08:27:56 -0000
Received: from (HELO ( by with SMTP; 30 Jul 2009 08:27:56 -0000
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Jul 2009 09:27:56 +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_01CA10EF.A382F661"
Date: Thu, 30 Jul 2009 09:27:55 +0100
Message-ID: <>
Thread-Topic: [tcpm] initial RTO (was Re: Tuning TCP parameters for the 21st century)
Thread-Index: AcoPskrFnef0JXkmSROcNgOfPDCsxgBPBIoP
References: <>
X-OriginalArrivalTime: 30 Jul 2009 08:27:56.0605 (UTC) FILETIME=[A3DF9ED0:01CA10EF]
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 08:27:59 -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.

related discussion of this is in our TCP Protocol Radius paper:
esp. Fig 2.



-----Original Message-----
From: on behalf of Mark Allman
Sent: Tue 2009-07-28 19:35
To: Jerry Chu
Subject: Re: [tcpm] initial RTO (was Re: Tuning TCP parameters for the 21st century)


> So the active open side has retransmitted SYN, assuming initRTO of
> 1sec, and eventually received a SYN-ACK but the TS option was
> denied so no good RTT sample can be taken. It will continue to send
> the init data with the initRTO.
> If the SYN retransmission has been unnecessary because the initRTO has
> been too aggressive, more SYN-ACK will be triggered. Assuming these
> dup SYN-ACKs are not lost, could they be used as a hint to the active
> open side that the initRTO has been too short, so that the RTO timer
> can be reverted back to 3secs immediately, in time to avoid further
> RTO hell?

So, you're saying that if you send N SYNs (N>1) and you get N SYN+ACKs
then you take that to mean the initRTO was too short.

Yeah, perhaps ... 

Are you suggesting something like this ...

  (1) Use an initRTO of 1sec.

  (2) If the RTO fires and you retransmit the SYN back the RTO to 3sec.
      (And, if necessary you exponential backoff even more.)

  (3) After the 3WHS you will either (a) have a good RTT sample from the
      timestamp option and can therefore set the RTO reasonably or (b)
      you retain the 3sec RTO until you get a good RTT sample.


That means that if 1sec is not enough in the 3WHS you have to use 3sec
until you have some idea about the network.  However, you also get a
shot [*one shot*] to retransmit sooner based on the notion that most
RTTs are less than 1sec.  

I think I buy that notion ... that both allows for more aggressiveness
for the common case while also protecting against RTO Hell for the long
path cases.  Is that the right walking of the line?