<snip>

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.

I'd wonder if a large part of the problems are not avoidable, but that since most persons do not as yet have a "feel" for ATM, its harder to see and diagnose building problems, or predict failure points. ATM acting like TDM *still* isn't TDM. "Load" testing is fine and well (sorry DISA folks) but it's the field use that matures technology and turns proposed process into good technique. We've watched the ATM simulations (and even helped with the code for a few) but nothing came close to predicting what happened in real life when clients implemented it, especially in the multimedia (IP/TV/VOICE) applications. -v