Re: Network end users to pull down 2 gigabytes a day, continuously?

From: Sean Donelan (no email)
Date: Wed Jan 10 2007 - 00:08:40 EST

  • Next message: Fergie: "Re: Network end users to pull down 2 gigabytes a day, continuously?"

    On Tue, 9 Jan 2007, wrote:
    > Multicast streaming may be a big win when you're only streaming the top
    > 5 or 10 networks (for some value of 5 or 10). What's the performance
    > characteristics if you have 300K customers, and at any given time, 10%
    > are watching something from the "long tail" - what's the difference between
    > handling 30K unicast streams, and 30K multicast streams that each have only
    > one or at most 2-3 viewers?

    1/2, 1/3, etc the bandwidth for each additional viewer of the same stream?
    The worst case for a multicast stream is the same as the unicast stream,
    but the unicast stream is always the worst case.

    Multicast doesn't have to be real-time. If you collect interested
    subscribers over a longer time period, e.g. scheduled downloads over the
    next hour, day, week, month, you can aggregate more multicast receivers
    through the same stream. TiVo collects its content using a broadcast
    schedule.

    A "long tail" distribution includes not only the tail, but also the
    head. 30K unicast streams may be the same as 30K multicast streams, but
    30K multicast streams is a lot better than 300,000 unicast streams.
    Although the long tail steams may have 1, 2, 3 receivers of a stream, the
    Parato curve also has 1, 2, 3 streams with 50K, 25K, 12K receivers.

    With Source-Specific Multicast addressing there isn't a shortage of
    multicast addresses for the typical broadcast usage. At least not until
    we also run out of IPv4 unicast addresses.

    There is rarely only one way to solve a problem. There will be multiple
    ways to distribute data, video, voice, etc.


  • Next message: Fergie: "Re: Network end users to pull down 2 gigabytes a day, continuously?"





    Hosted Email Solutions

    Invaluement Anti-Spam DNSBLs



    Powered By FreeBSD   Powered By FreeBSD