Some random thoughts are collected together here to stimulate a response. Please do respond! The thoughts below were inspired by many, they may change as the project develops. To start, here's a definition, ATM stands for "Annoying Tiny Messages" - at least that was what I was told by the datacomms community (they wanted 4K byte packets). The telephony users probably have a different interpretation (they wanted 64 bit packets).
A public network is what the Telco's provide to people's homes and offices. The basic question concerns whether the technology is for switching in the core between exchanges (i.e. lots of ATM switches building a universal network infrastructure) - or is it alternatively a service which is provided at some point in the core (i.e. a few ATM switches connected by PDH/SDH links). There is little chance of a "universal" ATM network for a long time, in the mean-time, ATM will be provided on top of the "normal" technology as a network service. For a public network, compatability between different manufacturers is not a key issue - most will buy from just one or two manufacturers.
There is still the question who needs ATM - the Telco's would presumably raise income from selling an ATM network service, and would save money and gain flexibility in the long-term for voice traffic when they adopt an ATM core. If a public ATM network exists, and if a satisfactory access agreement could be arranged for individual users (there remains the key issues of service agreement and interface policing), then someone will have to work out how to "sell cells" (i.e. to explain that you'll still be charged even when your data packet was never received!) The cost of using the new public networks could prevent users experimenting, and hinder the development of new applications. Using the Internet as an example, should this service be free? (Write to your local Telco.)
The ATM technology may be seen simply as the successor to X.25, Frame Relay, PPP, etc - as a means of providing connectivity between remote routers. In essence, this is "cell shuffling" - a kind of super IP. A key issue here is support for switched virtual circuits, and automatic routing. The issue of compatability between products may also be key in the construction of private networks.
There are a number of different devices with different features. Some switches support cell duplication (multicast) - this is a cool idea. But is ATM more than simply a next generation HDLC? How much of ATM is actually required to satisfy the backbone need? Does anyone provide a routed ATM network - or is bridging still being advocated? - Some routed solutions are out there.
Key issues to consider when you start using wide area links are:
An importnat consideration here is "is ATM really needed to do this?". As line speeds increase above the few hundred kilobit range, the blocking time when serialising a packet becomes less significant. From a packet service point of view, there will always be a variation in the round trip time across the network, and anyway, there's likely to be one in the host end systems anyway. (van Jacobson suggests you should build the applications protocols with this in mind, and not worry about it too much in the network, I can see his point!) So, couldn't we build routers which provide quality of service support? - The answer is yes, and there is a team at Aberdeen doing just this (As there probably is elsewhere, let me know if you are interested in this too!!)
The LAN has become the most fundamental component in most computing environments - the limited bandwidth of current LAN technology has finally become significant (at least to some users). The future of ATM in this area is however not clear. LAN traffic profiles change quickly, bandwidth is cheap, administration poor, and the whole technology becomes cost- driven (providing it is simple to deploy!). ATM is not the only high speed LAN technology, the competition from FDDI, and (more likely) from 100 Mbps Fast Ethernet (100 base VG or 100 base anylan) is at least as likely to succeed. There is also HIPPI, if you prefer a high speed bus. The high speed LAN is a potential source of data for ATM networks, even if it is not itself an ATM LAN.
Most current LANs are connectionless, ATM is not. Who sets up the ATM connections for the LAN traffic? A direct approach says it is the router or the host, the indirect approach relies upon a connectionless server in the ATM network. Which is best is the source of much argument. There are many other problems - errors in IP are assumed to arise from congestion - not so in ATM using AAL - they may be a result of statistical loss. Does this matter? The datacomms people seem to be worried. There may also be a need for some new higher speed transport protocols - although the latest news from the TCP community is that they may think TCP is fast enough!
Do we need to find a future (killer) application to utilise the ATM network? Quite what the "killer application" will be is not known - just as the original use of the arpanet was for "remote supercomputer access" - if we wait, the application will be developed by someone. Most LAN applications were invented by users, not standards committees, or service providers! This can mean that a new application can łgrow overnight˛.
There is a problem if we wish to exploit the real advantages of ATM. ATM provides a bounded transit delay and the ability to reserve (without committing to use) bandwidth, but to take advantage of these we may need new operating system features. Current operating systems have evolved to handle the IP protocol stack, - the data flow is not real-time, but the applications are not real-time either. Even packet video requires a slow response time compared to potential ATM applications. We may need a new generation of operating systems to work with ATM links.
There is a market for cable TV, there is likely to be a market for pay as you view TV, maybe even interactive TV, perhaps (who knows?) for multimedia home shopping, even for remote virtual reality? Cost is a key issue. While this fits well into ATM, there are other equally good ways of moving this type of data around.
So what does this mean? Is ATM a future-proof way of connecting networks? (How future- proof was the OSI applications stack?) How long will the standards take to stabilise???? (5 years?) Will the algorithms of ATM be (totally) public domain - or will there be significant inside knowledge required (aka X.25)? When the universal ATM network is finally adopted all this will (of course) be history and very obvious.