In message <5.2.0.9.0.20030627160856.02023200(a)pele.citylink.co.nz>, Richard Nayl or writes:
At 03:54 p.m. 27/06/2003 +1200, Ewen McNeill wrote:
In message <5.2.0.9.0.20030627141054.038683c0(a)pele.citylink.co.nz>, Richard Naylor writes:
[Multicast] Well the biggest part of the business is video on demand and that can really only be unicast as getting viewers to agree on what they watch is like agreeing on a TV Channel in a huge flat - hopeless.
[... "on demand" doesn't necessarily mean "instantly" ...] Which means that for popular stuff that is "on demand" it might not be enough to have one channel with it, where the wait time is, say, 15 minutes for it to cycle around -- but it might be fine to have 10-20 channels, suitably staggered, where the wait time was 1-2 minutes.
ah - its that word "channel" that I don't see in the future. Such a dated concept.
Ah. Channels are double-plus-ungood. Call it a stream if it makes you feel happier. Or VDC or whatever.
Instead, you're interested in Alastair Cook. Why should you wait til Monday at 8:45 every week and then miss it because you were on the phone.
I don't recall suggesting that you should.
Hey you have 10 minutes now and would like to catch up with what he said last Monday (when you were on the phone, remember). So why can't you click in now and view it ?
Your argument seems to be "viewers must be able to view it __NOW__(tm)" and hence we must use unicast for everything in order that everyone can have their whim satisifed at an instants notice (and provide all the bandwidth from source to (multiple) sink(s) to make this possible). My argument is that there's a fair chunk of evidence that says that people would be willing to wait 1, 2, 5, 10, 30, or even 60 seconds for something to start (maybe even longer if it's a sizeable time investment to watch it all and the waiting time can be used productively -- eg, getting that beer out of the fridge before settling down to watch the game), especially given a proper cost/benefit tradeoff ("would you pay 5 times as much to be able to have it start within half a second instead of within 5 seconds"?). And that by adding that relaxing condition it's both quite feasible, and quite benefical, to use multicast at least for the more popular things, especially where the multicast VDCs is set up "on demand" with just a short "setup time" to pull in other potential viewers. Think of it as the difference between everyone just crossing the road when they feel like it, and traffic lights (or at very least waiting for the same gap in the traffic). The big reason that it's beneficial in the popular-to-(re)view situation is that there're more people wanting to view something than there are 5-second, 10-second, 30-second, 60-second, whatever start periods. So you can achieve an N:M reduction in the number of VDC you need originating from the source, for only the price of a bit of management infrastructure (request-a-start-soon), and a slightly slip from the "I wanna watch it now! Now! Now! Mommy, make it go!" instant satisfaction.
Multicast is great for synchronous events like TRADITIONAL tv. I just don't see that continuing.
It's good for things other than traditional TV too. Especially where there's (significantly) more than one person wanting to watch something at the "same" time. Which is a surprisingly common case for "current" events. (Speech replays, sports replays, recent movie releases, etc.) Oh, and I quite agree with Joe's comment that caching at the edge can achieve quite remarkable things in turning "watch now or miss it" into "watch when you feel like it". (And even better, if those with suitable broadcast channels would actually get a clue and use the "down" time to spool out things people might want to watch during the week (eg, "this week's hot new movies"). But "video recorders are bad, we must do everything to defeat the use of video recorders". Furrfu.) Ewen