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