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

Mark Allman <> Wed, 29 July 2009 16:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8A3313A6F33 for <>; Wed, 29 Jul 2009 09:06:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yGPisp2wePIK for <>; Wed, 29 Jul 2009 09:06:05 -0700 (PDT)
Received: from pork.ICSI.Berkeley.EDU (pork.ICSI.Berkeley.EDU []) by (Postfix) with ESMTP id 9C7D13A6830 for <>; Wed, 29 Jul 2009 09:06:05 -0700 (PDT)
Received: from ( []) by pork.ICSI.Berkeley.EDU ( with ESMTP id n6TG64nN010804; Wed, 29 Jul 2009 09:06:04 -0700
Received: from ( []) by (Postfix) with ESMTP id 2A7503BD69C4; Wed, 29 Jul 2009 12:05:57 -0400 (EDT)
Received: from (localhost []) by (Postfix) with ESMTP id 122DF3884F5; Wed, 29 Jul 2009 12:05:59 -0400 (EDT)
To: Jerry Chu <>
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="--------ma29542-1"; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Wed, 29 Jul 2009 12:05:58 -0400
Message-Id: <>
Cc: "" <>
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: Wed, 29 Jul 2009 16:06:06 -0000

> I can think of a number of variations. The one-shot 1-sec-initRTO idea
> you described above also came through my mind but the drawback is you
> only get one-shot even though we know statistically > 98% of
> connections have RTT < 1 sec so most likely the continuous use of
> 1-sec-initRTO will turn out to be better. (A counter argument might be
> one-shot is "good enough", benefitting > 90% of the cases
> statistically...) The advantage of it is its simplicity, restricting
> the max # of spurious retransmissions caused by the reduced initRTO to
> 1, and obviously avoiding the RTO hell problem.

Two responses to "one shot":

(1) Yes, one-shot ought to be enough.  Considering losing the SYN,
    retransmitting it using an initRTO of 1sec and reseting the initRTO
    to 3sec.  Now, if there is actually loss in the first RTT of data
    transmission talking about fine-grained performance (i.e., that we
    can get from using 1sec again instead of 3sec) doesn't make a lot of
    sense because 1sec vs. 3sec doesn't matter because performance is
    going to suck no matter what.  So, why bother with anything terribly
    "smart" here?

(2) Using the numbers on your slides it seems to me that the fraction of
    hosts with an RTT of > 1sec is roughly the same as the SYN
    retransmit rate (at an RTT of 3sec, I assume).  To me that says that
    if you use an initRTO of 1sec and then retransmit then the reason
    for that retransmit is just as likely to be loss as it is to be a
    long path.  So, your approach of preferring more than one-shot
    assumes loss.  But, I don't see the measurements you gave as
    suggesting that is the right approach.  The notion of going back to
    3sec just sort of punts.  I.e., the notion is that we have hit a
    situation whereby we don't know what is going on and so let's not
    dogmatically try to push forward, but let's throw up our hands and
    try to do things that ultimately will figure out what is going on.
    And, further, one mistake does not propagate.

So, for me one-shot is just about the right balance here.  Any more than
that we're getting into the corner of a corner case and further in that
corner the empirical evidence is not suggestive of a clear path.  So,
let's just do something that will allow the protocol to get a handle on
things as they are in the specific situation and not try to make guesses
that propagate further.