[tcpm] Increasing the Initial Window - Notes

Hagen Paul Pfeifer <hagen@jauu.net> Wed, 10 November 2010 15:28 UTC

Return-Path: <hagen@jauu.net>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id CCAA93A681F for <tcpm@core3.amsl.com>; Wed, 10 Nov 2010 07:28:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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 mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id e1T8SMQyxaq4 for <tcpm@core3.amsl.com>; Wed, 10 Nov 2010 07:28:47 -0800 (PST)
Received: from geheimer.internetendpunkt.de (alternativer.internetendpunkt.de []) by core3.amsl.com (Postfix) with ESMTP id 724593A694F for <tcpm@ietf.org>; Wed, 10 Nov 2010 07:28:46 -0800 (PST)
Received: by geheimer.internetendpunkt.de (Postfix, from userid 1000) id 220C9F44195; Wed, 10 Nov 2010 16:29:12 +0100 (CET)
Date: Wed, 10 Nov 2010 16:29:02 +0100
From: Hagen Paul Pfeifer <hagen@jauu.net>
To: Jerry Chu <hkchu@google.com>, tmrg <tmrg-interest@ICSI.Berkeley.EDU>, Matt Mathis <mattmathis@google.com>, tcpm <tcpm@ietf.org>, Lars Eggert <lars.eggert@nokia.com>
Message-ID: <20101110152857.GA5094@hell>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-Key-Id: 98350C22
X-Key-Fingerprint: 490F 557B 6C48 6D7E 5706 2EA2 4A22 8D45 9835 0C22
X-GPG-Key: gpg --recv-keys --keyserver wwwkeys.eu.pgp.net 98350C22
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: [tcpm] Increasing the Initial Window - Notes
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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: Wed, 10 Nov 2010 15:28:47 -0000

Cause tomorrow Jerry will talk about the IW10 topic my 50 cents in advance.
First some skeptical notes, secondly a alternative approach to increase the

I am skeptical about this draft because IMHO renounce the conservative principle
towards a aggressive and HTML centric approach (the HTML example is a bad
allegation, but for FTP and friends slow start is fast enough ;-). My costumer,
and probably other networks too, operates multi-hop radio networks with a
bandwidth of less then 100kB/s.

An increased IW of 10 define 10*~MSS byte as the smallest atomic in-flight
value. New data are always pushed into the network in this quantum - a way to
much for the standard TCP CC mechanism to tune into a steady state for network
with a low BDP.

In the discussion I miss the impact of the proposed modification regarding
networks that operates already at a functioning boundary. Are we at a time
where we loss these types of networks? Where are the simulation results that
show that the impact at this kind of networks is acceptable?

Alternative idea: can we shift the idea towards a more robust basis. What about
a increased IW of 10 if we know that the path is capable of an increased IW?

Pseudo Algorithm for a new connection:

	a) No cached CC data available

		IW = 4 (standard mechanism a la RFC 5681, 3390)
		CC mechanism as usual but save CC parameters - especially cwnd - per route

	b) CC data per route is available

		IF (cached_cwnd >= 10)
			IW = 10
			IW = 4

After n minutes, previously saved CC data is marked as invalid, similar to the
existing "back to slow start after n minutes idle" mechanism.

Idea: networks with a low BDP will signal by packet drop or ECN marking that
congestion occur and the BDP is saturated. Why not use actual network
information to setup the IW but preserve the conservative nature of TCP?

Maybe this is an approach for further discussions, I have a curious feeling
that in 2 years the same discussion will start with a IW of 23 ... So maybe we
should drop the static IW approach completely and define IW as
cached_steady_state_cwnd / 2 for cached routes and IW = 4 for startup all other

Best regards, Hagen