RE: multicast (was Re: Readiness for IPV6)
There is also a "cart and horse" issue here: Where is the pervasive content? Most content providers don't want multicast because it breaks their billing model. They can't tell how many viewers they have at a given moment, what the average viewing time is, or any of the other things that unicast allows them to determine and more importantly bill their advertisers for. There is no Nielsen's Ratings for multicast so that advertisers could get a feel for how many eyeballs they are going to hit. Then add in the latest from Congress with regard to streaming audio over the net, and you have a source payment issue making you not want to go down the multicast path. (Leaving Congress living up to their name as being opposite of progress.) Multicast is a great technology. It just is stuck looking for a problem to solve that doesn't create even more problems. David -----Original Message----- From: Leo Bicknell [mailto:bicknell@ufp.org] Sent: Tuesday, July 09, 2002 7:52 AM To: nanog@merit.edu Subject: Re: multicast (was Re: Readiness for IPV6) In a message written on Tue, Jul 09, 2002 at 10:39:35AM -0400, Jared Mauch wrote:
They aren't aware of the savings they can see, consider the savings too small, don't know how to configure, can't configure, break the config, etc.. the list goes on and on.
Speaking from a provider who used to run multicast, and now doesn't: Customers don't want it. I can count our customer requests for multicast on both hands for the last two years. Of those, only one thought it was important, the rest were just playing with it. In fact, pretty much the only place we see it anymore is on RFP's from educational groups. My own view is that customers don't want it, because end users don't have it. Dial up users will probably never get multicast. So that leaves Cable Companies (good luck for them to do something intelligent) or DSL providers (perhaps they might) to make it happen. If a few million end users could just 'get it', then people running streaming services would be beating on backbone providers to carry it around. There is also a payment problem. If a unicast bit enters your network, you can be assured it takes one path to the destination. When a multicast bit enters your network, it could take one path, or it could take 50 paths through your network. The latter does cost the ISP more. This also makes peering an issue, as many people use ratio. If there was a significant amount of multicast traffic, hosting ISP's would send end-user ISP's one small stream that they would then replicate. That would pretty much make the ratio completely opposite of what it is today, due to unicast streaming. I'll be the first to jump on the multicast bandwagon, but I don't work for an eyeball provider. The first adopters need to be DSL and cable modem providers, to the end user, on by default. Then we can go somewhere. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
Most content providers don't want multicast because it breaks their billing model. They can't tell how many viewers they have at a given moment, what the average viewing time is, or any of the other things that unicast allows them to determine and more importantly bill their advertisers for. There is no Nielsen's Ratings for multicast so that advertisers could get a feel for how many eyeballs they are going to hit.
So why cant the data and control plane be separate for content delivery? Use multicast for the data part, but stick with unicast for the control. In other words, end-users will still need to explicitly register/deregister with content providers to receive content. This will allow the content providers to do everything they could do previously with unicast data. except now end-users will receive the content over the multicast tree. Of course the ISPs will also have to somehow separate the data and control plane, so their billing issues with multicast can be addressed... Rajesh.
* rrt@research.telcordia.com (Rajesh Talpade) [Tue 09 Jul 2002, 17:28 CEST]:
So why cant the data and control plane be separate for content delivery? Use multicast for the data part, but stick with unicast for the control.
RealPlayer for one does this, AFAIK. (Otherwise they wouldn't be able to charge those extortuous license fees for the server, of course)
Of course the ISPs will also have to somehow separate the data and control plane, so their billing issues with multicast can be addressed...
It probably costs more to send/receive a multicast packet than a unicast one, but there is a cutoff point at a certain (hopefully small!) number of listeners that will vary from network to network and from stream to stream... "Issues" might not be strong enough a word - which would also help explain why not many networks have it in their product portfolios. Regards, -- Niels.
Thus spake "David Sinn" <dsinn@microsoft.com>
There is also a "cart and horse" issue here: Where is the pervasive content?
No, it's a "chicken and egg" problem :)
Most content providers don't want multicast because it breaks their billing model. They can't tell how many viewers they have at a given moment, what the average viewing time is, or any of the other things that unicast allows them to determine and more importantly bill their advertisers for. There is no Nielsen's Ratings for multicast so that advertisers could get a feel for how many eyeballs they are going to hit.
That assumes there is no signaling. Commercial content will be encrypted and clients will have to get a key (possibly for free). Key distribution can be tracked and billed perfectly. Even for cleartext content, clients should be sending RTCP reports periodically. I think a bigger issue is that multicast is only truly compelling for high-bandwidth applications, and there's just not a critical mass of users with enough bandwidth to justify deployment today. Even worse, multicast is truly only suitable for live applications; on-demand content can't be realistically mcasted, and users will not settle for "the movie starts every 15 minutes" when they've been used to live VOD with unicast. The only saving grace may be things like TiVo, where an intelligent agent slurps up live mcasts in hopes that the user may want to watch it "live" later. S
Even worse, multicast is truly only suitable for live applications; on-demand content can't be realistically mcasted, and users will not settle for "the movie starts every 15 minutes" when they've been used to live VOD with unicast. The only saving grace may be things like TiVo, where an intelligent agent slurps up live mcasts in hopes that the user may want to watch it "live" later.
Really? What about DF-like technologies? Dave
On Tue, Jul 09, 2002 at 11:49:11AM -0500, Stephen Sprunk wrote:
Even worse, multicast is truly only suitable for live applications; on-demand content can't be realistically mcasted, and users will not settle for "the movie starts every 15 minutes"
Just for the sake of argument I'll point out that this is exactly how DirecTV offers PPV movies... each of the 30-odd movies available for viewing in a given month are listed on one or more channels with defined start times. Obviously this may not translate to on-demand movie streaming over the internet, but since DirecTV seems to be at least a little bit successful with this approach you may not want to be so quick to rule it out. Whether people will pay money to watch movies streamed over the Internet (as opposed to traditional media such as cable or satellite) is an entirely different question, of course. --Jeff
Thus spake "Jeff Aitken" <jaitken@aitken.com>
On Tue, Jul 09, 2002 at 11:49:11AM -0500, Stephen Sprunk wrote:
Even worse, multicast is truly only suitable for live applications; on-demand content can't be realistically mcasted, and users will not settle for "the movie starts every 15 minutes"
Just for the sake of argument I'll point out that this is exactly how DirecTV offers PPV movies... each of the 30-odd movies available for viewing in a given month are listed on one or more channels with defined start times.
Yes, that's the PPV model. AT&T Broadband calls it "InDemand" since it's probably fraud to call it "on demand". Most hotels have VOD now, and that tells me consumer acceptance is better for VOD but the technology just doesn't scale yet.
Obviously this may not translate to on-demand movie streaming over the internet, but since DirecTV seems to be at least a little bit successful with this approach you may not want to be so quick to rule it out.
They're certainly successful with big events like the Tyson/Lewis fight, but how much money does a PPV movie really bring in? Obviously they wouldn't do it if it were a total loser, but the cost to carry is near zero and $4.95/viewing is a huge disadvantage vs. rentals.
Whether people will pay money to watch movies streamed over the Internet (as opposed to traditional media such as cable or satellite) is an entirely different question, of course.
The question, of course, is whether the cost people are willing to pay will cover the cost of providing the service. Today, it's nowhere close. S
on 7/9/2002 11:49 AM Stephen Sprunk wrote:
I think a bigger issue is that multicast is only truly compelling for high-bandwidth applications, and there's just not a critical mass of users with enough bandwidth to justify deployment today.
Multimedia is the common example but I actually find multicast more useful for common administrative services like NTP. I've also done some simple research into multicast DHCP (goodbye mandatory unicast proxies) and DNS (goodbye mandatory unicast proxies) which has looked promising for the small investigative work done. In this regard, multicasting the small chatter stuff is actually much more compelling, although these examples all apply to a local administrative scope and not to multicasting across the Internet in general. The issue with the latter is that there is no killer app which requires it. As a result, ISPs don't offer it, firewalls/NATs don't support it, and so forth. I've never had a network connection which supported it. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
On Tue, 9 Jul 2002, Stephen Sprunk wrote:
Even worse, multicast is truly only suitable for live applications; on-demand content can't be realistically mcasted, and users will not settle for "the movie starts every 15 minutes" when they've been used to live VOD with unicast. The only saving grace may be things like TiVo, where an intelligent agent slurps up live mcasts in hopes that the user may want to watch it "live" later.
I remember seeing a presentation about 3-4 years ago for techniques for doing on-demand stream sending. They assume multicast, sufficient buffer capacity on clients to hold the entire stream, and that clients have enough bandwidth to recieve, say, 1.2-3.5 streams at once. There are many techniques, but the basic idea is to 'merge' streams together... Say, for example, you have two multicast streams *.1 and *.2 *.1 is free and unused. *.2 is 2 minutes into a movie. A client makes a request at T=0, and subscribes to *.1 and *.2. *.1 sends the first 2 minutes of the movie then closes. The clients buffers *.2 during those 2 minutes to get minutes 2-4 of the movie. The client drops *.1 which is now free. Now, at T=2, the client is listening on *.2 giving it minutes 4-120 of the movie, and minutes 2-4 are buffered on its hard drive. Now, stream *.1 is free, and two clients are on stream *.2. Thats the idea, and it can be scaled up.. I think the presentation I saw claimed that where clients listen to at most 2 streams, and servers send out at most 8 streams, then the delay before starting a 2 hour movie can be <12 seconds, instead of <15 minutes. Some googling finds: http://www.cs.washington.edu/homes/zahorjan/homepage/ Which can be read or mined for references. Scott
an example of a on-demand reliable multicast transport application that you can deploy is: http://www.digital-fountain.com/technology/index.htm in part it employs them mechanism you describe. joelja On Wed, 10 Jul 2002, Scott A Crosby wrote:
On Tue, 9 Jul 2002, Stephen Sprunk wrote:
Even worse, multicast is truly only suitable for live applications; on-demand content can't be realistically mcasted, and users will not settle for "the movie starts every 15 minutes" when they've been used to live VOD with unicast. The only saving grace may be things like TiVo, where an intelligent agent slurps up live mcasts in hopes that the user may want to watch it "live" later.
I remember seeing a presentation about 3-4 years ago for techniques for doing on-demand stream sending. They assume multicast, sufficient buffer capacity on clients to hold the entire stream, and that clients have enough bandwidth to recieve, say, 1.2-3.5 streams at once. There are many techniques, but the basic idea is to 'merge' streams together...
Say, for example, you have two multicast streams *.1 and *.2 *.1 is free and unused. *.2 is 2 minutes into a movie.
A client makes a request at T=0, and subscribes to *.1 and *.2. *.1 sends the first 2 minutes of the movie then closes. The clients buffers *.2 during those 2 minutes to get minutes 2-4 of the movie. The client drops *.1 which is now free. Now, at T=2, the client is listening on *.2 giving it minutes 4-120 of the movie, and minutes 2-4 are buffered on its hard drive. Now, stream *.1 is free, and two clients are on stream *.2.
Thats the idea, and it can be scaled up.. I think the presentation I saw claimed that where clients listen to at most 2 streams, and servers send out at most 8 streams, then the delay before starting a 2 hour movie can be <12 seconds, instead of <15 minutes.
Some googling finds: http://www.cs.washington.edu/homes/zahorjan/homepage/
Which can be read or mined for references.
Scott
-- -------------------------------------------------------------------------- Joel Jaeggli Academic User Services joelja@darkwing.uoregon.edu -- PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E -- In Dr. Johnson's famous dictionary patriotism is defined as the last resort of the scoundrel. With all due respect to an enlightened but inferior lexicographer I beg to submit that it is the first. -- Ambrose Bierce, "The Devil's Dictionary"
There is also a "cart and horse" issue here: Where is the pervasive content?
Most content providers don't want multicast because it breaks their billing model. They can't tell how many viewers they have at a given moment, what the average viewing time is, or any of the other things that unicast allows them to determine and more importantly bill their advertisers for. There is no Nielsen's Ratings for multicast so that advertisers could get a feel for how many eyeballs they are going to hit.
I worked for a startup in 1999 that was doing just that. Neilsen's for multicast. It was cool while I was there, but it quickly became clear that the product was ahead of it's time. They now do event streaming and I think they support unicast and multicast. Without a network that supports it, multicast apps are useless. jas
participants (10)
-
David Meyer -
David Sinn -
Eric A. Hall -
Jason Lewis -
Jeff Aitken -
Joel Jaeggli -
Niels Bakker -
Rajesh Talpade -
Scott A Crosby -
Stephen Sprunk