|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Real Media and M-Bone feeds
> > 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.
|