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