|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Real Media and M-Bone feeds
> > 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. ;-) Yes, when you have the _caching-replicators_ and you see some parts of your network became a _bottlechecks_, and this parts have multicast (local) option, you can use mcast (i.e. use L2 packet repliation instead of L4 replication). This schema should work well from the very first days, and should be improved in time if the multicast-able area will increase. Note - it don't need inter-AS-es multicast at all, don't need any modification on the data sources (except may be some priority for the replicators), don't need (almost) any modification for the clients, and provide bandwidth economy from the first days. MCAST - work only where it exists, have un-resolved problems, can hardly be installed over the AS boundaries, need to modify data sources and clients, can't work for the on-demand streams. Of course, until no one made attempt to build such _cache-and-replicate-on-the-fly_ engine (as CISCO built their WEB CACHE engine) - it's not more then theory. > > party on, > Sam > > -- > Those who do not understand Unix are condemned to reinvent it, poorly. > -- Henry Spencer > 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)
|