Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes

" Ilpo Järvinen " <ilpo.jarvinen@helsinki.fi> Tue, 16 November 2010 14:00 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 5FA903A69F3 for <tcpm@core3.amsl.com>; Tue, 16 Nov 2010 06:00:39 -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 t9ZeISwuC1K4 for <tcpm@core3.amsl.com>; Tue, 16 Nov 2010 06:00:38 -0800 (PST)
Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by core3.amsl.com (Postfix) with ESMTP id 0F5283A688E for <tcpm@ietf.org>; Tue, 16 Nov 2010 06:00:36 -0800 (PST)
Received: from wel-95.cs.helsinki.fi (wel-95.cs.helsinki.fi [128.214.10.211]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Tue, 16 Nov 2010 16:01:19 +0200 id 00093D18.4CE28EAF.00007A89
Date: Tue, 16 Nov 2010 16:01:19 +0200
From: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
X-X-Sender: ijjarvin@wel-95.cs.helsinki.fi
To: Fred Baker <fred@cisco.com>
In-Reply-To: <AD2BFE84-CA5B-4CDC-8822-1FC2713E3AE0@cisco.com>
Message-ID: <alpine.DEB.2.00.1011161345170.11898@wel-95.cs.helsinki.fi>
References: <20101110152857.GA5094@hell> <804D02FE-39AF-4437-BB15-C2247842E120@mac.com> <20101110170017.GF5094@hell> <97C75EA8-6CC7-444C-A19D-370148B81918@mac.com> <20101110174056.GH5094@hell> <AANLkTim7g=XqfSMHpHVbw1qqPOL-oNApt2i_2RCt0SCi@mail.gmail.com> <AD2BFE84-CA5B-4CDC-8822-1FC2713E3AE0@cisco.com>
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>, tmrg <tmrg-interest@ICSI.Berkeley.EDU>
Subject: Re: [tcpm] [Tmrg] 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: Tue, 16 Nov 2010 14:00:39 -0000

On Tue, 16 Nov 2010, Fred Baker wrote:

> On Nov 11, 2010, at 7:48 AM, Jerry Chu wrote:
> 
> > I wonder what factors will argue that the initial quantum can't be changed?
> > Someone has argued in the past IW10 effectively "disable CC algorithm".
> > But haven't we already done that years ago when moving up IW from 1 to 3 if
> > one insisted then that the initial quantum must be 1?
> 
> Actually, no. I may be the person who said that this effectively 
> disables congestion control in the average case; my reason for saying 
> that is that per what little data I have, the average TCP transfer is on 
> the order of 15K bytes, which is about ten 1460 byte segments. 

It only "disables" it if there was no congestion to control in the first 
place.

> Now, the median is much smaller - on the order of two or three data 
> segments each direction, which is where you get your comment. But the 
> fact that browsers, Bittorrent, and other applications open multiple 
> sessions simultaneously argues that a given endpoint having multiple 
> packets in flight simultaneously doesn't hurt, and research done at the 
> time by Mark Allman and others showed that IW=2..4 wasn't a problem and 
> did in fact reduce the median session to a single RTT for data. But the 
> median session doesn't create a congestion problem.
> 
> The question I have been asking is how IW=10 affects parallel sessions 
> on relatively low speed links.

Could you on your behalf answer how does IW=3 affect parallel sessions on 
the same kind of environment? ...I've done research on this (and Jerry has 
too) and I know that the answer is not an intuitive one. Then we changed 
to IW10 in the same environment and observe no (consistent) change. The 
results are driven by problems already with IW3 so IW10 won't make it any 
worse or the effect is just too small to be measured among the other 
troubles that happen.

> My sense is that the sudden arrival of 
> O(15K) bytes at a 56 KBPS line, which is to say the insertion of a tad 
> over two seconds delay in all competing sessions plus an increase in 
> their probability of loss, is likely to cause them all to be disrupted. 

Again, the existing research points to exactly _opposite_ thing to 
happen, ie., IW10 hurts mostly itself, not the others! We'll never get 
anywhere if these same "fuzzy feelings" (like Mark put it) just get 
repeated and the existing _evidence_ overlooked. Jerry has tested a case 
that is very close to what you're specifying and his results don't agree 
what you think would happen. My results also confirm Jerry's observations 
for the low end links though in my case it was a bit higher bw already 
(160kbps).

I personally don't anymore believe we will find a convincing case against 
IW10 from the very lowest end of links, afaict, it doesn't help but 
doesn't really hurt significantly either. ...I understand this is quite 
non-intuitive claim but it is what the performed studies seem to point 
out (and I expect new guys every now and then to jump in with this same 
argument if IW10 is to proceed). ...I'm more concerned about mid-ranged 
links where it could be possible (at least in theory if AQM in use) to 
have both TCP and low-latency requiring audio/video in parallel. 

> You told me verbally that in your tests it is net beneficial to the 
> parallel sessions, but in thought experiments I'm not sure how that can 
> be true; I'd be fascinated to see the data that shows that competing 
> voice/video sees no frame loss or induced noise, that competing file 
> transfers slow down but do not see redundant retransmissions, and so on.

In this I somewhat agree with you. The delay increase was confirmed by my 
measurements, however, I think you also end up too cleverly mixing 
IW3+IW10 and voice/video cases here. It seems that even if delay increases 
and as a result voice/video could possible experience more losses (I'm yet 
to confirm that losses actually happen as I didn't have actual CBR traffic 
running), IW3 TCP in mixed case is not affected in a similar way. Instead, 
IW3 TCP might actually get a boost in its performance against IW10 because 
also IW10 TCP needs to respond to the congestion it caused.

Also, regardless of IW, TCP is well capable of leaving audio/video in 
ruins as it will fill all buffers you give to it, so I find this exercise 
quite pointless anyway unless there is some form of AQM in use.

> So, IW=2..4 demonstrably works pretty well everywhere, but IW=10 seems 
> to me only sensible on MPBS and GBPS, not KBPS, scale links. 

IW3 doesn't work that well if you have parallel connections over 56kbps 
but since the latencies are high anyway, you just won't notice that.


-- 
 i.