IETF Logo Mail Archive

Re: [ledbat] Note well on the BitTorrent problem on the example...

Nicholas Weaver <nweaver@ICSI.Berkeley.EDU> Sun, 23 November 2008 16:26 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 EC9D03A6837; Sun, 23 Nov 2008 08:26:36 -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 774D33A6837 for <ledbat@core3.amsl.com>; Sun, 23 Nov 2008 08:26:36 -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 KhOXdASdpPMX for <ledbat@core3.amsl.com>; Sun, 23 Nov 2008 08:26:35 -0800 (PST)
Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id D64D83A67DB for <ledbat@ietf.org>; Sun, 23 Nov 2008 08:26:35 -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 mANGPrrH025168; Sun, 23 Nov 2008 08:26:33 -0800 (PST)
Message-Id: <ADDE3DF9-A645-4540-AEED-6BB779BCB19C@ICSI.Berkeley.EDU>
From: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
To: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
In-Reply-To: <DC8385BC-9899-48B1-861F-14D94CCB105E@icsi.berkeley.edu>
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Sun, 23 Nov 2008 08:25:53 -0800
References: <27294E60-8183-47F5-9672-D712E4D85493@icsi.berkeley.edu> <80ECA117-243B-49E0-954D-1EF9434E6965@shlang.com> <DC8385BC-9899-48B1-861F-14D94CCB105E@icsi.berkeley.edu>
X-Mailer: Apple Mail (2.929.2)
Cc: ledbat@ietf.org
Subject: Re: [ledbat] Note well on the BitTorrent problem on the example...
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 Nov 23, 2008, at 8:12 AM, Nicholas Weaver wrote:

> I know your example is about a single full-rate TCP flow, not  
> BitTorrent.  But your all about the "bad queue" congestion problem,  
> with occurs ALMOST exclusively for people in such situations when  
> doing P2P activity over web-surfing.

Well, there is backup like applications and photo uploading, but  
backup/synchronization over the WAN still seems to be a niche market  
(iDisk I think is the biggest player).

But in those cases, the activity can easily be time-shifted away from  
usage, rather than an integral part of getting content.

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

v2.23.0 | Report a Bug | By Email