Re: multicast (was Re: Readiness for IPV6)
--On Tuesday, July 09, 2002 10:16:38 -0700 David Meyer [EMAIL PROTECTED] wrote: Given the amount of time and resource we've spent on multicast, the question one might ask is why hasn't multicast succeeded? My guess is that it is because the demand from any of the potential users of the service just isn't there (not at internet ...and perhaps also because there is enough bandwidth currently, and that adding bandwidth is easier/cheaper/more stable/more well known than enabling multicast? Just a guess. - kurtis -
Re: multicast (was Re: Readiness for IPV6)
At 10:51 AM 7/9/2002 -0400, Leo Bicknell wrote: 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. Yahoo/Broadcast.com pushed this pretty heavily. MS's own media player supports multicast, so there definitely a *lot* of clients out there. http://broadcast.yahoo.com/home.html There are a list of providers supporting multicast in conjunction with Yahoo/Broadcast.com found at: http://www.broadcast.com/mcisp/ I see quite a few cable and dialup providers on there ( and I work for one of 'em... ) To find out if you are viewing via unicast/multicast in Windows Media Player, the option is View-Statistics, then in the Network section... -Chris -- \\\|||/// \ StarNet Inc. \ Chris Parker \ ~ ~ / \ WX *is* Wireless!\ Director, Engineering | |\ http://www.starnetwx.net \ (847) 963-0116 oOo---(_)---oOo--\-- \ Wholesale Internet Services - http://www.megapop.net
Re: multicast (was Re: Readiness for IPV6)
On Tue, Jul 09, 2002 at 11:16:56AM -0400, Leo Bicknell wrote: It's a cute list. Where's ATT (with all the old Home customers)? Where AOL? Don't see UUNet either. UUNET supports multicast, although the quality of that experience for me wasn't very good. Last I heard its one price to receive multicast and additional to generate multicast through them. John
Re: multicast (was Re: Readiness for IPV6)
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.
Re: multicast (was Re: Readiness for IPV6)
Hi, There is also a cart and horse issue here: Where is the pervasive content? At the risk of sounding somewhat cynical, I suspect the market driver for IP multicast will be what it often is for these sort of things: pr0n. My prediction? When one of the big adult hosting speciality companies starts IP multicasting free full length cable cut R-rated adult films in watchable MPEG1 quality, people will begin lobbying their ISP's for IP multicast support. Evidence supporting this assertion can be found in the popularity of events such as the Victoria Secret webcast, which reportedly drew more than a million viewers worldwide, even when streaming video was being done at postage-stamp-sized resolution. Of course, at the same time the pr0n channels get rolled out, there will also need to be something innocuous, like the Field Hockey Channel or the Brand-New-Bands-Live!-From-Small-Clubs Channel so that people will be able to use those less-embarassing content choices as their nominal interest when calling to request IP multicast support: Um, hi, my friends who connect via ISP Foo up the street tell me that if you do something to your network I can get the, uh, Field Hockey channel via IC muteypast. I'm, uh, a real big field hockey fan, and I'd really love to be able to watch, uh, field hockey on my PC. 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. That's why they'll go ahead and use it as a tease/for the free publicity they'll get if they're the first ones to do it. People have spent a lot more on publicity stunts that would get a lot less coverage than this sort of thing would. There is no Nielsen's Ratings for multicast so that advertisers could get a feel for how many eyeballs they are going to hit. Some IP multicast products *do* offer the ability to track viewership (albeit at the cost of some degradation to IP multicast's otherwise essentially perfect scalability). Cisco's StreamWatch is one example that comes to mind. Regards, Joe
Re: multicast (was Re: Readiness for IPV6)
At 11:16 AM 7/9/2002 -0400, Leo Bicknell wrote: In a message written on Tue, Jul 09, 2002 at 10:06:10AM -0500, Chris Parker wrote: 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. Yahoo/Broadcast.com pushed this pretty heavily. MS's own media player supports multicast, so there definitely a *lot* of clients out there. There is a lot of client _SOFTWARE_ that supports it. There are very few clients on multicast enabled networks. I've got a couple million... not that many use it, though. There are a list of providers supporting multicast in conjunction with Yahoo/Broadcast.com found at: http://www.broadcast.com/mcisp/ I see quite a few cable and dialup providers on there ( and I work for one of 'em... ) It's a cute list. Where's ATT (with all the old Home customers)? Where AOL? Don't see UUNet either. I didn't say it was ubiquitous. While some are notably lacking, you do have some larger networks on that list. Note this is also just partners/peers with Yahoo/Broadcast, not everyone who supports multicast on their networks. Almost as important, people like Sprint are on the list. Last I checked (admittedly, over a year ago) there was no multicast for Sprint DSL customers, and Sprint high speed customers had to specifically request it, it was not turned on by default. Result, less than 1% of Sprint's customers actually had it turned on, I believe. I'd be suprised if 1% of _residential end users_ were on multicast enabled networks today. Very surprised. It may be a bit higher, but the number who access multicast content is decidedly tiny. More content would probably push it higher, as much fun as it is watching the ISS live on Nasa TV, it does get a bit dry. :) -Chris -- \\\|||/// \ StarNet Inc. \ Chris Parker \ ~ ~ / \ WX *is* Wireless!\ Director, Engineering | |\ http://www.starnetwx.net \ (847) 963-0116 oOo---(_)---oOo--\-- \ Wholesale Internet Services - http://www.megapop.net
Re: multicast (was Re: Readiness for IPV6)
On Tue, Jul 09, 2002 at 11:16:56AM -0400, Leo Bicknell wrote: http://www.broadcast.com/mcisp/ I see quite a few cable and dialup providers on there ( and I work for one of 'em... ) It's a cute list. Where's ATT (with all the old @Home customers)? Where AOL? Don't see UUNet either. Almost as important, people like Sprint are on the list. Last I checked (admittedly, over a year ago) there was no multicast for Sprint DSL customers, and Sprint high speed customers had to specifically request it, it was not turned on by default. Result, less than 1% of Sprint's customers actually had it turned on, I believe. I'd be suprised if 1% of _residential end users_ were on multicast enabled networks today. Very surprised. Speaking as the person who got Voyager.Net on the list, here's what the deal was at the time (~2+ years ago) You configure a tunnel between you and the broadcast.com folks and speak mbgp+msdp over it to get their (S, G) state info and traffic. They gave information on how to enable the dialup ports, etc.. for multicast. We did have a few customers complain what's this 224 crap traffic you are sending us. The broadcast.com people didn't seem to want to help bridge the native gap between upstreams and the edge customers. Providers I know have multicast enabled and available for customers in some way/shape/form: CW, GBLX, Sprint, Qwest, UUNet/UUCast, Verio It's my understanding that Sprint has enabled pim on all customer-facing interfaces and is configured for nlri unicast multicast on all their bgp sessions so once a customer toggles their end to unicast+multicast they can get mbgp prefixes. I do suggest getting your routes in the table, which will not cause instability then later look at/concentrate on the rest, pim, msdp, etc.. - Jared -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
RE: multicast (was Re: Readiness for IPV6)
Cynical/realist, it's a fine line. While p0rn does drive a lot of the utilization on the net, I doubt that the those content providers are going to be happy with sending their content un-protected across the net for anyone (paying or not) to see. So now you are into a encryption issue where you need to insure the receiving end can securely receive the encryption key and not share it. Not insurmountable, but not (that I'm aware of) possible with today's applications. The upshot is today's client applications need to grow to add these and other discussed features and functions to help the content providers. David -Original Message- From: Joe St Sauver [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 09, 2002 8:55 AM To: David Sinn Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: multicast (was Re: Readiness for IPV6) Hi, There is also a cart and horse issue here: Where is the pervasive content? At the risk of sounding somewhat cynical, I suspect the market driver for IP multicast will be what it often is for these sort of things: pr0n. My prediction? When one of the big adult hosting speciality companies starts IP multicasting free full length cable cut R-rated adult films in watchable MPEG1 quality, people will begin lobbying their ISP's for IP multicast support. Evidence supporting this assertion can be found in the popularity of events such as the Victoria Secret webcast, which reportedly drew more than a million viewers worldwide, even when streaming video was being done at postage-stamp-sized resolution. Of course, at the same time the pr0n channels get rolled out, there will also need to be something innocuous, like the Field Hockey Channel or the Brand-New-Bands-Live!-From-Small-Clubs Channel so that people will be able to use those less-embarassing content choices as their nominal interest when calling to request IP multicast support: Um, hi, my friends who connect via ISP Foo up the street tell me that if you do something to your network I can get the, uh, Field Hockey channel via IC muteypast. I'm, uh, a real big field hockey fan, and I'd really love to be able to watch, uh, field hockey on my PC. 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. That's why they'll go ahead and use it as a tease/for the free publicity they'll get if they're the first ones to do it. People have spent a lot more on publicity stunts that would get a lot less coverage than this sort of thing would. There is no Nielsen's Ratings for multicast so that advertisers could get a feel for how many eyeballs they are going to hit. Some IP multicast products *do* offer the ability to track viewership (albeit at the cost of some degradation to IP multicast's otherwise essentially perfect scalability). Cisco's StreamWatch is one example that comes to mind. Regards, Joe
Re: multicast (was Re: Readiness for IPV6)
Thus spake David Sinn [EMAIL PROTECTED] 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
Re: multicast (was Re: Readiness for IPV6)
Here's my $0.02 on the whole multicast thing. We've been at this for a number of years now, and robust, ubiquitous multicast on the internet is really nowhere in sight. Kind of sounds like QoS, and maybe there's a lesson there (20 years of research and IETF activity, yielding, well, what?). Given the amount of time and resource we've spent on multicast, the question one might ask is why hasn't multicast succeeded? My guess is that it is because the demand from any of the potential users of the service just isn't there (not at internet scales, at least not now). Add to this that there are other, possibly simpler mechanisms to accomplish much of the functionality that multicast envisions (e.g. application layer multicast; this even hits dial-up eyes with no modification), problems with billing models, and difficultly in deploying the existing set of protocols (too much complexity, broken architecturally on shared access exchanges, etc), and you might expect just about what we've experienced. Dave On Tue, Jul 09, 2002 at 09:56:34AM -0700, David Sinn wrote: Cynical/realist, it's a fine line. While p0rn does drive a lot of the utilization on the net, I doubt that the those content providers are going to be happy with sending their content un-protected across the net for anyone (paying or not) to see. So now you are into a encryption issue where you need to insure the receiving end can securely receive the encryption key and not share it. Not insurmountable, but not (that I'm aware of) possible with today's applications. The upshot is today's client applications need to grow to add these and other discussed features and functions to help the content providers. David -Original Message- From: Joe St Sauver [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 09, 2002 8:55 AM To: David Sinn Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: multicast (was Re: Readiness for IPV6) Hi, There is also a cart and horse issue here: Where is the pervasive content? At the risk of sounding somewhat cynical, I suspect the market driver for IP multicast will be what it often is for these sort of things: pr0n. My prediction? When one of the big adult hosting speciality companies starts IP multicasting free full length cable cut R-rated adult films in watchable MPEG1 quality, people will begin lobbying their ISP's for IP multicast support. Evidence supporting this assertion can be found in the popularity of events such as the Victoria Secret webcast, which reportedly drew more than a million viewers worldwide, even when streaming video was being done at postage-stamp-sized resolution. Of course, at the same time the pr0n channels get rolled out, there will also need to be something innocuous, like the Field Hockey Channel or the Brand-New-Bands-Live!-From-Small-Clubs Channel so that people will be able to use those less-embarassing content choices as their nominal interest when calling to request IP multicast support: Um, hi, my friends who connect via ISP Foo up the street tell me that if you do something to your network I can get the, uh, Field Hockey channel via IC muteypast. I'm, uh, a real big field hockey fan, and I'd really love to be able to watch, uh, field hockey on my PC. 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. That's why they'll go ahead and use it as a tease/for the free publicity they'll get if they're the first ones to do it. People have spent a lot more on publicity stunts that would get a lot less coverage than this sort of thing would. There is no Nielsen's Ratings for multicast so that advertisers could get a feel for how many eyeballs they are going to hit. Some IP multicast products *do* offer the ability to track viewership (albeit at the cost of some degradation to IP multicast's otherwise essentially perfect scalability). Cisco's StreamWatch is one example that comes to mind. Regards, Joe
Re: multicast (was Re: Readiness for IPV6)
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
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. 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
Re: multicast (was Re: Readiness for IPV6)
Chris Parker wrote: It may be a bit higher, but the number who access multicast content is decidedly tiny. More content would probably push it higher, as much fun as it is watching the ISS live on Nasa TV, it does get a bit dry. :) I think this is a case of if you build it, they will come. RealPlayer's default configuration is to first attempt to use multicast, then fail-over to UDP, then fail-over to TCP. In other words, if multicast is available, the program will use it. I don't know about other streaming clients, but I would guess that others would behave similarly. -- David
Re: multicast (was Re: Readiness for IPV6)
Thus spake David Meyer [EMAIL PROTECTED] Here's my $0.02 on the whole multicast thing. We've been at this for a number of years now, and robust, ubiquitous multicast on the internet is really nowhere in sight. Kind of sounds like QoS, and maybe there's a lesson there (20 years of research and IETF activity, yielding, well, what?). OTOH, multicast and QOS are both widely deployed inside most large corporate networks and are rapidly approaching ubiquity. They both effectively solve business problems and therefore there's a big motivation for them, and the IETF's efforts have been extremely fruitful. Don't let the IETF's (or NANOG's) ISP-centric membership blind you to that. S
Re: multicast (was Re: Readiness for IPV6)
Thus spake Jeff Aitken [EMAIL PROTECTED] 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. ATT 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
Re: multicast (was Re: Readiness for IPV6)
the heck do i know wether eggs would taste better than spam. I do not want eggs, let me eat spam! And even worse, people don't know what eggs are. They only want omolettes! (Multicast ? Huh ? give me live streaming radio and video, on-line on-demand music, software and video download for this weeks hippest product, stock ticker for my dad and large scale interactive multiplayer gaming with short latencies, that's what i want. What was this multicast stuff again ?) Add to this that there are other, possibly simpler mechanisms to accomplish much of the functionality that multicast envisions (e.g. application layer multicast; this even hits dial-up eyes with no modification), Simpler for certain business cases, like when you have an obsolete infrastructure that is entangled in all kind of legacy conditions, sure. IP Multicast was never designed as the ideal transition solution. If we would have listened to this transition argument back in the 1980th then we today would not have IP at all, but just applications that have to be commissioned by national PTTs running on top of X25 over ATM or the like. Ridiculous ? Well, look what processes are involved in provisioning a live video stream into the Internet with overlay networks then you know what i mean. Free choice of the receiver ? It's closer to the frustration you have as a cable-tv customer in getting 200 useless channels but guaranteed not the 5 ones you want. problems with billing models, FUD. What problem with billing models ? If you are an ISP, you are selling bandwidth. If another receiver joins the content , you get another piece of egress bandwidth filled up which hopefully is being paid for. If you need to cross-charge this back to the ingress-point, so do it. You just technically can't simply have accounting points on your exchange points anymore if you need to do so, you also need them on the delivery side of your network. More complex things than this have been done in the past. And of course, that could even be improved if demand for technology improvements was there (like eyeball count transmission via PIM). existing set of protocols (too much complexity, broken architecturally on shared access exchanges, etc) Just do SSM if you are troubled by complexity of protocols. And besides: I never got the impression that technical complexity issues are decisive for the success or lack thereoff: It is the missing drive from marketing at the places connecting to eyeballs. Marketing only buys complete solutions nowadays with lots of recent buzzwords per square inch, they do not dare to get involved in anything infratructure if they can not prove beyond a doubt that there will be a financial gain within the next 2..3 quarters - however small the actual investment would be! Can you blame them ? So, given this market situation (*mumble* *mumble* i want my good old pre 1995 Internet back ;-), IP multicast will grow out of those closed loop business cases, and when we're lucky, actual eyeball ISPs will not only use those to provide another preprovisioned set of 100 TV channels, but also allow receipt of arbitrary Internet sourced Ip multicast traffic, so that the open ended promise can start to work! For this to happen, quite frankly i would not bet on the incumbants, as much as i would like them to be there, because i trust them to have the most solid expertise, but unfortunately they also have the lowest market driver. And incumbants can mean as much country with well established infratstructure (dismal but sufficient cable or dsl) as it can mean actual companies. Toerless Dave On Tue, Jul 09, 2002 at 09:56:34AM -0700, David Sinn wrote: Cynical/realist, it's a fine line. While p0rn does drive a lot of the utilization on the net, I doubt that the those content providers are going to be happy with sending their content un-protected across the net for anyone (paying or not) to see. So now you are into a encryption issue where you need to insure the receiving end can securely receive the encryption key and not share it. Not insurmountable, but not (that I'm aware of) possible with today's applications. The upshot is today's client applications need to grow to add these and other discussed features and functions to help the content providers. David -Original Message- From: Joe St Sauver [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 09, 2002 8:55 AM To: David Sinn Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: multicast (was Re: Readiness for IPV6) Hi, There is also a cart and horse issue here: Where is the pervasive content? At the risk of sounding somewhat cynical, I suspect the market driver for IP multicast will be what it often is for these sort of things: pr0n. My prediction? When one of the big adult hosting speciality companies starts IP multicasting free full length cable cut R-rated adult films in watchable MPEG1
Re: multicast (was Re: Readiness for IPV6)
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. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: multicast (was Re: Readiness for IPV6)
the IETF's efforts have been extremely fruitful. That is good to hear. Dave
RE: multicast (was Re: Readiness for IPV6)
I guess I'll toss in my two cents here. I see this all as a weird kind of catch-22 on how multicast would ever become viable. To get multicast going, people have to convince their ISPs that multicast is a good idea. Now, the large businesses that provide the content have done a decent job of getting the ISPs to support (at least nominally) multicast. The problem comes in at the content consumer level (dial, DSL etc). To get these providers to support multicast, their users will probably have to complain to them and convince them it's worth their while. The majority of users will not make this effort. Why should they? The only benefit they get from multicast is if they run a LAN (not so unlikely) and have multiple listeners for the same multicast stream (much less likely). So, for most consumers, there is no direct benefit for multicast. Yes, if consumers where just a little more far sighted, the eventual cost savings multicast would provide might be an incentive. Then again, I think most consumers are jaded enough to think that they'd never see the savings anyway, and the content provider would just pocket the money (or at least I am). snip a discussion of free market economics here If multicast is ever to become viable, either there will have to be a grass roots campaign for it from all the dsl/cable/dial up users (again, not likely as they have no real motivation), or several large content providers go to the dsl/cable/dial up providers and make a push for them to enable multicast or else. -Nate
Re: multicast (was Re: Readiness for IPV6)
On Tue, Jul 09, 2002 at 11:51:08AM -0700, Toerless Eckert wrote: FUD. What problem with billing models ? If you are an ISP, you are selling bandwidth. If another receiver joins the content , you get another piece of egress bandwidth filled up which hopefully is being paid for. If you need to cross-charge this back to the ingress-point, so do it. You just technically can't simply have accounting points on your exchange points anymore if you need to do so, you also need them on the delivery side of your network. More complex things than this have been done in the past. And of course, that could even be improved if demand for technology improvements was there (like eyeball count transmission via PIM). How about as a service provider... How could you possibly bill someone for a packet if you have no idea how much of your network resources it will consume? Most people bill at the customers' port, as a receiver of multicast there are no issues, but as a sender I havn't seen anyone come up with a satisfactory way to charge for it. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
Re: multicast (was Re: Readiness for IPV6)
On Tue, 9 Jul 2002, Richard A Steenbergen wrote: On Tue, Jul 09, 2002 at 11:51:08AM -0700, Toerless Eckert wrote: FUD. What problem with billing models ? If you are an ISP, you are selling bandwidth. If another receiver joins the content , you get another piece of egress bandwidth filled up which hopefully is being paid for. If you need to cross-charge this back to the ingress-point, so do it. You just technically can't simply have accounting points on your exchange points anymore if you need to do so, you also need them on the delivery side of your network. More complex things than this have been done in the past. And of course, that could even be improved if demand for technology improvements was there (like eyeball count transmission via PIM). How about as a service provider... How could you possibly bill someone for a packet if you have no idea how much of your network resources it will consume? If I source a 1Mb/s stream my upstream can be assured that it will use no greater than 1Mb/s on each of their multicast transit links... that may require a different billing structure than unicast but it's easy to measure (netflow) or bill for... their internal network make look strange though.. if they have a full mesh (mess maybe) mpls network provisioned on top of their access circuits they may carry the same traffic more than once of the same link... such are the joys of tunnels. Most people bill at the customers' port, as a receiver of multicast there are no issues, but as a sender I havn't seen anyone come up with a satisfactory way to charge for it. -- -- Joel Jaeggli Academic User Services [EMAIL PROTECTED] --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
Re: multicast (was Re: Readiness for IPV6)
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
Re: multicast (was Re: Readiness for IPV6)
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 [EMAIL PROTECTED] --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
