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