Re: [p2pi] [tana] [tsv-area] TANA proposed charter

Nicholas Weaver <nweaver@ICSI.Berkeley.EDU> Wed, 22 October 2008 12:45 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 6A0DF3A6A9B; Wed, 22 Oct 2008 05:45:10 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 12F303A6804; Wed, 22 Oct 2008 05:45:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.683
X-Spam-Status: No, score=-5.683 tagged_above=-999 required=5 tests=[AWL=0.916, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VCy2NeSRdGtf; Wed, 22 Oct 2008 05:45:03 -0700 (PDT)
Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU []) by (Postfix) with ESMTP id 91D1A3A692F; Wed, 22 Oct 2008 05:45:03 -0700 (PDT)
Received: from [IPv6:::1] (fruitcake []) by fruitcake.ICSI.Berkeley.EDU ( with ESMTP id m9MCjmcd022265; Wed, 22 Oct 2008 05:45:59 -0700 (PDT)
Message-Id: <>
From: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
To: Rolf Winter <>
In-Reply-To: <>
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Wed, 22 Oct 2008 05:45:48 -0700
References: <> <> <>
X-Mailer: Apple Mail (2.929.2)
Cc:, Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>,,, Michael Welzl <>
Subject: Re: [p2pi] [tana] [tsv-area] TANA proposed charter
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: P2P Infrastructure Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"

On Oct 22, 2008, at 1:49 AM, Rolf Winter wrote:
>> Besides, there are ISPs that are worried about the effect
>> that P2P have on other applications when the link is
>> saturated, but otherwise they do not care. P2P would be
>> treated like best effort in non-saturated situations (a more
>> ECN type approach).
> That is exactly the point. P2P should not "harm" inelastic traffic.  
> In order to do that, queues should not build up as a consequence of  
> the P2P traffic. The charter according to my interpretation says  
> that the most suitable of the set of available means should be used  
> or any combination of it that makes sense.

There are actually at least two sources of harm that BitTorrent and  
related bulk-data P2P protocols can cause:

A)  Self harm on access-link buffers:  Simply because the protocol  
will very easily saturate uplinks for residences, and devices ON the  
uplinks (NAT boxes, etc) are often criminally overbuffered.  This is  
not really affected by the multiple-TCP flow nature of the protocols  
in question, as a single TCP flow will happily grab the full buffer as  
well, but P2P protocols tend to be the heaviest user of the uplink.

B)  Congestion on shared-access uplinks:  DOCSIS is explicitly a  
shared-bandwidth media.  Thus a few users of a P2P protocol (many- 
flow, full-data-rate) can acquire a large amount of the shared channel.

Part of the problem:  A and B may require different strategies and  

A is the one which the P2P developers are most interested in, because  
that directly harms their customers.  If you provide a solution to A,  
it will be deployed, and quickly.

B is the source of conflicts between the ISP and P2P, why ISPs have  
tried managing the upload rate, and why some ISPs, notably Comcast,  
are shifting to a network-enforced fairness approach.

Dealing with B is what I personally consider essential for a scavenger  
class protocol, and the more interesting problem, but I think it may  
be trickier, because you can solve A but not B with delay-based hacks.

But solving B also has another problem:  If P2P program Gamma and P2P  
program Delta are sharing the same uplink, and Gamma implements a  
scavenger protocol, its going to get squeezed out if congestion occurs  
on the uplink and, if any reciprocity is involved, the user's download  
is also going to suffer.

So there may be reasons for P2P developers to use techniques which  
solve A AND B, but there doesn't seem to be so clear an incentive for  
such solutions over solutions for A alone.

p2pi mailing list