I'm wondering how much content is used TiVo style, not in real time, but fairly soon thereafter. It might make sense to multicast feeds to local caches so when people actually want stuff, it doesn't come all the way across the net.
I think the good folks at Akamai may have already thought of this. :-)
Akamai has built a Content Delivery Network (CDN) because they do not have to rely on any specific ISP or any specific IP network functionality. If you go with IP Multicast, or MPLS P2MP(Point to MultiPoint) then you are limited to only using ISPs who have implemented the right protocols and who peer using those protocols. P2P is a lot like CDN because it does not rely on any specific ISP implementation, but as a result of being 100% free of the ISP, P2P also lacks the knowledge of the network topology that it needs to be efficient. Of course, a content provider could leverage P2P by predelivering its content to strategically located sites in the network, just like they do with a CDN. IP multicast and P2MP have routing protocols which tell them where to send content. CDN's are either set up manually or use their own proprietary methods to figure out where to send content. P2P currently doesn't care about topology because it views the net as an amorphous cloud. NNTP, the historical firehose protocol, just floods it out to everyone who hasn't seen it yet but actually, the consumers of an NNTP feed have been set up statically in advance. And this static setup does include knowledge of ISP's network topology, and knowledge of the ISP's economic realities. I'd like to see a P2P protocol that sets up paths dynamically, but allows for inputs as varied as those old NNTP setups. There was also a time when LAN's had some form of economic reality configured in, i.e. some users were only allowed to log into the LAN during certain time periods on certain days. Is there any ISP that wouldn't want some way to signal P2P clients how to use spare bandwidth without ruining the network for other paying customers? --Michael Dillon _______________________________________________ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog