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 andym(a)ntt.net
>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
>
>
>
