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

Lars Eggert <lars.eggert@nokia.com> Mon, 01 December 2008 16:23 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 B246E3A68A9; Mon, 1 Dec 2008 08:23:51 -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 224023A68A9 for <ledbat@core3.amsl.com>; Mon, 1 Dec 2008 08:23:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 FMcIV69mBJ-C for <ledbat@core3.amsl.com>; Mon, 1 Dec 2008 08:23:42 -0800 (PST)
Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id DDD313A6816 for <ledbat@ietf.org>; Mon, 1 Dec 2008 08:23:37 -0800 (PST)
Received: from [IPv6:2001:2060:40:2:219:e3ff:fe06:dc74] ([IPv6:2001:2060:40:2:219:e3ff:fe06:dc74]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id mB1GN5TZ038043 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 1 Dec 2008 18:23:06 +0200 (EET) (envelope-from lars.eggert@nokia.com)
Message-Id: <50FCE54A-9524-4193-BBA6-6D60FB58FBBC@nokia.com>
From: Lars Eggert <lars.eggert@nokia.com>
To: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
In-Reply-To: <34F38819-7926-4659-952B-3059B2B45C56@icsi.berkeley.edu>
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Mon, 01 Dec 2008 18:23:05 +0200
References: <34F38819-7926-4659-952B-3059B2B45C56@icsi.berkeley.edu>
X-Mailer: Apple Mail (2.929.2)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (mail.fit.nokia.com [IPv6:2001:2060:40:1::123]); Mon, 01 Dec 2008 18:23:06 +0200 (EET)
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on fit.nokia.com
X-Virus-Status: Clean
Cc: "ledbat@ietf.org" <ledbat@ietf.org>
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="===============1141947743=="
Sender: ledbat-bounces@ietf.org
Errors-To: ledbat-bounces@ietf.org

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 list
ledbat@ietf.org
https://www.ietf.org/mailman/listinfo/ledbat