ATM Wide-Area Networks (was: sell shell accounts?)

Sean Doran smd at
Wed Jul 24 00:00:17 UTC 1996

| It's difficult to quantify wrt to how ATM plays a role in end-to-end 
| performance on the Internet.  There is very little research to support how
| ATM affects the overall performance.  Even Ameritech and PacBell restricted
| the majority of their performance evaluation on
| performance in the switch

Well, perhaps it's better from me than from someone very
fond of ATM: this is comparing apples and oranges.

ATM can be used in two main modes: as a funny form of TDM
or as a means of overcommitting resources.

The former is in use now in the land of InternetMCI,
ESNET, NSI and others, for better or for worse, and has
been for some time.   As Tim and others have pointed out,
it works, given some tweaking here and there with things
like EPD.

The latter has been observed in use as an offering by MFS,
and it had obvious problems.  It has also been observed
from time to time at the ATM-using NAPs, and also had
obvious problems.  These problems were arguably not
directly the fault of ATM, but of arguably broken
interface and adaptation devices like ADSUs, ethernet
framers and FRADs.

At the same time, using *BR and the like to manage the
overcommitment of resources has largely been limited in
scope, and in particular, I do not know of any serious use
involving ABR in particular and a mix of heavily
aggregated low-bandwidth traffic competing with traffic
with high bandwidth*delay traffic.  I also do not know of
any serioufs use of IP over ATM in this mode on very long
haul lines.   (If anyone _does_, drop me a note).

I certainly have some hypotheses (namely that it won't
work very well), however they haven't been fully tested,
and moreover, I don't think it's very smart to test them
out using production Internet traffic, given the serious
nature of the failure modes we _do_ know about.

And for Tim:

| if you fill your pipe into the ATM switch,
| your ATM switch still becomes a packet shredder, compared to the more
| graceful packet drops seen on a clear channel line.

"packet shredding" here is the effect seen where attempts
at traffic shaping within an ATM cloud results in cells
being dropped from within IP datagrams.  This is
particularly toxic with TCP flows with large
delay*bandwidth products, since, as we must assume large
congestion windows, the arrival of a damaged segment may
drop a flow's goodput through the floor.   While FR^2 and
SACK appear to help out, the presence of many damaged
TCP segments in flight on people's wires will not really win
much love for ATM by the people who pay for those wires,
and that ultimately is end-to-end.

A network that does not behave as a "packet shredder" is
one which discards whole IP datagrams, to avoid
transmitting damaged goods through fractional paths.

However, drops on a clear channel line are not graceful,
and only happen when there is insufficient end-to-end
buffering in the presence of congestion to allow delayed
ACKs to cause transmitters to slow down.  On the other
hand, it is more difficult to overcommit a clear-channel
pipe used principally for TCP by virtue of slow-start, 
whereas overcommitting a pipe is often considered a
feature of ATM, and most ATM switches make it very easy 
to do.


More information about the NANOG mailing list