How do you put a TV station on the Mbone?

Steven Bellovin smb at cs.columbia.edu
Wed May 4 19:46:25 UTC 2011


On May 4, 2011, at 3:37 48PM, Jeff Wheeler wrote:

> On Wed, May 4, 2011 at 2:22 PM, Scott Helms <khelms at ispalliance.net> wrote:
>> Local caching is MUCH more efficient than having the same traffic running in
>> streams and depending on everyone's PC to try and update in the same time
> 
> This only works, of course, if there is a local cache which PCs are aware of.
> 
>> Same issue as above, even if I am watching the latest popular movie moving
>> between a multicast and unicast stream everytime I pause it to get another
>> beer isn't realistic.  The chances that there will be a multicast stream
>> that will be in synch with me is not high at all.
> 
> You must have skipped over the word "cache" when reading my post.
> I'll explain again in a little more detail, so you can understand why
> the consumer who pauses the film to go get a snack is actually an
> advantage for this system.
> 
> Let's say your typical movie is 5Mb/s and you want to start watching
> it right away; you aren't willing to wait several minutes (or longer)
> until the next "multicast loop" begins.  You press play and begin
> receiving a 5Mb/s unicast stream, but your STB also joins an mcast
> group for that movie, because it is very popular and being watched by
> a huge number of users during peak time.  The mcast stream is 20Mb/s,
> or 400% of real-time.  No matter what point the loop is at when you
> join, you will cache the multicast data and eventually reach a point
> in the movie where you no longer need the unicast stream.
> 
> Given a 2 hour movie, the worst-case is that you'll join just a minute
> after the stream/loop started, in which case it will be about 30
> minutes before you start viewing from multi-casted, STB-cached data,
> instead of unicast streamed data.  With two subscribers watching the
> movie given worst-case circumstances, there is a bandwidth
> conservation of: (users - 1) * 5Mb/s * 90min, or a mean savings around
> 37%, for only two users.  If ten users are watching, your worst-case
> bandwidth savings will be greater, 33.7Mb/s, or about 67%.
> 
> If, on the other hand, you start watching the movie, then realize it
> would be more enjoyable with some popcorn, your STB is already
> listening to the mcast stream and caching the movie for you.  The
> longer it takes your popcorn to cook, the greater the chance that the
> STB will start receiving mcast data for the beginning of the movie
> before you un-pause it, which means you would not need the unicast
> stream at all.
> 
> In fact, if you include the probability that some users will be able
> to receive data via mcast earlier than 30 minutes into the movie,
> because they didn't get unlucky and press play at the worst-case
> moment, your bandwidth savings for a group of ten viewers and a 400%
> real-time mcast stream will be about 80%.
> 
> The potential savings is limited by the over-speed of the mcast stream
> vs real-time, and the density of mcast listener groups.  Given that
> access network speeds continue to increase, yet ISPs are really not
> increasing "bandwidth caps," it is reasonable to assume that an ISP
> might like to allow its subscribers to receive a very fast mcast
> stream for a short period of time, instead of all of those subscribers
> receiving many, slow mcast streams.
> 
A crucial point here is the cost ratio between bandwidth and disk space,
since ultimately consumers pay for both.  My own STB can cache the
movie -- but that requires local disk.  On the other hand, as you point
out, it saves on bandwidth.  (Note that I'm interpreting "cost" broadly
to include not just the capital cost of, say, the disk, but all of the
associated operational costs, including what ISPs need to spend on
provisioning and operating multicast, consumer reactions to local disks
being full or dying, etc.

Of course, I don't know what the answer is now, let alone over time...


		--Steve Bellovin, https://www.cs.columbia.edu/~smb









More information about the NANOG mailing list