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

Nicholas Weaver <nweaver@ICSI.Berkeley.EDU> Tue, 21 October 2008 17:40 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id F3FED28C162; Tue, 21 Oct 2008 10:40:37 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id EDFF23A6AC1; Tue, 21 Oct 2008 10:40:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.54
X-Spam-Status: No, score=-5.54 tagged_above=-999 required=5 tests=[AWL=1.059, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ym1k5k-bK06S; Tue, 21 Oct 2008 10:40:35 -0700 (PDT)
Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU []) by (Postfix) with ESMTP id 2412C3A68E1; Tue, 21 Oct 2008 10:40:35 -0700 (PDT)
Received: from [IPv6:::1] (fruitcake []) by fruitcake.ICSI.Berkeley.EDU ( with ESMTP id m9LHfkrN004602; Tue, 21 Oct 2008 10:41:46 -0700 (PDT)
Message-Id: <4D4C2826-077A-4948-9A92-5EC393DC88AF@ICSI.Berkeley.EDU>
From: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
To: Stanislav Shalunov <>
In-Reply-To: <>
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Tue, 21 Oct 2008 10:41:46 -0700
References: <> <> <> <> <>
X-Mailer: Apple Mail (2.929.2)
Cc:, Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>,, TSV Area <>, "Eddy, Wesley M. \(GRC-RCN0\)\[VZ\]" <>
Subject: Re: [p2pi] [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 21, 2008, at 10:06 AM, Stanislav Shalunov wrote:
>> Yet why would a bulk-data content provider want to USE it?
> This is a great question and it deserves a more detailed answer than  
> this, but let me try, briefly, to provide one reason to use it:
> Because the user wants to use the Internet while P2P app is doing  
> whatever it is doing.  Or the user will uninstall the app.
> The content provider serves at the leisure of the user.  The user is  
> willing to share uplink capacity as long as the sharing is largely  
> invisible.  The user will be upset by uploads that affect the user's  
> ability to use the network for interactive applications and web  
> browsing.
> (There are other scenarios, particularly with shared congestion and  
> traffic management, that generally push the content provider to be  
> nicer, so the above is just one example.)

However, the "Internet Not Working" effect is a subpiece of the  
overall problem:  It is buffer occupancy on end-user buffers where the  
buffers are on the order of 1+ RTT (often 1+ Second!).   Otherwise,  
the incentives are to be as UN-friendly as possible, as the  
externalities of congestion, EXCEPT at the access-link device, are  
applied to other users.

Thus the P2P application provider can use existing RTT-based  
congestion control techniques to look for a greater than .25 RTT  
increase in delay, and respond to it by shrinking window sizes until  
the RTT drops and at-that-point, call it good.

In fact, simply feed this into bandwidth estimation:  Do an initial  
uncongested bandwidth estimation on startup (packet-pair measurement)  
to other peers (eliminates the "select a bandwidth" checkbox, bonus!),  
attempt to allocate to the whole pipe-5% with your TCP flows, and do  
an immediate backoff/slow ramp-back when you see RTTs increasing to  

Although a new class of congestion control that would do a true end-to- 
end job would be a better solution, the partial solution is complete  
from the P2P application provider's viewpoint: it fixes the "We break  
the net for everything else" effect on the user, while still keeping  
the very agressive (many-flow TCP) properties of P2P for the rest of  
the network.

Or at least until you bribe the NAT box vendors to implement some  
active queue management.

p2pi mailing list