IETF Logo Mail Archive

Re: [tcpm] TCP tuning

Alexander Zimmermann <alexander.zimmermann@nets.rwth-aachen.de> Thu, 04 February 2010 08:08 UTC

Return-Path: <alexander.zimmermann@nets.rwth-aachen.de>
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 2B2323A6D30 for <tcpm@core3.amsl.com>; Thu, 4 Feb 2010 00:08:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.801
X-Spam-Level:
X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 Ru9g24sRd84F for <tcpm@core3.amsl.com>; Thu, 4 Feb 2010 00:08:01 -0800 (PST)
Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id B35473A6D2E for <tcpm@ietf.org>; Thu, 4 Feb 2010 00:08:01 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: text/plain; charset="us-ascii"
Received: from ironport-out-2.rz.rwth-aachen.de ([134.130.5.41]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0KXB00KEE5ALDOF0@mta-1.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Thu, 04 Feb 2010 09:08:45 +0100 (CET)
X-IronPort-AV: E=Sophos;i="4.49,403,1262559600"; d="scan'208";a="23504053"
Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-2.rz.rwth-aachen.de with ESMTP; Thu, 04 Feb 2010 09:08:45 +0100
Received: from miami.nets.rwth-aachen.de ([unknown] [137.226.12.180]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0KXB006475AK7150@relay-auth-2.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Thu, 04 Feb 2010 09:08:45 +0100 (CET)
From: Alexander Zimmermann <alexander.zimmermann@nets.rwth-aachen.de>
In-reply-to: <1e41a3231002031411u57a79ffas1fa77988e83343c0@mail.gmail.com>
Date: Thu, 04 Feb 2010 09:08:45 +0100
Message-id: <278B912D-421D-4E25-AC37-5D39C9A37A02@nets.rwth-aachen.de>
References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <133D9897FB9C5E4E9DF2779DC91E947C025F1861@SLFSNX.rcs.alcatel-research.de> <d1c2719f1002031110v3b76ca9eu14c9a110847548e7@mail.gmail.com> <4B69CDD7.6060802@isi.edu> <d1c2719f1002031339u14709270k6452c05f0dd3c39e@mail.gmail.com> <EC7B72027914A242B991C029F5F213CF3EBE4C5753@exchsvr01.ocarina.local> <1e41a3231002031411u57a79ffas1fa77988e83343c0@mail.gmail.com>
To: John Heffner <johnwheffner@gmail.com>
X-Mailer: Apple Mail (2.1077)
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, Murali Bashyam <MBashyam@ocarinanetworks.com>
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: Thu, 04 Feb 2010 08:08:03 -0000

The motivation for this is RFC 2861: TCP Congestion Window Validation

Alex

Am 03.02.2010 um 23:11 schrieb John Heffner:

> On Wed, Feb 3, 2010 at 5:03 PM, Murali Bashyam
> <MBashyam@ocarinanetworks.com> wrote:
>> Any idle period higher than the RTT between HTTP requests tends to reset the cwindow down to the restart window. This hurts persistent connections too. What's the motivation for this, can we have a different slope while reducing the window instead of resetting all the way down?
> 
> 
> This is because you lose the ack clock.  Otherwise, when resuming
> sending you'll send a line-rate burst of the full BDP, which will
> often overflow queues and cause loss and/or large delay spikes.  There
> is currently no pacing mechanism in TCP to smooth out such bursts.
> 
>  -John
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

//
// Dipl.-Inform. Alexander Zimmermann
// Department of Computer Science, Informatik 4
// RWTH Aachen University
// Ahornstr. 55, 52056 Aachen, Germany
// phone: (49-241) 80-21422, fax: (49-241) 80-22220
// email: zimmermann@cs.rwth-aachen.de
// web: http://www.umic-mesh.net
//

v2.23.0 | Report a Bug | By Email