|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: [NANOG] P2P traffic optimization Was: [Nanog] Lies, Damned Lies, and Statistics [Was: Re: ATT VP: Internet to hit capacity by 2010]
Replies below: - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Christopher Morrow" <[email protected]> To: "Laird Popkin" <[email protected]> Cc: "Alexander Harrowell" <[email protected]>, "Doug Pasko" <[email protected]>, [email protected] Sent: Wednesday, April 23, 2008 7:47:57 PM (GMT-0500) America/New_York Subject: Re: P2P traffic optimization Was: [Nanog] Lies, Damned Lies, and Statistics [Was: Re: ATT VP: Internet to hit capacity by 2010] On Wed, Apr 23, 2008 at 6:30 PM, Laird Popkin <[email protected]> wrote: > I would certainly view the two strategies (reverse engineering network information and getting ISP- > provided network information) as being complimentary. As you point out, for any ISP that doesn't > provide network data, we're better off figuring out what we can to be smarter than 'random'. So while I > prefer getting better data from ISP's, that's not holding us back from doing what we can without that > data. ok, sounds better :) or more reasonable, or not immediately doomed to blockage :) 'more realistic' even. - Thanks. Given that there are many thousands of ISP's, an incremental approach seemed best. :-) > ISP's have been very clear that they regard their network maps as being proprietary for many good > reasons. The approach that P4P takes is to have an intermediate server (which we call an iTracker) > that processes the network maps and provides abstracted guidance (lists of IP prefixes and > percentages) to the p2p networks that allows them to figure out which peers are near each other. The > iTracker can be run by the ISP or by a trusted third party, as the ISP prefers. What's to keep the itracker from being the new 'napster megaserver'? I suppose if it just trades map info or lookup (ala dns lookups) and nothing about torrent/share content things are less sensitive from a privacy perspective. and a single point of failure of the network perspective. - That's a good point. The iTracker never knows what's moving in the P2P network. We are comparing two recommendation models, which expose different levels of information. In the 'general' model, the iTracker knows nothing about the p2p network, but provides a recommendation matrix based purely on the ISP's network resources and policies. In the 'per torrent' model, the iTracker receives information about peer distribution (e.g. there are many seeds in NYC, and many downloaders in Chicago), in which case it can make peering recommendations based on that knowledge. The latter approach seems like it should be better able to 'tune' communications (to reduce maximum link utilization, etc.), but it requires the p2p network to provide real-time information about swarm distribution, which involves more communications, and exposes more details of the network to the iTracker, raising some privacy concerns. Admittedly the iTracker doesn't know what the swarm is delivering, but it would know (in network terms) where the users in that swarm are, for example. Latency requirements seem to be interesting for this as well... at least dependent upon the model for sharing of the mapping data. I'd think that a lookup model served the client base better (instead of downloading many large files of maps in order to determine the best peers to use). There's also a sensitivity to the part of the network graph and which perspective to use for the client -> peer locality mapping. - The network data is loaded into the p2p networks's Tracker, and used locally there, so there's no external communications during normal p2p network operation. The communication pattern in P4P (current, at any rate - it's still evolving) is that the P2P network's Tracker polls the P4P iTracker periodically to receive updated map files. In the case of the 'general' weight map, it could be one update every few minutes (or every day, etc., depending on how often the ISP cares to update network information). In the case of 'per torrent' optimization, it's an update per swarm every few minutes, which is much more messaging, so it might only make sense to do this for a very small number of the most popular swarms. It's interesting at least :) Thanks! -Chris (also, as an aside, your mail client seems to be making each paragraph one long unbroken line... which drives at least pine and gmail a bit bonkers...and makes quoting messages a much more manual process than it should be.) - Sorry - I reconfigured to send 'plain text' email. Does it show up OK? I'm using Zimbra's web mail interface. _______________________________________________ NANOG mailing list [email protected] http://mailman.nanog.org/mailman/listinfo/nanog
|