Re: [ledbat] Another uTP story by alarmist author

Nicholas Weaver <nweaver@ICSI.Berkeley.EDU> Fri, 05 December 2008 20:37 UTC

Return-Path: <ledbat-bounces@ietf.org>
X-Original-To: tana-archive@ietf.org
Delivered-To: ietfarch-tana-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 817B23A69AC; Fri, 5 Dec 2008 12:37:38 -0800 (PST)
X-Original-To: ledbat@core3.amsl.com
Delivered-To: ledbat@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 619283A6B8A for <ledbat@core3.amsl.com>; Fri, 5 Dec 2008 12:37:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.636
X-Spam-Level:
X-Spam-Status: No, score=-6.636 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, 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 KSH8C-ImPvIz for <ledbat@core3.amsl.com>; Fri, 5 Dec 2008 12:37:33 -0800 (PST)
Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 467C93A6823 for <ledbat@ietf.org>; Fri, 5 Dec 2008 12:37:29 -0800 (PST)
Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id mB5KbK4G028752; Fri, 5 Dec 2008 12:37:20 -0800 (PST)
Message-Id: <EE529CB6-C2DF-4092-8552-85717447B8F5@icsi.berkeley.edu>
From: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
To: Richard Bennett <richard@bennett.com>
In-Reply-To: <49398658.2020007@bennett.com>
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Fri, 05 Dec 2008 12:37:19 -0800
References: <34F38819-7926-4659-952B-3059B2B45C56@icsi.berkeley.edu> <50FCE54A-9524-4193-BBA6-6D60FB58FBBC@nokia.com> <D6741F6B-5392-4A12-984D-AFEEA3FB8EBE@shlang.com> <b98e548c0812020127i2f6ebaefqc71457e990b3072b@mail.gmail.com> <49398658.2020007@bennett.com>
X-Mailer: Apple Mail (2.929.2)
Cc: ledbat@ietf.org, Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
Subject: Re: [ledbat] Another uTP story by alarmist author
X-BeenThere: ledbat@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mailing list of the LEDBAT WG <ledbat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ledbat>, <mailto:ledbat-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/ledbat>
List-Post: <mailto:ledbat@ietf.org>
List-Help: <mailto:ledbat-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ledbat>, <mailto:ledbat-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="windows-1252"; Format="flowed"; DelSp="yes"
Sender: ledbat-bounces@ietf.org
Errors-To: ledbat-bounces@ietf.org

Unfortunately there are continued errors in your article.



On Dec 5, 2008, at 11:51 AM, Richard Bennett wrote:
>
> Morris also told the media this week that TCP only reduces its  
> sending rate in response to packet loss, a common but erroneous  
> belief. Like uTP, Microsoft’s Compound TCP begins to slow down when  
> it detects latency increases. Even though TCP is capable of being  
> just as polite as BitTorrent wants uTP to be, the fact that it hides  
> its delay measurements from applications makes it troublesome for  
> P2P clients with many paths to choose from. But it’s sensible to  
> explore alternatives to TCP, as we’ve said on these pages many  
> times, and we’re glad BitTorrent finally agrees.
>

And Compound TCP is the exact opposite requirements as uTP, the goal  
is something which is NOT outcompeted by AIMD, if I'm groking the  
description correctly.  Compound-TCP uses a sum-of-windows method, an  
AIMD window and a delay-based window.

uTP is a "Minimum of AIMD/delay based" window sizing algorithm.

The implications are huge.


Compound TCP is designed to get the delay-based behavior on very fast,  
high latency networks, where even a very small loss rate introduces  
very bad behavior to AIMD based congestion control and, in the absence  
of congestion, an AIMD based sender would back off and not utilize the  
link.

Yet by using a sum-of-window with a second AIMD based window, it is  
fully competitive with TCP flows.  This is actually more agressive  
than conventional AIMD, except that the delay-based window gets  
outcompeted by other AIMD flows, so it becomes effectively AIMD based  
in terms of agressiveness.

Thus under competition, Compound TCP can be considered AT LEAST AIMD- 
only for fairness/agressiveness, because it uses the sum of the two  
windows so the AIMD window will compete like any other flow and  
(hopefully) the delay-based window will go to 0.

Thus Compound TCP does NOT back off earlier.  In fact, the feature is  
that it does NOT back off on a packet drop if it is on a high  
bandwidth, high latency network!


uTP, by being a "Minimum of two window" algorithm, is the opposite, as  
it is AT MOST AIMD-only for fairness/agressiveness, precisely because  
it takes advantage of the side effect of delay based congestion  
control: it backs off earlier than AIMD-based flows so it gets starved  
out by AIMD-based flows (hopefully).


In almost all other TCP applications, the starvation problem faced by  
delay-based window sizing is a problem.  For a scavenger-class  
protocol like uTP, it is potentially a feature.

Thus all TCP stacks are AT LEAST AIMD-aggressive, including Compound  
TCP, as it uses delay-based metrics to have the exact opposite  
behavior: attempting to grab more bandwidth in conditions where AIMD- 
based systems fail.  Because any TCP stack that is not AT LEAST AIMD- 
aggressive is going to face starvation under congestion.



The open question is "how much friendlier" is (min(AIMD, delay based))  
in practice.

Delay-based measurements are notoriously noisy and jitter prone, so it  
may very well become "just AIMD" in terms of ISP congestion behavior,  
which means it isn't more aggressive than TCP but isn't less  
aggressive, thus it isn't a real scavenger-class service.


And this isn't about replacing TCP, its about alternate congestion  
control algorithms which are friendlier than AIMD (TCP Reno).

The window sizing algorithms from uTP could just as easily be an  
option in a TCP stack (and I've argued it should be a single-sided  
option: one side of a TCP stack should be able to control both sending  
and receiving windows in this manner).

And its really just observing that "Not all flows are really equal  
under congestion", so if you can designate a flow as "less important",  
you get better aggregate behavior, and because you have some points of  
congestion (eg, the user's uplink) where only the individual user  
experiences it, there are incentives for applications to actually use  
such a property.


_______________________________________________
ledbat mailing list
ledbat@ietf.org
https://www.ietf.org/mailman/listinfo/ledbat