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