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

"Rolf Winter" <Rolf.Winter@nw.neclab.eu> Wed, 22 October 2008 00:46 UTC

Return-Path: <p2pi-bounces@ietf.org>
X-Original-To: p2pi-archive@ietf.org
Delivered-To: ietfarch-p2pi-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEC713A68A4; Tue, 21 Oct 2008 17:46:12 -0700 (PDT)
X-Original-To: p2pi@core3.amsl.com
Delivered-To: p2pi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 731A23A67ED; Tue, 21 Oct 2008 17:46:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 S6jJTMox65zl; Tue, 21 Oct 2008 17:46:10 -0700 (PDT)
Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 3877A3A63EC; Tue, 21 Oct 2008 17:46:10 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 429842C0012C2; Wed, 22 Oct 2008 02:47:23 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office)
Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l0Shd+S39+uU; Wed, 22 Oct 2008 02:47:23 +0200 (CEST)
Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id 0CB832C000359; Wed, 22 Oct 2008 02:46:53 +0200 (CEST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 22 Oct 2008 02:46:51 +0200
Message-ID: <547F018265F92642B577B986577D671C3E031F@VENUS.office>
In-Reply-To: <086D03E5-61BE-43F5-A750-3539AF47F13E@ICSI.Berkeley.EDU>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [tana] [p2pi] [tsv-area] TANA proposed charter
Thread-Index: AckzrfkB1yfPeIbSR3OG8ws+cQsjEQALls2w
References: <AE465507-305C-41A4-BE95-311BB628064B@shlang.com><B5A5E01F9387F4409E67604C0257C71E660E5F@NDJSEVS25A.ndc.nasa.gov><36BFC323-FDD5-42DD-9A17-F32DDE7DDF5E@cisco.com><9F472A6A-F3F3-4616-9ACE-4BD24D77FBCD@icsi.berkeley.edu><19AE9AF4-E857-41EF-BF3E-B831F4EB8159@shlang.com><4D4C2826-077A-4948-9A92-5EC393DC88AF@ICSI.Berkeley.EDU><BE82361A0E26874DBC2ED1BA244866B9284E7711@NALASEXMB08.na.qualcomm.com> <086D03E5-61BE-43F5-A750-3539AF47F13E@ICSI.Berkeley.EDU>
From: Rolf Winter <Rolf.Winter@nw.neclab.eu>
To: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>, "Narayanan, Vidya" <vidyan@qualcomm.com>
Cc: TSV Area <tsv-area@ietf.org>, tana@ietf.org, p2pi@ietf.org, "Eddy, Wesley M. (GRC-RCN0)[VZ]" <Wesley.M.Eddy@nasa.gov>
Subject: Re: [p2pi] [tana] [tsv-area] TANA proposed charter
X-BeenThere: p2pi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: P2P Infrastructure Discussion <p2pi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/p2pi>, <mailto:p2pi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/p2pi>
List-Post: <mailto:p2pi@ietf.org>
List-Help: <mailto:p2pi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/p2pi>, <mailto:p2pi-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: p2pi-bounces@ietf.org
Errors-To: p2pi-bounces@ietf.org

Very well scoped charter and I think the discussion so far has shown that besides clarifications and a need for a better name the charter is right on target. I am all for TANA or whatever its name is going to be.

I think what is very important to remember in these discussions is that we talk about content that is served from the edge of the network, i.e. your typical P2P application. Access network asymetry in terms of upstream and downstream (e.g. DSL) is e.g. an important factor. P2P apps have been shown to fill up the upstream very efficiently. Tit-for-tat in BitTorrent will (to some degree) make sure the downstream will not significantly exceed the upstream bandwidth (Stansilav correct me if I am wrong). So the upstream is usually the thing we need to worry about in those settings as it is the limiting factor. Downloading something from YouTube is therefore very different in nature although it qualifies as bulk traffic. Overall I think "file-like" content distribution is the main application field as application developers probably do not want to bet their application's functioning on the access link characteristics of their customers if delay is an issue e.g. Even the earlier Warcraft example is still "file-like". We do not need to explicitly write this down but trying to achieve more complex things to make all sorts of potential applications "happy" would probably too ambitous.

	Rolf

> 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 about.
> 
> 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.
> 
> _______________________________________________
> tana mailing list
> tana@ietf.org
> https://www.ietf.org/mailman/listinfo/tana
> 

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 
_______________________________________________
p2pi mailing list
p2pi@ietf.org
https://www.ietf.org/mailman/listinfo/p2pi