Real Media and M-Bone feeds

Tue Oct 5 22:20:16 UTC 1999

On Tue, Oct 05, 1999 at 02:39:04PM -0700, Tim Wolfe wrote:
> 
> Conceptually, is it that much more effort for a server/router/device to store a
> local copy of a packet as it passes through the server/router/device than it
> is to simply forward said packet?  Admittedly, the client to cache
> interaction is somewhat more complicated but would seem to be addressable
> using (mostly) existing technology.  Would "Live" content be incredibly
> hampered by a 500 ms (or less) delay so that the cache could receive the
> data and distribute it to the appropriate users locally?

What would be the point of this?
What you would accomplish with this setup compared to multicasting is
moving the redundant parallel data streams closer to the receiver, inside
the provider's network. For n receivers, the cache still has to send out
n streams, and if the data truly is treated as "live/real-time", it ends
up sending n identical (except for destination address) packets out its
outbound interface. This is n*bitrate of traffic that has to travel from
wherever the "packet-cache" is, accross the internal network to wherever
the recipients are. With multicast, if there is a large enough collection
of receivers to justify a cache, there will be at most 1*bitrate on any
single connection on the internal provider network. The cache solution is
less optimal in this case. If you suggest a hierachical cache (i.e. main
cache takes a feed, replicates to n distributed caches closer to the
receivers) you have just re-invented multicast, and not very well. ;-)

party on,
Sam

-- 
Those who do not understand Unix are condemned to reinvent it, poorly.
                -- Henry Spencer