Sean M. Doran wrote:
You want bounded delay on some traffic profiles that approach having hard real time requirements. (Anything that has actual hard real time requirements has no business being on a statistically multiplexed network, no matter what the multiplexing fabric is).
Hey, if you make sure that _class_ of traffic has enough bandwish (no matter how overloaded the network is by other classes of traffic), you're pretty much ok with stochastical muxing.
This can be implemented in routers now, with or without MPLS/tag switching, although having the latter likely makes configuration and maintenance easier.
...or harder :) Adding more complexity seldom makes life easier.
Delay across any fabric of any decent size is largely determined by the speed of light. Therefore, unless ABR is deliberately inducing queueing delays, there is no way your delay can be decreased when you send lots of traffic unless the ATM people have found a way to accelerate photons given enough pressure in the queues.
Well, that's not absolute delay which is interesting (can't do anything about it anyway short of exploiting EPR paradox, or drilling a hole all the way to Australia), but rather variance of delay. Having large variance is equivalent to adding that variance to the propagation time :( Given that in single-class tail-drop IP networks the variance can be as large as RTT*number_of_hops (if the network has the buffers of just right size), the effect can be significant. What worries me about ABR and other traffic shaping stuff more is a) scalability and b) it encourages real-time transmission of non-realtime "canned" contents. I would expect that 99% of all A/V feeds over the network will be unidirectional (tv, movies, web, etc), and so can be delayed by hundereds of ms without any ill effects. The only really interactive kind of A/V contents (telephony / video telephony) is so low-bandwidth compared to full-motion movies that we probably shouldn't care about it. --vadim