ATM (was Re: too many routes)

Vadim Antonov avg at
Fri Sep 12 00:46:42 UTC 1997

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

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

More information about the NANOG mailing list