Real Media and M-Bone feeds

Tue Oct 5 16:35:11 UTC 1999

> From: Darin Divinia <ddivinia at broadcast.com>
> To: Andy McConnell <andym at ntt.net>, Alex P. Rudnev <alex at Relcom.EU.net>
> Cc: Randy Bush <randy at psg.com>, Vadim Antonov <avg at kotovnik.com>,
     nanog at merit.edu
> Subject: Re: Real Media and M-Bone feeds
> 
> Caching doesn't work for live content.
Caching work for the live content - it became REPLICATION.

If you have cache engine which can:

- catch request,
- ask the data source about the data stream itself
- store the data stream, just as replicate it to those who requested it
- reproduce the data stream from the cache

Then you have a few cases:

(1) store time - 0, all data are replicated on the fly - live streams,
multicasting is one of the ways to do replication;
(2) store time - long, can't replicate data at all (every request get it's
own data stream) - just existing WWW cache engine
(3) store time - middle (few hours), the requested are delayed a little in
attempts to merge a few Media-On-Demand requests into the same answer -
MultiMedia cache.

I have pointed here - the customers demand is (from my point of view, you
can disagree) more ON-DEMAND multimedia content. Multicasting does nothing
with it. Multicasting does nothing about existing multimedia content.
Multicasting need in fact to build new interaction schemas between an ISP
over the world. That's why I don't think it's the best solution for the
multimedia demand we have from the customers this days.

On the other hand, if you have a dense multimedia streams in some network
(for example, Internet TV delivered by ADSL in the local region) and it's
just in the one ISP - multicast can be used as ONE of the delivering
methods. For now, it exist more as an independent address schema.

Alex Roudnev.

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

Aleksei Roudnev, Network Operations Center, Relcom, Moscow
(+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 230-41-41, N 13729 (pager)
(+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)