Re: [tcpm] Tuning TCP parameters for the 21st century

Michael Scharf <> Wed, 15 July 2009 09:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8F9473A67DD for <>; Wed, 15 Jul 2009 02:35:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7mCbQiyQ3eTR for <>; Wed, 15 Jul 2009 02:34:59 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 809423A68B9 for <>; Wed, 15 Jul 2009 02:34:59 -0700 (PDT)
Received: from (netsrv1-c []) by (Postfix) with ESMTP id D59B643A03; Wed, 15 Jul 2009 11:15:17 +0200 (CEST)
Received: from (cnode02 []) by (Postfix) with SMTP id BD8FABC07E; Wed, 15 Jul 2009 11:15:17 +0200 (CEST)
Received: by (sSMTP sendmail emulation); Wed, 15 Jul 2009 11:15:17 +0200
Date: Wed, 15 Jul 2009 11:15:17 +0200
From: Michael Scharf <>
To: Joe Touch <touch@ISI.EDU>
Message-ID: <>
References: <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: "" <>
Subject: Re: [tcpm] 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, 15 Jul 2009 09:35:00 -0000

On Tue, 14 Jul 2009 at 16:02:39, Joe Touch wrote:
> Larger messages benefit as you open the window to burst the whole thing
> out. Here's a back of the envelope:
> # packets	was RTTs:	is RTTs:	benefit
> 	4	2		2		0%
>  	10 	3		2		33%
> 	19	4		2		50%
> 	32	5		2		60%
> 	52	6		2		67%
> 	82	7		2		71%
> Note though that at some point your SND_CWND will be opened only as far
> as the path allows, at which point sending more packets just takes more
> RTTs, so you start to lose. 90% of our max CWNDs were below 9K, which
> means we only saw benefits in the 20-30% range (i.e., the first two rows
> above). Sure, if you see CWNDs much larger, you might benefit from
> reusing old values...

A large initial SND_CWND might not result in such a large benefit if
the receiver still announces a small receive window (e. g., the Linux
stack initially announces a receive window of about 6K only). This
issue is documented in an (expired) ID:

An example for a limitation by the receive window can also be seen on
slide 19 of

Note that, at least in case of Linux, it is possible to mitigate this
limitation by an ugly hack: The sender could ignore the announced
receive window during the first RTT of the Slow-Start and
optimistically send more data. As the receiver exponentially opens the
receive window, the received packets are always within the current
receive window - if the receiver does not run out of memory. But of
course this hack violates RFC 793.

BTW: My experiments with different fast startup schemes (with and
without rate pacing) also show that the absolute benefit of a faster
startup is small for many typical Internet workloads. Yet,
applications that frequently transfer mid-sized amounts of data can
indeed benefit. And since only few applications actually use a large
initial SND_CWND, the risk of a moderate increase of the initial
window appears to be rather small. As also mentioned in my ICCRG
presentation, the "Jump-Start" idea of M. Allman et al. seems to have
a quite reasonable performance in many scenarios.

Unfortunately, I cannot back these statements by large-scale
experimental data so far. But if someone wanted to perform some
experiments, e. g., with the "Jump-Start" scheme, I could provide
corresponding Linux kernel patches.