The 100 Gbit/s problem in your network

Mon Feb 11 23:52:58 UTC 2013

On Feb 11, 2013, at 14:11 , Stephen Sprunk <stephen at sprunk.org> wrote:
> 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.

One of us has a different dictionary than everyone else.

Assume I have 10 million movies in my library, and 10 million active users.  Further assume there are 10 movies being watched by 100K users each, and 9,999,990 movies which are being watched by 1 user each.

Which has more total demand, the 10 popular movies or the long tail?

This doesn't mean Netflix or Hulu or iTunes or whatever has the aforementioned demand curve.  But it does mean my "definition" & yours do not match.

Either way, I challenge you to prove the long tail on one of the serious streaming services is a "tiny fraction" of total demand.

-- 
TTFN,
patrick