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

Mailman List Mirror (Read Only)
1

From: Dave Siegel <dave@rtd.net>
Subject: Re: sell shell accounts?
To: freedman@netaxs.com (Avi Freedman)
Date: Fri, 19 Jul 1996 16:01:01 -0700 (MST)
Cc: vansax@atmnet.net, richards@netrex.com, agislist@interstice.com,
        nanog@merit.edu

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

After we upgraded our switches to use much larger output buffers, most of
the problems we experienced were related to the hosts, (e.g., poor
TCP implementations, poor ATM interfaces, etc).

By the way, I believe that most people who are using ATM wide-area networks
in production or as part of the Internet are using static bandwidth
allocation to avoid a number of problems.

We also have a number of OC-12c interfaces for our switches. They
appear to work, but we haven't really had a chance to stress them
yet. (Part of the problem is that it is hard to find OC-12c data
sources and sinks.)

The current generation of routers appears unlikely to support OC-12c,
particularly since their backplanes are only about the same speed.

On a more theoretical note, switches, being circuit-switched, make
the complicated decisions when the connection is established, (or
configured for PVCs), and need to make relatively simple decisions
to switch each cell. This probably scales very well is terms of
speed, although at some point might have some difficulty in scaling
to a very large number of simultaneous connections.

Routers, on the other hand, have to make a bit more complicated
decisions per packet. This has some limitations in terms of speed
and number of simultaneous "connections."

-tjs

2

By the way, I believe that most people who are using ATM wide-area networks
in production or as part of the Internet are using static bandwidth
allocation to avoid a number of problems.

Correct. Milo Medin said it best, IMHO: "ATM is really
just TDM with really small time-slots".

The problem is that many ATM proponents want to believe
that ATM qua TDM is not enough, but rather espouse the
magic of *BR, particularly ABR, to allow for an
overcommittment of long-haul capacity. Nice idea, but it
doesn't seem to work very well in practice, and
particularly not with a mix of heavily aggregated
low-bandwidth TCP flows and TCP flows with large
delay*bandwith products.

(This is not to say that routers in general (with a few
exceptions) and ciscos in particular have fared much
better at supporting TCP flows with large delay*bandwidth
products, since the amount of buffering available in such
routers is on the puny side. Unfortunately the vendors
(and many others) have had trouble understanding the
relationship between buffering and goodput on
high-bandwidth, high-delay TCP streams through a fabric
that is carrying other traffic).

We also have a number of OC-12c interfaces for our switches. They
appear to work, but we haven't really had a chance to stress them
yet. (Part of the problem is that it is hard to find OC-12c data
sources and sinks.)

I suppose the question is one of objectives: do you want
to move huge flows end-to-end, or do you want to move them
around on ATM? I subscribe to the former, and to the
extent that ATM is currently the only readily available
fabric one can put TCP/IP on at that speed, I support
playing with ATM at that speed. However, should an
alternative come along, I would be very keen on seeing
data move on that too (or instead).

However, there are certainly a large number of people who
would like to follow the second approach: run whatever
data can be run at very high speeds, and run them over
ATM.

I believe that it isn't too much of a stretch to suggest
that there is a cultural gap between the two camps.

The current generation of routers appears unlikely to support OC-12c,
particularly since their backplanes are only about the
same speed.

NFK, and even if they could, good luck getting anywhere
near line rate more than across town if there are multiple
simultaneous TCP flows. :frowning:

(Well, some of the current generation of routers are being
built with appropriate buffering, I gather, and some might
be retrofitted)

On a more theoretical note, switches, being circuit-switched, make
the complicated decisions when the connection is established, (or
configured for PVCs), and need to make relatively simple decisions
to switch each cell.

This is the case in any tag-based switching scheme, even
in lowly ethernet switches. The problem is what to do in
the case of failures, and what the failure modes are in
the first place, and, as you say below:

This probably scales very well is terms of
speed, although at some point might have some difficulty in scaling
to a very large number of simultaneous connections.

But, you also say:

Routers, on the other hand, have to make a bit more complicated
decisions per packet.

which is not always the case, particularly when one begins
thinking of tags as a general abstraction, rather than as
particular varieties like MAC addresses, VPI/VCIs and the
like.

  Sean.