> The usual scenario is that the edge always has the most=20 > bandwidth. Its your areas north of=20 > the edge that can be bandwidth challenged. Thanks for the reply. Well, maybe my use of "edge" and p2p was not clear. I was thinking on residential areas with a few hundreds of viewers which would connect to other similar areas, forming p2p nets themselves, at the infrastructure level - ie. not following the typical (I assume) backbone/branches tree-like structure.=20 Application level p2p would/could then give priority to peers in the neighbourhood therefore avoiding a huge load on backbones. I consider this to be true for real video-on-demand or personalized channels where there is at least some small overlap between user's demands.=20 If we consider the two extremes:=20 a) each person sees its _own_content_ at its _own_time_ b) everybody sees the _same_thing_ at the _same_time_ Both multicast and p2p will fail at pure a). (still better than unicast for the reasons you, Kon, explained so well in a recent email). It seems to me p2p will behave better near a), and relatively less so near b). On the contrary, multicast may be better near b) and, relatively less useful near a). In terms of time, while p2p behave better when viewers view content at different times from other viewers getting the same content, multicast will only be effective if a reasonable number of people are willing to get their content at the same time. (also, forgive me if I appear to put multicast on the same OSI layer as p2p - I'm not - it just looks that way ;) )=20 =20 > > In a p2p solution, like for example IBM P2G Media Broadcast > > (www.alphaworks.ibm.com/tech/p2g), the more users want a piece of > > content (or channel?), the more capacity will be available for it - > > although, near online with a delay. >=20 > It doesn't appear to offer any advantage when the peers and=20 > edge server are all at the edge.=20 But consider you have inexpensive standard routers near homes routing between nodes and residential areas directly, and content servers one or two hierarchy levels above. The nodes themselves become the content servers! That's p2p saving a lot of money to providers... > I've seen one such box that does exactly this, but its=20 > problem was that it exposed the notion=20 > of 'downloading' and 'queues' to the user. Other than that,=20 > yes and no. Do you still remember which box you are referring to? Thanks. > Content providers=20 > prefer walled gardens, and so do CA companies. Also, RSS=20 > isn't designed for carrying 'real'=20 > broadcast data (how do you carry keys in an RSS feed) or=20 > handling billing (how do you figure=20 > out how/where/when to bill someone if the feeds are from=20 > diverse sources, and how do you=20 > securely automate this process). Its a nice first try though,=20 > but the modern equivalent of a=20 > wooden coach wheel.=20 In terms of being doable, you will have to agree it is. In terms of doing it, I currently have a student doing a final year project precisely on that (personalized RSSs on secure, authenticated channels for a "broadcatching" scenario). Let's see how it goes. > Freenet is an anonimity service - so you can pirate movies=20 > without fear of being traced. What=20 > does that have to do with DRM? :-) Freenet does offer anonymity. But it also offers encryption.=20 Both are useful if instead of getting all your content from a straight line from your ISP/content provider, you get it through other peers. Anonymity would be needed for doing this in a ethically acceptable way (privacy wise). Encryption would be need to preserve the value chain - that's the relation with DRM... an enabling technology. > I believe if these technologies that are out there in their=20 > infancy now continue to be=20 > promoted for illegal downloading (the Engadget article is=20 > priceless - screenshots of Battlestar=20 > galactica divx'd episodes, clearly illegal), then the motion=20 > picture industry will continue to=20 > push away from them, no matter what advantages they hold. True. But we all know it was porn that drove e-commerce forward, it was kazaa/napster/others that originated iTune like markets, and I believe the pressure for IPTV, with or without the hype, will also come from p2p users sharing the content they choose and slowly moving towards paying for it.=20 We still have the opportunity to skip a generalised illegal phase - will the industry react soon enough?=20 Best regards, Silvio (and let's be honest, this illegal wave is already responsible for hardware DivX players, improvement of codecs, xvid, etc) > Cheers > Kon ---------------------------------------------------------------------- You can UNSUBSCRIBE from the OpenDTV list in two ways: - Using the UNSUBSCRIBE command in your user configuration settings at FreeLists.org - By sending a message to: opendtv-request@xxxxxxxxxxxxx with the word unsubscribe in the subject line.