Re: [tcpm] Increasing the Initial Window - Notes

" Ilpo Järvinen " <ilpo.jarvinen@helsinki.fi> Thu, 11 November 2010 02:19 UTC

Return-Path: <ilpo.jarvinen@helsinki.fi>
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 E3FBA3A68E7 for <tcpm@core3.amsl.com>; Wed, 10 Nov 2010 18:19:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level:
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 DYSgBCF2W8zh for <tcpm@core3.amsl.com>; Wed, 10 Nov 2010 18:19:57 -0800 (PST)
Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by core3.amsl.com (Postfix) with ESMTP id D362E3A6900 for <tcpm@ietf.org>; Wed, 10 Nov 2010 18:19:56 -0800 (PST)
Received: from melkinpaasi.cs.helsinki.fi (melkinpaasi.cs.helsinki.fi [128.214.9.14]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Thu, 11 Nov 2010 04:20:23 +0200 id 0009C836.4CDB52E7.0000625D
Date: Thu, 11 Nov 2010 04:20:23 +0200
From: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
X-X-Sender: ijjarvin@melkinpaasi.cs.helsinki.fi
To: Joe Touch <touch@isi.edu>
In-Reply-To: <4CDAD0FB.6060602@isi.edu>
Message-ID: <alpine.DEB.2.00.1011110413380.21459@melkinpaasi.cs.helsinki.fi>
References: <20101110152857.GA5094@hell> <4CDAD0FB.6060602@isi.edu>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Cc: tcpm <tcpm@ietf.org>, Matt Mathis <mattmathis@google.com>, tmrg <tmrg-interest@ICSI.Berkeley.EDU>
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: Thu, 11 Nov 2010 02:19:58 -0000

On Wed, 10 Nov 2010, Joe Touch wrote:

> 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?

Please stay tuned, I intend to try to answer this question in my upcoming 
presentation. ...Or if curious enough, you can find my slides already 
among the tcpm material.

-- 
 i.