On May 4, 2011, at 3:37 48PM, Jeff Wheeler wrote:
On Wed, May 4, 2011 at 2:22 PM, Scott Helms <khelms@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