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

"Robb Topolski" <robb@funchords.com> Thu, 20 November 2008 23:06 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 404B73A6935; Thu, 20 Nov 2008 15:06:32 -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 CFB413A699A for <ledbat@core3.amsl.com>; Thu, 20 Nov 2008 15:06:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.24
X-Spam-Level:
X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6]
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 Ermik5OBTvBY for <ledbat@core3.amsl.com>; Thu, 20 Nov 2008 15:06:30 -0800 (PST)
Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.238]) by core3.amsl.com (Postfix) with ESMTP id 9A03B3A67F0 for <ledbat@ietf.org>; Thu, 20 Nov 2008 15:06:30 -0800 (PST)
Received: by rv-out-0506.google.com with SMTP id b25so650357rvf.49 for <ledbat@ietf.org>; Thu, 20 Nov 2008 15:06:29 -0800 (PST)
Received: by 10.141.212.5 with SMTP id o5mr1490301rvq.247.1227222389411; Thu, 20 Nov 2008 15:06:29 -0800 (PST)
Received: by 10.141.69.3 with HTTP; Thu, 20 Nov 2008 15:06:29 -0800 (PST)
Message-ID: <3efc39a60811201506s120a731dv50cb01d61c26ef59@mail.gmail.com>
Date: Thu, 20 Nov 2008 15:06:29 -0800
From: Robb Topolski <robb@funchords.com>
To: Nicholas Weaver <nweaver@icsi.berkeley.edu>
In-Reply-To: <7C1BD40A-C0F3-465E-A438-8C25DD66E1F8@icsi.berkeley.edu>
MIME-Version: 1.0
References: <27294E60-8183-47F5-9672-D712E4D85493@icsi.berkeley.edu> <3efc39a60811201233n62b4265ar566228d4e4f60d12@mail.gmail.com> <7C1BD40A-C0F3-465E-A438-8C25DD66E1F8@icsi.berkeley.edu>
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-Type: multipart/mixed; boundary="===============1860956807=="
Sender: ledbat-bounces@ietf.org
Errors-To: ledbat-bounces@ietf.org

Replies inline...

On Thu, Nov 20, 2008 at 12:48 PM, Nicholas Weaver <nweaver@icsi.berkeley.edu
> wrote:

>
> In the aggregate, a bulk-data P2P system must upload as much as it
> downloads, and your performance becomes limited by uplink bandwidth.
>

We can start here, although I know it's not the crux of your point.

"In the aggregate," true, but "your performance" is not in that context --
its yours alone.

I think the value of 1:1 up:down participation on an individual basis is
overrated if not unhealthy (if not unattainable).  There will always be some
last downloader in a swarm -- who is he going to upload to?  How many swarms
that should have died stay alive (and perform poorly) in a futile effort for
someone to reach their 1:1 goal?

Such goals forget that some people value getting their own interests out
there, and are motivated to spend their energy (and bandwidth) in doing that
(quickly/broadly/efficiently etc) and that activity is further skewed based
on their preferences (linux, anime, porn, first-run movies, software, old
music, amateur documentaries).



> When you have a significant group of hosts with a near-zero uplink, these
> hosts contribute very little to the overall performance of the system.
>


> EG, if 1/2 of the systems are cable modems with 1 Mbps uplink, and 1/2 are
> behind 128 kb uplink, the aggregate system bandwidth is 8-1: for every
> single bit of uplink from the DSL lines, you get 8x the uplink from the
> cable modem lines.
>
> At such a point, you might as well, from an aggregate system viewpoint,
> reduce the upload of the DSL hosts to 0: they are contributing so little,
> but experiencing a huge degredation of performance that MUST occur because
> of the minimum buffer size of a few packets.
> .
>


If two dial-up users are reciprocatively sharing chunks of files, that's two
slots from the universe of other peer's uploading slots that they won't
occupy.  It's an efficient pairing.  It would be inefficient for one of
these dialup users to occupy the upload slot of a cablemodem user for any
extended time.  (Some clients will open an additional slot if this happens,
but that enhanced behavior is optional, and an uploader still won't spend
significant time servicing a slow downloader).

Could those 128 Kb uploaders service ISDN or Satellite users?  Or maybe pair
up with a dial-up user (slow but better than 1 Mbps transferring to
dial-up)?




> You can NEVER size a buffer for a DSL modem for normal TCP such that you
> will get good interactive behavior while a full rate upload occurs.
>

This is the part that got my attention.  These aren't like the old phone
modems with flow control, so that's why they have this problem?  (This isn't
really a P2P-related problem, is it?)



> In contrast, you can use an effectivev 100-150ms buffer on the cable
> modems, so they can get full rate TCP but at the same time, not step on
> their interactive traffic (subequent message coming on that).
>
>
I'll watch for it.  I wasn't aware that one had less of a problem than the
other.

Thanks Nick!

Robb


-- 
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