On Fri, Jan 10, 2014 at 7:30 AM, Craig Birkmaier <craig@xxxxxxxxxxxxx>wrote: > > On Jan 9, 2014, at 7:52 PM, "Manfredi, Albert E" < > albert.e.manfredi@xxxxxxxxxx> wrote: > > Why would they need any servers. To replicate their existing business > model, all they need is one IP Multicast stream per market (or several if > they are multicasting today). Why would the networks let the local > broadcasters stream the network feeds AND Offer this content as VOD streams? > Given the fact that every group of subs may have a unique routing path, you still have to troubleshoot issues with latency. Bandwidth is no longer the issue, but good luck troubleshooting all those hops and fixing latency issues out of your control. The only option would be to put edge servers in local pops with guaranteed bandwidth, push streams to them possibly over some sort of fixed path/tunnel, and make that available via IP multicast. Current CDNs aren't built for this model. They are most if not all based on TCP/HTTP pull. Plus there is the problem that CDNs share traffic and use infrastructure you don't control. The only way to be profitable is to over-provision the network. You have no guarantee that a edge node will be able to fulfill your content delivery requirements (bandwidth/cpu/storage) if some other customers have a huge traffic spike. The larger CDNs just have more boxes in the field. But hardware ages quickly these days, so even that becomes an issue with failure rates and cost of maintenance. And last if you use a CDN you don't get to determine the path traffic flows through it, so you have to design and tweak your system around this black box router that may have dozens of exceptions to every rule that are out of your control. For the type of delivery we are talking about, only way to do it is to build the CDN yourself. Cheers Kon