North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Real Media and M-Bone feeds
Caching doesn't work for live content. D. At 08:39 AM 10/5/99 -0700, Andy McConnell wrote: > >On Tue, 5 Oct 1999, Alex P. Rudnev wrote: > >} >}> > 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. >}Wrong... >} >}Multicast is just not more than one case of data caching on the fly. It >}can be used for the local networks, just with the net of the media >}replicators. In principle there is not big difference between multicast >}and www caching except first is an example of the _real-time caching_ and >}second is usially _store-and-forward_ caching. > >It it really comparable to caching? I see multicasting as more of a >traffic reduction, rather than a cache. > >}This days we can see the weakness of the global-multicasting - and I think >}it should be replaced by the media-caching servers (with the ability to >}replicate data on the fly - in case of live media stream, and short or >}long tome _store-and-forward_ in case of Video-on-demand stream) - and >}with just this multicasting on the very end of the data tree. But an >}attempts to build over-the-world multicast network - brr... it's possible >}(if you should dig some mountain every day, you'll build a tunnel at last; >}but may be it's easy to run this mountain over?). > >Your model would work, but it requires a LOT more coordination and >cooperation than even multicast requires. Are you sugesting that networks >implement machines that sniff into the data, identify those streams, >intercept them, and then coordinate with the streams' sources to stop >sending the unicasts behind the cache, and send the stream to the cache >only? Or will your new machine simply "spoof" the source? If the latter, >then you haven't told the sender to reduce the traffic. > >You mentioned your doubt of building an over-the-world multicast >network... but what you are sugesting seems to be an over-the-world >caching mechanism. If we are going to build an over-the-world anything, >why not build on the IP model, which is already over-the-world? > >The whole reason for multicast is to reduce the traffic at the source, not >necessarily just then receivers. And the concept behind ip multicast is >to replicate as closely as possible the IP model - send trafic to an IP >address, and let the layer 3 devices forward the packet to the right >shared-media networks as required. > >}And - your NANOG forum is the excellent example. RealVideo streaming work >}fine; Multicast don't work at all; why do you try to use weak schema >}instead of the strong one? No enougph bandwidth - install stream >}replicators inb the key points; build _replication on the fly_ schemas >}(such as CCP for the www caching on the fly), etc. No, even with all >}attempts Cisco and some other are trying this days - multicast is more >}dead than alive. I can get 10,000 multimedia sources by RealVideo or >}StreamVideo - and I can't get nothing usefull by multicast. If I could >}install RV-cache engine (cache on the fly) - I should choose this >}solution. > >You can get a lot more software for Windows, too, but that doesn't make it >the right solution all the time. How much software was available for >Linux just two years ago? Market share is a poor measurement of the >quality and capability of a solution. > >-andy > >-- >Andy McConnell IP Operations Manager [email protected] >NTT America Network and IP Service Division +1 408 873 3757 >$B??8~N}(B $B0BEHN6(B NTT$B%"%a%j%+(BIP$B%*%Z%l!<%7%g%sC4Ev2]D9(B > >"What right does Congress have to go around making laws just because they >deem it necessary?" > - M. Barry, Mayor of Washington, DC > > >
|