[ledbat] Another uTP story by alarmist author

Richard Bennett <richard@bennett.com> Fri, 05 December 2008 19:52 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 A9F4C3A6B4C; Fri, 5 Dec 2008 11:52:09 -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 496063A6B4C for <ledbat@core3.amsl.com>; Fri, 5 Dec 2008 11:52:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.688
X-Spam-Level:
X-Spam-Status: No, score=-0.688 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_HTML_ONLY=1.457]
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 mv17tR3fL3wK for <ledbat@core3.amsl.com>; Fri, 5 Dec 2008 11:52:03 -0800 (PST)
Received: from outbound-mail-135.bluehost.com (outbound-mail-135.bluehost.com [67.222.39.25]) by core3.amsl.com (Postfix) with SMTP id C65F03A6A36 for <ledbat@ietf.org>; Fri, 5 Dec 2008 11:52:03 -0800 (PST)
Received: (qmail 13649 invoked by uid 0); 5 Dec 2008 19:51:54 -0000
Received: from unknown (HELO host46.hostmonster.com) (74.220.202.46) by outboundproxy4.bluehost.com with SMTP; 5 Dec 2008 19:51:54 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bennett.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=R/I7KMTU5wjeTx1iQxY6be2aPt/jSAbVIBXrO5tqXUyxp8PRufdMBTYHRrL/DH60a7dyBGTLNe/QEOv43mkHKn1b+nudCFuVrpGJhPDN86hTSHbgw4rvaLlUAfxAsTMK;
Received: from c-24-5-203-48.hsd1.ca.comcast.net ([24.5.203.48] helo=[192.168.1.101]) by host46.hostmonster.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <richard@bennett.com>) id 1L8giP-0002so-Sf; Fri, 05 Dec 2008 12:51:53 -0700
Message-ID: <49398658.2020007@bennett.com>
Date: Fri, 05 Dec 2008 11:51:52 -0800
From: Richard Bennett <richard@bennett.com>
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: ledbat@ietf.org
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>
In-Reply-To: <b98e548c0812020127i2f6ebaefqc71457e990b3072b@mail.gmail.com>
X-Identified-User: {842:host46.hostmonster.com:bennett1:bennett.com} {sentby:smtp auth 24.5.203.48 authed with richard@bennett.com}
Subject: [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-Type: multipart/mixed; boundary="===============1248989137=="
Sender: ledbat-bounces@ietf.org
Errors-To: ledbat-bounces@ietf.org

Readers enjoyed by last article on BitTorrent uTP so much I've done a follow-up for The Register, available here:

http://www.theregister.co.uk/2008/12/05/richard_bennett_bittorrent_udp/" rel="nofollow">http://www.theregister.co.uk/2008/12/05/richard_bennett_bittorrent_udp/

It raises some issues that are relevant to the deliberation of this group, mentions you all by name, and is a quick read. Here's a teaser:

The internet's TCP/IP protocol doesn't work very well. As the internet's traffic cop, it's supposed to prevent applications from overloading the network, but it's at a loss when it comes to managing P2P applications. This deficiency, generally known to network engineers but denied by net neutrality advocates, has been a central issue in the net neutrality debate. BitTorrent Inc has now weighed in on the side of the TCP/IP critics.

The next official release of the uTorrent client – currently in alpha test – replaces TCP with a custom-built transport protocol called uTP, layered over the same UDP protocol used by VoIP and gaming. According to BitTorrent marketing manager Simon Morris, the motivation for this switch (which I incorrectly characterized in The Register earlier this week as merely another attempt to escape traffic shaping) is to better detect and avoid network congestion.

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 http://research.microsoft.com/%7Ekuntan/index_files/Page315.htm" target="_blank" rel="nofollow">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.

It remains to be seen whether uTP is the best approach. The company has touted its close relationships with ISPs and the IETF’s LEDBAT task group, but has so far shared none of the specifics of uTP operation in public fora. The PowerPoints they’ve shared with the IETF are encouraging, but they’re a long way from the source code, simulations, and hard data from impartial sources that are prerequisite to any new protocol standard.


Enjoy,

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