Re: [tcpm] Increasing the Initial Window - Notes

Joe Touch <touch@isi.edu> Wed, 10 November 2010 17:05 UTC

Return-Path: <touch@isi.edu>
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 635E43A6978 for <tcpm@core3.amsl.com>; Wed, 10 Nov 2010 09:05:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 k4kGxDnBtbEs for <tcpm@core3.amsl.com>; Wed, 10 Nov 2010 09:05:49 -0800 (PST)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 8DBFD3A6949 for <tcpm@ietf.org>; Wed, 10 Nov 2010 09:05:49 -0800 (PST)
Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id oAAH63wR022729 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 10 Nov 2010 09:06:03 -0800 (PST)
Message-ID: <4CDAD0FB.6060602@isi.edu>
Date: Wed, 10 Nov 2010 09:06:03 -0800
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: Hagen Paul Pfeifer <hagen@jauu.net>
References: <20101110152857.GA5094@hell>
In-Reply-To: <20101110152857.GA5094@hell>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
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:05:50 -0000

FWIW, I'd like to add another point to the discussion.

There has been recent concern with "buffer bloat", where home OS's, home 
routers, etc. all have either poorly optimized or incomplete 
implementations of fair queuing and socket buffering.

The basic problem can be seen as follows:
	- run a continuous ping anywhere
	- start a large upload

The latencies go from 10-100 milliseconds up t 0.5-5 seconds. This 
happens because the outbound buffers get stuffed with data.

Although a single connection can cause this to happen (it optimizes for 
rate, not throughput), we know how to handle that - use RED, fair 
queuing, etc.

I'm wondering if increasing the IW can defeat these corrective measures, 
and recreate the problem in a way that has no effective solution.

Has that been considered?

Joe