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

"Robb Topolski" <robb@funchords.com> Mon, 01 December 2008 21: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 A927A3A682E; Mon, 1 Dec 2008 13:37:08 -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 5DDB93A682E for <ledbat@core3.amsl.com>; Mon, 1 Dec 2008 13:37:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Level:
X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
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 AR704-UMbi15 for <ledbat@core3.amsl.com>; Mon, 1 Dec 2008 13:37:05 -0800 (PST)
Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.236]) by core3.amsl.com (Postfix) with ESMTP id 10E5D3A6874 for <ledbat@ietf.org>; Mon, 1 Dec 2008 13:37:03 -0800 (PST)
Received: by rv-out-0506.google.com with SMTP id b25so2572236rvf.49 for <ledbat@ietf.org>; Mon, 01 Dec 2008 13:36:58 -0800 (PST)
Received: by 10.140.161.11 with SMTP id j11mr5435856rve.86.1228167417888; Mon, 01 Dec 2008 13:36:57 -0800 (PST)
Received: by 10.141.20.16 with HTTP; Mon, 1 Dec 2008 13:36:57 -0800 (PST)
Message-ID: <3efc39a60812011336n7773a715te46df07bf5e54321@mail.gmail.com>
Date: Mon, 01 Dec 2008 13:36:57 -0800
From: Robb Topolski <robb@funchords.com>
To: "ledbat@ietf.org" <ledbat@ietf.org>
In-Reply-To: <49345115.2000407@bennett.com>
MIME-Version: 1.0
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>
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-Type: multipart/mixed; boundary="===============0504636668=="
Sender: ledbat-bounces@ietf.org
Errors-To: ledbat-bounces@ietf.org

I didn't read his article.  This is in reply to his message only.


> But what happens when users can tune congestion avoidance and backoff
> parameters through a GUI?
>

1.  They can tune parameters in TCP now with REGEDIT in Windows or by using
Linux.  And even that doesn't limit the possibility that they could if they
wanted to -- users are already swapping out Windows TCPIP.SYS (have been for
years) for ones hacked to work as they want it to.  So, having this ability,
what are they changing?  Are they defeating congestion control boundaries?
Nope.  They're only defeating a half-open TCP limit designed to avoid the
fast spread of worms.

