How do you put a TV station on the Mbone?

Jeff Wheeler jsw at
Wed May 4 19:37:48 UTC 2011

On Wed, May 4, 2011 at 2:22 PM, Scott Helms <khelms at> 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.

Jeff S Wheeler <jsw at>
Sr Network Operator  /  Innovative Network Concepts

More information about the NANOG mailing list