Re: [tcpm] Increasing the Initial Window - Notes

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

Return-Path: <hagen@jauu.net>
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 489CA3A69C3 for <tcpm@core3.amsl.com>; Wed, 10 Nov 2010 09:40:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level:
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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wKFotkQ5uINC for <tcpm@core3.amsl.com>; Wed, 10 Nov 2010 09:40:39 -0800 (PST)
Received: from geheimer.internetendpunkt.de (alternativer.internetendpunkt.de [88.198.24.89]) by core3.amsl.com (Postfix) with ESMTP id 9FF6A3A6949 for <tcpm@ietf.org>; Wed, 10 Nov 2010 09:40:37 -0800 (PST)
Received: by geheimer.internetendpunkt.de (Postfix, from userid 1000) id A6D8BF44195; Wed, 10 Nov 2010 18:41:04 +0100 (CET)
Date: Wed, 10 Nov 2010 18:40:58 +0100
From: Hagen Paul Pfeifer <hagen@jauu.net>
To: rick jones <perfgeek@mac.com>
Message-ID: <20101110174056.GH5094@hell>
References: <20101110152857.GA5094@hell> <804D02FE-39AF-4437-BB15-C2247842E120@mac.com> <20101110170017.GF5094@hell> <97C75EA8-6CC7-444C-A19D-370148B81918@mac.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <97C75EA8-6CC7-444C-A19D-370148B81918@mac.com>
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)
Cc: tmrg <tmrg-interest@ICSI.Berkeley.EDU>, Matt Mathis <mattmathis@google.com>, tcpm <tcpm@ietf.org>
Subject: Re: [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 17:40:40 -0000

* rick jones | 2010-11-10 09:20:23 [-0800]:

>Earlier you wrote "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."  I read that as implying a concern
>about how much data any one connection injects into the network at any moment
>in time.

To clarify this: I especially focus on the start phase of the connection. If
the CC algorithm detects during slow start, congestion avoidance that the
available BDP is larger then the IW it is fine. But if the IW is 10, how
should _new connections_ react, they always will initially transmit 10 packets
- which can be too much - the problem is the initial quantum.

>And I presume, make it configurable.  It is already configurable on a
>per-route basis in the Linux stack.

Yes, and you know the statement of davem and other guys if the discussion goes
in this direction. Davem is aware of the impact of this knob and I am not sure
if everybody is happy about it. I remember a discussion with davem about a
HOT-TO-AGGRESSIVELY-TUNE-YOUR-NETWORK-STACK-HOWTO.xml. If these option are
available they can be misused. I am happy that the per route knobs are a
little bit tricky usable. ;-)

Hagen