From: Randy Bush <randy@psg.com>
Multicast is broken as an idea, period. Now, why won't we just forget about it and spend our life doing something useful instead?
because, although it is getting less expensive quickly, transport costs money. multicast promises to reduce that cost near sources.
I strongly suspect that the combined time of engineering staff spent on deployment and development of mulitcasting won't be paid off by the supposed transport cost savings any time soon. Worse yet, it distracts from deployment of the real solution - cacheing.
this is a better fantasy than the qos smokers who think it will effectively get more bits into the pipe.
...or at least more buds :) --vadim
On Tue, Oct 05, 1999 at 10:29:49AM -0700, Vadim Antonov wrote:
From: Randy Bush <randy@psg.com>
Multicast is broken as an idea, period. Now, why won't we just forget about it and spend our life doing something useful instead?
because, although it is getting less expensive quickly, transport costs money. multicast promises to reduce that cost near sources.
I strongly suspect that the combined time of engineering staff spent on deployment and development of mulitcasting won't be paid off by the supposed transport cost savings any time soon.
The problem is that everyone thinks that multicasting is more complicated than it really is. How many people would be interested in a presentation of some sort on multicast, and deployment? The key here is education, and the people who understand it tend to not be good at explaining it, nor willing to spend the time educating the masses as necessary these days, as their jobs have them working too many hours, or traveling enough. I've found that once you spend the time necessary to explain how it works from the 20,000 foot view and then start to come in closer you end up with people understanding it much better than they ever have before. People try and overthink a few too many things, and this I think is one. I'd be willing to do a multicasting BOF or somesort at the next nanog if there is interest. Including real life deployment examples, and practical applications for use.
Worse yet, it distracts from deployment of the real solution - cacheing.
Multicasting is faster than disk. I'm not sure how caching is the solution. Distributed content is also good.
this is a better fantasy than the qos smokers who think it will effectively get more bits into the pipe.
...or at least more buds :)
--vadim
-- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. END OF LINE |
I strongly suspect that the combined time of engineering staff spent on deployment and development of mulitcasting won't be paid off by the supposed transport cost savings any time soon.
The problem is that everyone thinks that multicasting is more complicated than it really is. Jared, we (I and Vadim - it's amazing but we are far one from another but support the same ideas) don't think multicasting is complex; but to build stable, hacker's/free, well controlled multicast network is really the complex (and unsolved yet) task.
And when thuch network will be (if) built, it cover only 10 - 15% of the customers demand - only LIVE-MULTIMEDIA, while 90% of this demand is _on-demand multimedia_ (hope I did not twisted my idea by the wrong translation). I here do not need multicasting now; I need to get a numerous multimedia sources I have now in Internet, and made this sources available widely by decreasyng the bandwidth they use in our uplinks. We have 1 - 2 - 3 live events a week, and we have 10,000 - 100,000 on-demand sources - it's a difference. And (more important) it's a better way to solve boths problems at once than to follow _multicast_ idea blindly. Multicast works well in the DENSE case - when you have a LAN network with the 10 - 20 listeners; it's useless in the RARE network when 100 customers listen everyone to his own stream. Moreover, multicast do nothining (almost) in comparation with existing air broadcasting, it's not more than one extra transport (and very complex transport - turn on your TV or your radio-tuner - and you can listen to the Russion radio stations even from the USA - now try the same by multicast); but ON-DEMAND streams provide new feature for the customers - you can't call TV station and ask _show me this animation_ - but RealVideo client can. And the other idea I am talking again and again is very simple - there is not PRINCIPIAL difference between caching, replication and multicasting - it's the same process with some different tunings. Alex
How many people would be interested in a presentation of some sort on multicast, and deployment? The key here is education, and the people who understand it tend to not be good at explaining it, nor willing to spend the time educating the masses as necessary these days, as their jobs have them working too many hours, or traveling enough. Yes, you are right, the education is one example when you can found the DENSE network.
You forgot to mention _feed-back in case of the video-conferencing_ - and just again it's an example when existing multicasting have the strict position. And... that's all, this is not big part of the internet's users.
People try and overthink a few too many things, and this I think is one.
I'd be willing to do a multicasting BOF or somesort at the next nanog if there is interest. Including real life deployment examples, and practical applications for use.
Worse yet, it distracts from deployment of the real solution - cacheing.
Multicasting is faster than disk. I'm not sure how caching is the solution. Distributed content is also good.
To be strict, disk is faster than the multicasting. Then, in case of the LIVE-STREAM, caching have 0 time-to-live and became the simple replication. In case of the DENSE network, the best way to do replication is multicasting. We don't deny such _edgge_ case, but it's only one state of the caching machine.
On Tue, Oct 05, 1999 at 11:22:51PM +0400, Alex P. Rudnev wrote:
I strongly suspect that the combined time of engineering staff spent on deployment and development of mulitcasting won't be paid off by the supposed transport cost savings any time soon.
The problem is that everyone thinks that multicasting is more complicated than it really is. Jared, we (I and Vadim - it's amazing but we are far one from another but support the same ideas) don't think multicasting is complex; but to build stable, hacker's/free, well controlled multicast network is really the complex (and unsolved yet) task.
Yes, there are the hacker related issues that need to be addressed. I'm not touching on that here directly...
And when thuch network will be (if) built, it cover only 10 - 15% of the customers demand - only LIVE-MULTIMEDIA, while 90% of this demand is _on-demand multimedia_ (hope I did not twisted my idea by the wrong translation).
[see further down on percentages]
I here do not need multicasting now; I need to get a numerous multimedia sources I have now in Internet, and made this sources available widely by decreasyng the bandwidth they use in our uplinks. We have 1 - 2 - 3 live events a week, and we have 10,000 - 100,000 on-demand sources - it's a difference. And (more important) it's a better way to solve boths problems at once than to follow _multicast_ idea blindly.
Absoluteley.
Multicast works well in the DENSE case - when you have a LAN network with the 10 - 20 listeners; it's useless in the RARE network when 100 customers listen everyone to his own stream. Moreover, multicast do nothining (almost) in comparation with existing air broadcasting, it's not more than one extra transport (and very complex transport - turn on your TV or your radio-tuner - and you can listen to the Russion radio stations even from the USA - now try the same by multicast); but ON-DEMAND streams provide new feature for the customers - you can't call TV station and ask _show me this animation_ - but RealVideo client can.
With the advent of DSL, etc.. and the more people that are entering the broadband markets, I think that this will change. The number of people that are sending live media all the time I believe will change. Currently numerous radio stations are sending live audio via (some sort of) streaming media to the world, either via the real products, or via the m$ products, or both. As more and more people get higher bandwidth solutions into their homes, (dsl, cable, etc), there are people out there that would like to start sending their video along with audio. Creating the ability for there to be a less resource intensive one-to-many system on the broadcaster will (in my mind) allow more people to get into the sourcing these types of sources, for either pay, or whatnot. (Think USA cable, pay-per-view.. they make their money someplace). I'm not saying that the on-demand media is not important, but I see more and more live events also being there. The on-demand media will be important, but you can distribute your on-demand servers across multiple providers, but your live media needs to be more transportable. - Jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. END OF LINE |
participants (3)
-
Alex P. Rudnev -
Jared Mauch -
Vadim Antonov