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

[Laird Popkin <[e-mail]>]

One technical point about p2p: a tit-for-tat mechanism only applies between downloaders (i.e. peers that have <100% of the data); seeds (i.e. peers with 100% of the data) send data without getting anything in return. This means that while the traffic between downloaders is balanced (so upstream is roughly equal to downstream, which would given asymmetrical consumer bandwidth would typically leave lots of available downlink capacity) it's entirely possible for many seeds to collectively saturate a downloader's downstream capacity. So while I agree that upstream is much more often the concern, we can't ignore downstream entirely.

- Laird Popkin, CTO, Pando Networks
  mobile: [phone]

----- Original Message -----
From: "Rolf Winter" <[e-mail]>
To: "Nicholas Weaver" <[e-mail]>, "Vidya Narayanan" <[e-mail]>
Cc: "TSV Area" <[e-mail]>, [e-mail], [e-mail], "Wesley M. Eddy (GRC-RCN0)[VZ]" <[e-mail]>
Sent: Tuesday, October 21, 2008 8:46:51 PM (GMT-0500) America/New_York
Subject: Re: [tana] [p2pi]   [tsv-area] TANA proposed charter

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 War
 craft 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tana
> 

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