Re: [tcpm] Increasing the Initial Window - Notes

Joe Touch <touch@isi.edu> Wed, 10 November 2010 23:23 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 7383D3A67C2 for <tcpm@core3.amsl.com>; Wed, 10 Nov 2010 15:23:32 -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 WrNQtKmV-BOA for <tcpm@core3.amsl.com>; Wed, 10 Nov 2010 15:23:31 -0800 (PST)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 6ABFB3A67B5 for <tcpm@ietf.org>; Wed, 10 Nov 2010 15:23:31 -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 oAANNfwq014504 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 10 Nov 2010 15:23:41 -0800 (PST)
Message-ID: <4CDB297D.7060304@isi.edu>
Date: Wed, 10 Nov 2010 15:23:41 -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: Jerry Chu <hkchu@google.com>
References: <20101110152857.GA5094@hell> <4CDAD0FB.6060602@isi.edu> <AANLkTim4f+9HWx4QokDttkbMGKcNAZLqGE6P2zTAsmZO@mail.gmail.com>
In-Reply-To: <AANLkTim4f+9HWx4QokDttkbMGKcNAZLqGE6P2zTAsmZO@mail.gmail.com>
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: tcpm <tcpm@ietf.org>, tmrg <tmrg-interest@icsi.berkeley.edu>, Matt Mathis <mattmathis@google.com>
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 23:23:32 -0000

On 11/10/2010 3:13 PM, Jerry Chu wrote:
> + yaogong
>
> Joe,
>
> You brought up a good question. We don't have any direct data on the scenario
> you described. Also we've used FIFO tail drop so far hence haven't tried any
> AQM algorithm on the router. Otherwise our testbed data showed under high
> load and some extreme case (e.g., a constantly 5-simultaneous open bursts)
> the average qlen of IW10 can get much longer than that of IW3, although under
> those loaded conditions IW3 is already bad enough.
>
> To really answer your question, I'd suggest you to go to
> http://research.csc.ncsu.edu/netsrv/?q=content/iw10
>
> and tell us how to modify the test setup/parameters/programs to emulate the
> exact condition you have in mind. I'm sure our collaboration Yaogong Wang from
> NCSU will be happy to run some results for you.

Your collaborators need to learn more about the situation of buffer 
bloat - it might be useful to contact Jim Gettys on this, and see what 
he can point you to that would help you understand how you need to 
configure the testbed to consider this issue. I'm following it, but only 
peripherally.

Joe

>
> Thanks,
>
> Jerry
>
> On Wed, Nov 10, 2010 at 9:06 AM, Joe Touch<touch@isi.edu>  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?
>>
>> Joe
>>