On 11-Feb-13 12:25, Mark Radabaugh wrote:
On 2/11/13 9:32 AM, ML wrote:
Any eyeball network that wants to support multicast should peer with the content players(s) that support it. Simple!
Just another reason to make the transit only networks even more irrelevant.
The big issue is that the customers don't want to watch simulcast content. The odds of having two customers in a reasonably sized multicast domain watching the same netflix movie at exactly the same time frame in the movie is slim. Customers want to watch on time frames of their own choosing. I don't see multicast helping at all in dealing with the situation.
Multicast _is_ useful for filling the millions of DVRs out there with broadcast programs and for live events (eg. sports). A smart VOD system would have my DVR download the entire program from a local cache--and then play it locally as with anything else I watch. Those caches could be populated by multicast as well, at least for popular content. The long tail would still require some level of unicast distribution, but that is _by definition_ a tiny fraction of total demand. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking