Re: [ledbat] "Oh Noes, the Internetz will Melt Down..."

Nicholas Weaver <nweaver@ICSI.Berkeley.EDU> Mon, 01 December 2008 21:54 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 B9C8B28C0E4; Mon, 1 Dec 2008 13:54:56 -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 8617C28C0FA for <ledbat@core3.amsl.com>; Mon, 1 Dec 2008 13:54:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 jUlUi8DEF-0C for <ledbat@core3.amsl.com>; Mon, 1 Dec 2008 13:54:54 -0800 (PST)
Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id BE95228C0D8 for <ledbat@ietf.org>; Mon, 1 Dec 2008 13:54:54 -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 mB1LrYFg017872; Mon, 1 Dec 2008 13:54:44 -0800 (PST)
Message-Id: <663E9704-FF9C-4604-A1B9-236505608247@ICSI.Berkeley.EDU>
From: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
To: Richard Bennett <richard@bennett.com>
In-Reply-To: <49345115.2000407@bennett.com>
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Mon, 01 Dec 2008 13:53:34 -0800
References: <34F38819-7926-4659-952B-3059B2B45C56@icsi.berkeley.edu> <50FCE54A-9524-4193-BBA6-6D60FB58FBBC@nokia.com> <FCA794787FDE0D4DBE9FFA11053ECEB61AFFFAF140@NA-EXMSG-C110.redmond.corp.microsoft.com> <49345115.2000407@bennett.com>
X-Mailer: Apple Mail (2.929.2)
Cc: "ledbat@ietf.org" <ledbat@ietf.org>, Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
Subject: Re: [ledbat] "Oh Noes, the Internetz will Melt Down..."
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: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: ledbat-bounces@ietf.org
Errors-To: ledbat-bounces@ietf.org

On Dec 1, 2008, at 1:03 PM, Richard Bennett wrote:

> I'm glad so many people have read my article, and I'd be happy to  
> discuss it at length if it's appropriate. Broadband Reports, the  
> info hub for file-sharers, ran an article on uTorrent 1.9 over the  
> weekend under the title: "New UDP uTorrent Takes Aim At Throttling,"  
> highlighting the value of UDP-based file sharing for avoiding TCP- 
> based fair traffic systems. It's clear that the users of BitTorrent  
> see this as simply another means of grabbing more network resources.
>
> That being said, I'll gladly stipulate that BitTorrent, Inc., means  
> well and has a heart of gold. But what happens when users can tune  
> congestion avoidance and backoff parameters through a GUI? I'll go  
> out on a limb here and say some of them may not be altruistic.

Where is the suggestion that users will be able to control the  
congestion control parameters?

IF the algorithm is equivalent to what was presented at the IETF,  
namely, a delay-based ADDITION to a TCP-like AIMD, this will only have  
a net benefit, as this will still stabilize out like any other TCP  
flow (so no effect on the ISP congestion problem one way or the  
other), but will have a huge benefit on the buffer-oversizing  
congestion problem.


Likewise, the notion that this can avoid traffic management is pretty  
delusional.  The only thing a UDP shift avoids is RST-injection based  
management, which is a crude tool.  Any in-path management (which,  
btw, Sandvine supports, but was simply not deployed in this way by  
Cox, Comcast, and others) can block a UDP flow just as easily as a TCP  
flow.  Likewise, router ACL injection can block flows as well.


There are plenty of things to dislike about bulk-data P2P.  But this  
is probably not one of them.

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