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
smime.p7s
Description: S/MIME Cryptographic Signature