Re: [nznog] Multicast status in New Zealand
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
I have taken all my notes I had when setting up multicast connections @ APE ages ago and put on http://www.mbone.net.nz A small howto on Multicast in NZ. (At APE at least at the moment). Its very incomplete and may not give you multicast and even crash your router but its a small start for some people. With this setup (or something like it) I could see some multicast stuff ages ago. If you have any additions/notes/things to add/remove please let me know. Thanks Craig
The benefit of multicast is primarily in the combination of richnes and reach (marketing terms) in a limited bandwidth network, Richness is about the quality of the material as percevied by the recipient. Reach is is how broad you can spread that material. Multicast allows flows of highly rich material to be received by those wanting it (unlimited reach, assuming everyone has internet access), while minimising network overhead. If bandwidth is somewhat unlimited (and it bloody well should be!) we do not need multicast. I think we should press for providers to turn it on, especially since they are the ones choking the pipes. Craig Whitmore wrote:
I have taken all my notes I had when setting up multicast connections @ APE ages ago and put on http://www.mbone.net.nz A small howto on Multicast in NZ. (At APE at least at the moment). Its very incomplete and may not give you multicast and even crash your router but its a small start for some people. With this setup (or something like it) I could see some multicast stuff ages ago.
If you have any additions/notes/things to add/remove please let me know.
Thanks Craig
_______________________________________________ Nznog mailing list Nznog(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
-- Peter Macaulay Executive Director InternetNZ Direct +64 4 495 2113
On Sat, Jun 28, 2003 at 11:53:50PM +1200, Craig Whitmore wrote:
A small howto on Multicast in NZ. (At APE at least at the moment).
So, just how "dead" _is_ the mbone, anyway? How does NZ's multicast (in)capabilies compare with other developed nations (including the likes of South Korea and Vietnam) And while on the topic of global virtual networks, I take it the 6bone is still alive and kicking?
If you have any additions/notes/things to add/remove please let me know.
You might like to throw in the link to the "IPv6 Multicast Best Current Practice" draft RFC (June 2003 - December 2003) http://www.ietf.org/internet-drafts/draft-ietf-mboned-ipv4-mcast-bcp-01.txt This document doesn't mention anything about PIM-2 though, just PIM Sparse Mode, MSDP, and MBGP. It also doesn't mention anything about address allocation (MALLOC) It also mentions nothing about accounting and billing methodologies, nor DNS issues (if any). BTW. I looked up about Project PROBE the other day, and some information from the Ministry of Education wrt ICT. I found no mention whatsoever about multicast (and they were talking about video conferencing a lot). Mind you, there was no technical information I could find about PROBE, except to find that Halfmoon Bay in Stewart Island can get Jetstream now. -- Cameron Kerr cameron.kerr(a)paradise.net.nz : http://nzgeeks.org/cameron/ Empowered by Perl!
On Sunday 29 June 2003, at 08:11, Cameron Kerr wrote:
And while on the topic of global virtual networks, I take it the 6bone is still alive and kicking?
The 6bone was declared dead at the v6ops meeting at the recent IETF meeting in San Francisco, I believe (I wasn't actually in that meeting). Apparently production, non-pTLA-numbered v6 networks are now common enough that prolonging the use of 3ffe:: is no longer considered important. Last time I asked there weren't any ISPs on the APE or the WIX who were ready/interested in doing native v6 peering. Joe
The 6bone was declared dead at the v6ops meeting at the recent IETF meeting in San Francisco, I believe (I wasn't actually in that meeting). Apparently production, non-pTLA-numbered v6 networks are now common enough that prolonging the use of 3ffe:: is no longer considered important.
basically there was agreement (hmmmmm) that there would be no more pTLAs allocated past January 1, 2004 (i honestly thought they chose April 4, 2004 for that date but this is beside the point) and for all of 3ffe:: space to be reclaimed at June 6, 2006 - at which point the 6bone would well and truly be dead. i've seen requests for 3ffe:: space granted on the 6bone mailing list since the San Francisco IETF http://www.ietf.org/internet-drafts/draft-fink-6bone-phaseout-04.txt http://www.6bone.net/ngtrans/IETF-56-SanFrancisco/6bone-phaseout.pdf
Hi Joe:
Last time I asked there weren't any ISPs on the APE or the WIX who were ready/interested in doing native v6 peering.
NGI-NZ has a strong interest in promoting native IPv6. Once the NGI network network is up and running, i.e. providing reliable IPv4 connectivity, we'll be looking to do the same for IPv6. BTW, last year's report on NGI proposed a startup date well before the end of 2003, and all those involved in the NGI discussions have been working hard to make that happen. Cheers, Nevil (wearing NGI-NZ Technical WG chair hat) ----------------------------------------------------------------------- Nevil Brownlee Director, Technology Development Phone: +64 9 373 7599 x88941 ITSS, The University of Auckland FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand ------------------------------------------------- This mail sent through University of Auckland http://www.auckland.ac.nz/
On Sat, Jun 28, 2003 at 13:05 +1200, Ewen McNeill wrote:
In message <5.2.0.9.0.20030627160856.02023200(a)pele.citylink.co.nz>, Richard Naylor writes:
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.
I think Rich's point is broader than "channels," it goes to the notion of "broadcast," which, while like most things is not going to go away anytime soon, but the option of obtaining material from P2P or other sources (Tivo as so aptly observed by Joe) and assembling your own experience is becoming more feasible, NB. those "mix CDs" that upset the same distribution monopolies who take exception to video recorders. As per usual there will be those (including me) who wish to be spoon-fed the mass-market LCD, and good for them, what appears to be disliked by a percentage of any audience/market is the lack of any choice. Its no longer held that the centre/operator knows best for us all. This is what makes me leery of attempts to make the Internet a better broadcast medium than it already isn't. It may make non-broadcast use more difficult. Unintended consequences, increased core complexity, et al.
Your argument seems to be "viewers must be able to view it __NOW__(tm)"
I don't recall Rich writing anything quite so exclusionary, I read it as saying this could be a better, non-exclusive, option. Assuming you mean MUST in the RFC 2119 sense of the word.
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
Most of the WWW supports that conclusion, LOL.
(maybe even longer if it's a sizeable time investment to watch it all and the waiting time can be used productively
Yes, like video rental already provides, without the drive there and back, and PPV on Sky Digital. No, new things are almost always about adding options, not about removing them. Though that said, some options become so niche that they vanish.
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).
I think its more about about buses on a scheduled route rather than everyone owning a car going where and when they want, but your analogising may vary. In my analogy, people rather prefer the private vehicle (and bus over train (10 to 1) in Wellington). They can possibly afford this preference as the vehicle/road (as opposed to the packet/bearer) network has matured to the point where operators don't make any money at all (excepting London of course <grin>), though they are trying to get into that mode via the pernicious "Public/Private Partnership" and "congestion charging."
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.)
I think those are "synchronous events" or what in TV is called "live" and there certainly is interest.
But "video recorders are bad, we must do everything to defeat the use of video recorders". Furrfu.)
The Boston Strangler of the TV Industry huh? (I didn't know so I'll explain, "furrfu" is rot13 "sheesh"). Service implementation on the edge is double-plus-good. That can happen without this discussion or the attendant attempts at co-ordination and convincing the operators they can make money this way. Customer owned/created services generally serve the customer best.
Ewen
Hamish. PS. Road congestion, like unicast broadcast congestion, seems to arise from the continued belief that we all have to use the road at the same times (morning and night, Monday-Friday) in the same way we all have to watch/hear the news as it is broadcast or rolls off the presses. It doesn't really have to be that homogeneous any more, and putting a cost on that, might drive recognition of this fact. We appear to have noticed you don't need to own the rails to run services over them... -- You will soon break the bow if you keep it always stretched. -- Phaedrus
participants (8)
-
Cameron Kerr -
Craig Whitmore -
Ewen McNeill -
Hamish MacEwan -
Joe Abley -
Matthew Luckie -
Nevil Brownlee -
Peter Macaulay