2.  (Until I'm blue in the face, I swear), P2P developers generally are fans
of the Internet and are unlikely to intentionally develop in ways harmful to
the network.  I don't know how else to day it.  They don't ##### where they
live.  They surf websites and take VOIP calls, too.

It's clear that the users of BitTorrent see this as simply another means of
> grabbing more network resources.
>

3.  I'm not agreeing with that conclusion, as it's just as plausible that
they want to reduce their own support load; a lot of effort is dedicated to
teaching users how to avoid overrunning the buffers in their modem.
However, if "more network resources" are they're there to "grab" and doing
so doesn't interfere with anybody, then so what?  The design of TCP is to
keep trying to grab more network resources, and most applications do nothing
to change that behavior.

Broadband Reports, the info hub for file-sharers,
>

4.  Hardly. But as clear as it is to you that users of BitTorrent see this
as simply another means of grabbing more network resources, it's clear to me
that some people are never pursuaded from their consistent droning despite
any amount of facts and evidence presented to the contrary.

Robb Topolski

On Mon, Dec 1, 2008 at 1:03 PM, Richard Bennett <richard@bennett.com> 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.
>
> RB
>
>
>
> Murari Sridharan wrote:
>
> Lars I think you are right, stas can confirm. I was trying to get more details on the actual protocol and here is a post I found from BitTorrent VP
>
> ------
> A comment from BitTorrent on UTP:
>
> Firon posted already about UTP:
> ******
> uTP, the micro transport protocol. This UDP-based reliable transport is designed to minimize latency, but still maximize bandwidth when the latency is not excessive. We use this for communication between peers instead of TCP, if both sides support it. In addition, we use information from this transport, if active, to control the transfer rate of TCP connections. This means uTorrent, when using uTP, should not kill your net connection - even if you do not set any rate limits.
> ******
>
> Just to re-iterate and offer a few more details (there's some pretty wild press reports popping up):
> Firon described uTP completely accurately.
> uTP is the result of a couple of years of work to try to make a Bittorrent protocol that works better on the internet.
>
> The switch to uTP is at this point purely experimental, but the design objective (counter to some reports in the press) is actually to offer better congestion control than TCP offers, but maintain the same level of performance (speed).
> Better congestion control is good for everyone - for users (VOIP, Gamers etc.) as well as for ISPs.
> Same performance is what users have come to expect from their BitTorrent application - unless we can offer the same performance, then people will switch to a different BitTorrent client. (In reality we may be able to offer faster speeds too in many circumstances, but this is a byproduct and not the main objective.)
>
> uTP is our UDP-based implementation of the BitTorrent protocol.
> Normally BitTorrent is implemented on top of TCP which is the standard congestion control mechanism for the internet.
> It so happens that the congestion control mechanism inside TCP is quite crude and problematic. It only detects congestion on the internet once "packet loss" has occurred - i.e. once the user has lost data and (probably) noticed there is a problem. The problems of TCP are fairly well known in technical circles, but it doesn't get fixed as TCP is one of those protocols that is implemented in every webserver and application (e.g. browsers, bittorrent clients) on the internet. Co-ordinating a giant upgrade is a very long process.
>
> Because BitTorrent publishes the world's most popular BitTorrent clients AND because these clients are talking mostly to each other (not to web servers), then we have an opportunity to detect end-to-end congestion and implement a protocol that can detect problems very quickly and throttle back accordingly so that BitTorrent doesn't slow down the internet connection and Gamers and VOIP users don't notice any problems. This is our objective.
>
> This is great news for users of the internet and even for ISPs as it should mean that people make far more efficient use of internet bandwidth, but don't over-use it to destruction. If uTP is successful, then internet congestion due to BitTorrent protocol could become a thing of the past. Of course there are many other applications that use the internet and they may also cause congestion, but we can only control what we do. Having said that, given that some press reports suggest that BitTorrent traffic constitutes half of all traffic on the internet, our technology might have a profound impact. We're trying to do our bit to be responsible citizens on the internet.
>
> While uTP is for now a proprietary BitTorrent protocol, we are also co-chairing an IETF group to address these issues. Hopefully that will lead to solutions that can be standardized and broadly adopted in due course.
>
> Simon Morris
> VP Product Management
> BitTorrent, Inc.
>
> -----Original Message-----
> From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org <ledbat-bounces@ietf.org>] On Behalf Of Lars Eggert
> Sent: Monday, December 01, 2008 8:23 AM
> To: Nicholas Weaver
> Cc: ledbat@ietf.org
> Subject: Re: [ledbat] "Oh Noes, the Internetz will Melt Down..."
>
> On 2008-12-1, at 17:56, Nicholas Weaver wrote:
>
>
>  The typical Fear Mongering "UDP Death Uhz Da Internetz":http://www.theregister.co.uk/2008/12/01/richard_bennett_utorrent_udp/
>
>  Wow. Talk about jumping to conclusions. That is quite an "article".
>
>
>
>  However, the question is, does anyone have insight into the "uTP"
> congestion control protocol and what it is actually doing?
>
>
>  See http://forum.utorrent.com/viewtopic.php?id=49813
>
> "What is in 1.9:
> uTP, the micro transport protocol. This UDP-based reliable transport is designed to minimize latency, but still maximize bandwidth when the latency is not excessive. We use this for communication between peers instead of TCP, if both sides support it. In addition, we use information from this transport, if active, to control the transfer rate of TCP connections. This means uTorrent, when using uTP, should not kill your net connection - even if you do not set any rate limits.
>
> What was in 1.8.1:
> uTP, but connection attempts were not initiated by default, and there was no control over TCP as described above. You can enable it, but likely you will see the uTP connections not transfering much data, because they are pushed out of the way by TCP."
>
> This last bit sounds a lot like if uTP is is using some sort of less- than-best-effort CC. (I believe someone mentioned in Minneapolis that utorrent would implement BitTorrent's DNA - maybe this is it?
>
> Lars
>
>
> _______________________________________________
> ledbat mailing listledbat@ietf.orghttps://www.ietf.org/mailman/listinfo/ledbat
>
>
> _______________________________________________
> ledbat mailing list
> ledbat@ietf.org
> https://www.ietf.org/mailman/listinfo/ledbat
>
>


-- 
Robb Topolski (robb@funchords.com)
Hillsboro, Oregon USA
http://www.funchords.com/
_______________________________________________
ledbat mailing list
ledbat@ietf.org
https://www.ietf.org/mailman/listinfo/ledbat