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

Mailman List Mirror (Read Only)
1

> > Acceptable arguments are:
> > o Switches can handle more throughput
>
> That's difficult to quantify in theory *or* practice.
> [...]

I may misunderstand your assertion, but it doesn't seem all that
difficult to quantify, at least to some coarse level.

We have been using wide-area ATM switches at OC-3c for some time.
It is pretty clear that the switches can handle OC-3c. The
early switches had relatively small output buffers, so they tended
to loose cells before TCP could throttle back in congested circumstances.
We are now using switches with much larger output buffers, and TCP appears
able to throttle back fairly gracefully.

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,
and only extended their scope if they leased an ADSU to a customer. Even
with the improved buffering, 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.

The performance of the switched technology is integral with the equipment
attached to it. You cannot evaluate the performance of the system by
analyzing small chunks of it, and coming to conclusions on the whole system.

This is what I'm talking about. It's easy to qualify that ATM switches
can switch cells much faster than routers can switch packets (with current
commercially available routers), but it's much more difficult to qualify
the scope of how ATM improves performance in the big picture.

Dave

2

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.

  Sean.