Real Media and M-Bone feeds

Darin Divinia ddivinia at broadcast.com
Tue Oct 5 16:18:38 UTC 1999


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 at 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
>
>
>





More information about the NANOG mailing list