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

"Narayanan, Vidya" <> Tue, 21 October 2008 18:32 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 27D553A6B8C; Tue, 21 Oct 2008 11:32:45 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 752E13A6B8C; Tue, 21 Oct 2008 11:32:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.173
X-Spam-Status: No, score=-103.173 tagged_above=-999 required=5 tests=[AWL=-0.574, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id O9YZ9Nu+E26e; Tue, 21 Oct 2008 11:32:43 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3DCEB3A6B89; Tue, 21 Oct 2008 11:32:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=qcdkim; t=1224614038; x=1256150038; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Narayanan,=20Vidya"=20<>|To: =20Nicholas=20Weaver=20<nweaver@ICSI.Berkeley.EDU>,=0D=0A =20=20=20=20=20=20=20=20Stanislav=20Shalunov=0D=0A=09<sha>|CC:=20""=20<> ,=20""=20<>,=0D=0A=20=20=20=20 =20=20=20=20TSV=20Area=0D=0A=09<>,=20Bru ce=20Davie=20<>,=0D=0A=20=20=20=20=20=20 =20=20"Eddy,=20Wesley=20M.=0D=0A=20(GRC-RCN0)[VZ]"=20<Wes>|Date:=20Tue,=2021=20Oct=202008=2011: 33:26=20-0700|Subject:=20RE:=20[tana]=20[p2pi]=20[tsv-are a]=20TANA=20proposed=20charter|Thread-Topic:=20[tana]=20[ p2pi]=20[tsv-area]=20TANA=20proposed=20charter |Thread-Index:=20AckzpE8VwMHEv0SxSwWTvEiWLooraAAAjXkQ |Message-ID:=20<BE82361A0E26874DBC2ED1BA244866B9284E7711@>|References:=20<AE465507-305C>=0D=0A=09<B5A5E01F9387>=0D=0A =09<>=0D=0A =09<9F472A6A-F3F3-4616-9ACE-4BD24D77FBCD@icsi.berkeley.ed u>=0D=0A=09<19AE9AF4-E857-41EF-BF3E-B831F4EB8159@shlang.c om>=0D=0A=20<4D4C2826-077A-4948-9A92-5EC393DC88AF@ICSI.Be rkeley.EDU>|In-Reply-To:=20<4D4C2826-077A-4948-9A92-5EC39 3DC88AF@ICSI.Berkeley.EDU>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5411"=3B=20a=3D"11136557"; bh=FIa8oFeNU858lLORm50NuJDqbULtULi9XlS8t1y84gU=; b=Hlu9+4W2zzqc4Ct7utS8DUuQzvdClrvkUvcBZBxHSdF6rXDusQxhaZqS ac0JJjQLna8/ymfCab0UXWda/OMVD5qYjD8ZItfpWK11rHz76pbbhlZ0B Oe4db305n/ZvKICdJqxUZuoNvWol+s1A1RFC5CRUGELcalbendDMkU8M8 U=;
X-IronPort-AV: E=McAfee;i="5300,2777,5411"; a="11136557"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Oct 2008 11:33:30 -0700
Received: from ( []) by (8.14.2/8.14.2/1.0) with ESMTP id m9LIXUGf031892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 21 Oct 2008 11:33:30 -0700
Received: from ( []) by (8.14.2/8.14.2/1.0) with ESMTP id m9LIXTaD007182 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 21 Oct 2008 11:33:29 -0700
Received: from ( by ( with Microsoft SMTP Server (TLS) id 8.1.311.2; Tue, 21 Oct 2008 11:33:29 -0700
Received: from ( by ( with Microsoft SMTP Server (TLS) id 8.1.311.2; Tue, 21 Oct 2008 11:33:29 -0700
Received: from ([]) by ([]) with mapi; Tue, 21 Oct 2008 11:33:28 -0700
From: "Narayanan, Vidya" <>
To: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>, Stanislav Shalunov <>
Date: Tue, 21 Oct 2008 11:33:26 -0700
Thread-Topic: [tana] [p2pi] [tsv-area] TANA proposed charter
Thread-Index: AckzpE8VwMHEv0SxSwWTvEiWLooraAAAjXkQ
Message-ID: <>
References: <> <> <> <> <> <4D4C2826-077A-4948-9A92-5EC393DC88AF@ICSI.Berkeley.EDU>
In-Reply-To: <4D4C2826-077A-4948-9A92-5EC393DC88AF@ICSI.Berkeley.EDU>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
MIME-Version: 1.0
Cc: 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-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

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. 

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. 

There is no doubt that this charter is attempting to tackle a very important issue.  But, it would be good to think about what grades we may need to address here.  


> -----Original Message-----
> From: [] On 
> Behalf Of Nicholas Weaver
> Sent: Tuesday, October 21, 2008 10:42 AM
> To: Stanislav Shalunov
> Cc:; Nicholas Weaver;; TSV Area; 
> Bruce Davie; Eddy, Wesley M. (GRC-RCN0)[VZ]
> Subject: Re: [tana] [p2pi] [tsv-area] TANA proposed charter
> 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 MULTIPLE peers.
> 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.
> _______________________________________________
> tana mailing list
p2pi mailing list