Re: [tcpm] TCP tuning

"SCHARF, Michael" <Michael.Scharf@alcatel-lucent.com> Wed, 03 February 2010 15:16 UTC

Return-Path: <Michael.Scharf@alcatel-lucent.com>
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 D7FA73A6C44 for <tcpm@core3.amsl.com>; Wed, 3 Feb 2010 07:16:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level:
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
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 8Urn-GNg5R3D for <tcpm@core3.amsl.com>; Wed, 3 Feb 2010 07:16:52 -0800 (PST)
Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by core3.amsl.com (Postfix) with ESMTP id AF6613A6991 for <tcpm@ietf.org>; Wed, 3 Feb 2010 07:16:51 -0800 (PST)
Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay2.alcatel.de (8.13.8/8.13.8/ICT) with ESMTP id o13FHUUe014364 for <tcpm@ietf.org>; Wed, 3 Feb 2010 16:17:31 +0100
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Wed, 03 Feb 2010 16:17:29 +0100
Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C025F1861@SLFSNX.rcs.alcatel-research.de>
In-Reply-To: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [tcpm] TCP tuning
Thread-Index: Acqk3XLzrGK3T9V1Rri9FSyzcg9I/wAAnUiQ
References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com>
From: "SCHARF, Michael" <Michael.Scharf@alcatel-lucent.com>
To: tcpm@ietf.org
X-Scanned-By: MIMEDefang 2.57 on 149.204.45.73
Subject: Re: [tcpm] TCP tuning
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, 03 Feb 2010 15:16:53 -0000

> This topic seems to be gaining momentum, and the WG should 
> take some time considering if there is work here for it.

IMHO there could indeed be room for increasing the initial window. If
most data transfers continue to be smaller than 3 MSS, a larger initial
window would not necessarily cause harm, as it is seldomly used. Still,
this would speed up those data transfers that currently suffer from
Slow-Start.

In the past, I have played a little bit with an initial window e. g. of
10 MSS, and that worked surprisingly well. Also, one could combine a
larger initial window with other mechanisms that would reduce the
aggressiveness of the flow startup. Maybe it is indeed time to think
about the Slow-Start once again.

Michael