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

Mark Allman <mallman@icir.org> Tue, 28 July 2009 18:36 UTC

Return-Path: <mallman@icir.org>
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 93DB73A684C for <tcpm@core3.amsl.com>; Tue, 28 Jul 2009 11:36:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_34=0.6]
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 CaGQFNY2JuNT for <tcpm@core3.amsl.com>; Tue, 28 Jul 2009 11:36:04 -0700 (PDT)
Received: from pork.ICSI.Berkeley.EDU (pork.ICSI.Berkeley.EDU [192.150.186.19]) by core3.amsl.com (Postfix) with ESMTP id DF8733A6A84 for <tcpm@ietf.org>; Tue, 28 Jul 2009 11:36:04 -0700 (PDT)
Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id n6SIa38n015110; Tue, 28 Jul 2009 11:36:03 -0700
Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id DDEFC3BCFC45; Tue, 28 Jul 2009 14:35:55 -0400 (EDT)
Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id A5820385088; Tue, 28 Jul 2009 14:35:56 -0400 (EDT)
To: Jerry Chu <hkchu@google.com>
From: Mark Allman <mallman@icir.org>
In-Reply-To: <d1c2719f0907280832u199cbaa7p10a977b3a2cef244@mail.gmail.com>
Organization: International Computer Science Institute (ICSI)
Song-of-the-Day: Sweet Emotion
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="--------ma17674-1"; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Tue, 28 Jul 2009 14:35:56 -0400
Sender: mallman@icir.org
Message-Id: <20090728183556.A5820385088@lawyers.icir.org>
Cc: "tcpm@ietf.org" <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
Reply-To: mallman@icir.org
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: Tue, 28 Jul 2009 18:36:05 -0000

Jerry-

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

allman