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

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  
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.

_______________________________________________
p2pi mailing list
p2pi@ietf.org
https://www.ietf.org/mailman/listinfo/p2pi