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:JOE@OREGON.UOREGON.EDU] Sent: Tuesday, July 09, 2002 8:55 AM To: David Sinn Cc: bicknell@ufp.org; nanog@merit.edu 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
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:JOE@OREGON.UOREGON.EDU] Sent: Tuesday, July 09, 2002 8:55 AM To: David Sinn Cc: bicknell@ufp.org; nanog@merit.edu 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
Thus spake "David Meyer" <dmm@sprint.net>
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
On Tue, Jul 09, 2002 at 10:16:38AM -0700, David Meyer wrote:
Given the amount of time and resource we've spent on multicast, the question one might ask is "why hasn't multicast succeeded"?
Has it not ? It is succeeding in every place where you have a closed financial business model from content to eyeball. It is purely failing to be established as a network connectivity infrastructure component by access ISPs because these access ISPs do not invest in their own future if you ask me. If we would have had the same business model driven network infrastructure and technology deployment politics that we have today in the beginning of the 1990th then we would not have the Internet==TheWeb today. Luckily at that time the IP unicast infrastructure was expanded predominantly by research, academic and other public funding (DoD, ES, NSF, etc..) so that we reached a critical mass of eyballs that made the upcoming technology of the web viable enough to get businesses jumpstarted into that web technology. And see where it is today. IP multicasts main intrinsic downside is that it is not a good transitional technology today. This means that you first must provide for a critical mass of eyballs before you will get new content using it. Who did jumpstart the web with content ? The incumbant book stores, CD dealers or retailers ? No, of course not. It was new content. The incumbants had an established infrastructure, thank you very much, i am making lots of money out of analog cable-tv at dismal quality, go away with new technology. Did the web startups have the money to demand the establishment of the Internet infrastucture ? No, not in the beginning - only after the ralley set off. It just kicked off by the initial pre-web user basis and grew from there on. And see what growth curve it got. Don't tell me you wouldn't want to repeat that again - and this time you'll all sell your stock at the ideal time, right ;-)) ? Who today can do streaming media across the Internet ? Well, mostly the big players because the financial overhead in using overlay networks is way too high. How progressive are the big players ? Well... how about the music industry. Where would we be with streaming audio in the Internet if it was not for Napster ? So right, there is starting to be some movie-on demand download now. Is it attractive ? Well... we can argue that for a long time, but in the endthe new technology is the best chance for new content and/or new providers, not necessarily to replace incumbant solutions - because for incumbant solutions everybody just makes a cost comparison, and that's a much longer term goal to reach once you already have a paid off infrastructure in place. With ip multicast as an end-to-end transport component you could repeat the success model of the web for streaming content to large number of receivers. Think about the anybody startup who could broadcast a streaming video to arbitrary many people like he could back in 1995 reach 'arbitrary' many people with this "web" thing application. If we would have let's say 10 mio eyeballs @ home that reliably could get ip multicast, then this would be a critical mass for smaller content providers to start out providing content for them. Why is it not happening ? See above: Because investment in ISPs today is driven by marketing and marketing is driven purely by the "solution" buzzword. IP multicast is not a solution in itself, it is a technology. If you have a business case with an application, content, control the whole path and have the eyeballs - then you have a solution, otherwise you just have a piece of the infrastructure. But those business cases are always individual ones, and even though they can be big and successfull (like in the finance markets or upcoming in enterprise ip multicast transit), you will often not even know afterwards that IP multicast is used in them and that over time leaves a totally skewed picture on the success of ip multicast. And we don't really talk about these business specific solutions that IP multicast thrives from today. What we talk about here is the main and open ended promise of IP multicast as a ubiquitous network transport component in the ISP transit space, right ? This open ended promise is exactly what we have seen to play out so well with IP unicast and the web. How do you get this open ended message into marketing heads and repeat it for ip multicast ? I don't know: IP multicast has been around for too long, so it is not a marketing buzzword anymore, and sound investment into infrastucture components is not on the agenda of access ISPs. FUD rules.
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).
Think 1995, think web. What demand ? How do you measure demand, how can you predict demand ? You generate hype ? "There is no demand" is just backward looking: "I do not have eggs. I do not need need chicken. What 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:JOE@OREGON.UOREGON.EDU] Sent: Tuesday, July 09, 2002 8:55 AM To: David Sinn Cc: bicknell@ufp.org; nanog@merit.edu 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
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 <ras@e-gerbil.net> 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)
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 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"
David Meyer <dmm@sprint.net> writes:
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.
1. The problems that multicast solves are also solved by the favorite solution of business: buy your way out of the problem. Bigger fatter pipes. More bandwidth. Beefier routers. The problems have been addressed (papered over) by an alternate -easily implementable- but not superior algorithm.
Kind of sounds like QoS, and maybe there's a lesson there (20 years of research and IETF activity, yielding, well, what?).
2. The problems that Qos solves are also solved by the favorite solution of business: buy your way out of the problem.
Given the amount of time and resource we've spent on multicast, the question one might ask is "why hasn't multicast succeeded"?
goto 1. recurse. I do think, however, that we've all gotten it quite wrong since the beginning. Multicast is not a subset of IP. It is IP. With a different view of the protocol, unicast IP is a multicast group of 2. Broadcast is a multicast group of all... perhaps if the infrastructure reflected that from the get-go, we wouldn't be in this situation. Peace, Petr
--On Tuesday, July 09, 2002 10:16:38 -0700 David Meyer <dmm@sprint.net> 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 -
participants (8)
-
David Meyer
-
David Sinn
-
Joel Jaeggli
-
Kurt Erik Lindqvist
-
Petr Swedock
-
Richard A Steenbergen
-
Stephen Sprunk
-
Toerless Eckert