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

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

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 39ED028C133; Tue, 21 Oct 2008 11:49:36 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 76A0B3A6AA1; Tue, 21 Oct 2008 11:49:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.574
X-Spam-Status: No, score=-5.574 tagged_above=-999 required=5 tests=[AWL=1.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ENSoIUxlL4CM; Tue, 21 Oct 2008 11:49:33 -0700 (PDT)
Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU []) by (Postfix) with ESMTP id 8A9EC3A6985; Tue, 21 Oct 2008 11:49:33 -0700 (PDT)
Received: from [IPv6:::1] (fruitcake []) by fruitcake.ICSI.Berkeley.EDU ( with ESMTP id m9LInifF012737; Tue, 21 Oct 2008 11:50:45 -0700 (PDT)
Message-Id: <086D03E5-61BE-43F5-A750-3539AF47F13E@ICSI.Berkeley.EDU>
From: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
To: "Narayanan, Vidya" <>
In-Reply-To: <>
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Tue, 21 Oct 2008 11:50:44 -0700
References: <> <> <> <> <> <4D4C2826-077A-4948-9A92-5EC393DC88AF@ICSI.Berkeley.EDU> <>
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] [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 21, 2008, at 11:33 AM, Narayanan, Vidya wrote:

> I'll start by saying that I do like the charter and believe that it  
> is scoped correctly.
> I do, however, share some of the concerns that Nicholas has raised.   
> We are talking about bulk data p2p transfers here, not necessarily  
> just limited to file transfers.  This does mean p2p models of video,  
> games that exchange large amounts of data (e.g., World of Warcraft),  
> large medical data (e.g., high resolution imaging) transfer, etc.  
> fall into this category.  Of course, for some of these applications,  
> the answer may simply be that TANA is not applicable and hence,  
> should not be used.  However, I do think there are more grades to  
> this.

Well, it also depends too:

The medical data is point to point, not P2P.  A single TCP flow works  
well, and by being on real network, shouldn't experience the buffer  
issues present in home gateways, and by being a single flow, doesn't  
have the congestion-monopolization properties that P2P transfer  
programs have.

Warcraft is not using P2P for playing, rather it is using P2P to save  
money in the data transfer of "patches", which include large amounts  
of content (textures, models, etc) (thus my rant on cost shifting).

> Another interesting piece of data is that for the first time in many  
> years, http has overtaken p2p traffic in some markets, primarily  
> driven by video download applications such as YouTube.  Thanks to  
> http being the common firewall transport mechanism, much of the  
> video now runs over TCP.  So, is it really as cut and dry as the  
> bulk data P2P traffic needing to yield to Internet traffic?  As long  
> as it is about some background file transfer, perhaps that  
> philosophy will just work.  But, if the P2P app is also a video app,  
> the answer is probably more complex.

Additionally, on the video apps, to my mind these are often badly  
done, and badly done in a way that the transport layer can do nothing  

Take YouTube for example.  Its flash-based structure is not suitable  
(deliberately so!) for significant offline viewing.  Yet its buffer  
strategy is "Fill-er-up completely", when many viewers will not stick  
around to watch the whole thing: a substantial waste although it does  
improve seek time.

(Comedy Central's, OTOH, has a maximum buffer of about 10 seconds, so  
"stop in the middle" doesn't waste bandwidth).

Yet all of these apps don't also properly recognize "I don't have  
ENOUGH bandwidth to keep up with realtime", and so don't (aren't  
capable of in flash?) of switching to a lower-bitrate encoded source.

p2pi mailing list