The technical description of the two methods is rather lengthy and involved, but I will attempt to simplify it here to explain the basic differences. I'm going to use an analogy. Pretend you have to send 1,000 people going from Washington, D.C. to Philadelphia, Pennsylvania. Those people will be our data, and we have a choice of TCP/IP or ATM.
ATM (Asynchronous Transfer Mode) can be compared to an infinitely long train that is continually traveling from D.C. to Philadelphia. The cars hold a certain number of passengers, and as one car fills up, your people (data) get into the next available one. The train never stops, the people get on as it moves, and step off the same way. Since some of these passengers are more important than others (carrying voice or video), ATM allows them to cut the line and get right on the train. The rest of the data passengers just have to wait.
TCP/IP (Tranfer Control Protocol/Internet Protocol) is more freewheeling. Instead of sending your 1,000 people on that train, you decide you want to use TCP/IP. To do this, they are broken up into groups (called packets) and sent on their merry way to Philadelphia. How do they find which way to go? Well, each group will go to a router, which will look at the address they are heading to, and will give them directions.
One of the problems we encounter with sending our people this way is we have to make sure they made it. To handle this, the TCP (Transfer Control Protocol) is constantly checking to make sure each group makes it. If one doesn't, they are sent again (pretend we can regenerate those people). The next problem is that these people aren't going to arrive at the same time. Not only that, they have to share the different routes with others, and by default there is no prioritization. So, if these people are carrying voice or video, there can be problems (such as speed issues) on the other end.
To solve this, there is software available for networks that allow prioritization of voice and video. Fool community member Scott (who works in this industry) adds this: "Quality of Service (QoS) guarantees are being added to TCP/IP (where they currently exist, and are becoming enhanced) in order to help prioritize data on the network."
However, I've been told (in my discussion with Williams Communications) that ATM provides greater flexibility. Since TCP/IP provides a number of different routes to travel, there is contention that this method allows better efficiency in the network. There is a lot of disagreement among people I've spoken to in the industry. However, most agree that ATM will be around for a long time.
Let me quote directly from Fool Scott again: "The one main benefit of ATM over TCP/IP is that ATM has full control of the data flow from the lower-layers up through the upper-layers. TCP/IP on the other hand is simply an upper layer protocol, which is somewhat constrained by its lack of control over its lower-layer providers (Ethernet, token ring, FDDI, etc)."
I'd like to thank Scott, and another Fool in this business (who asked to remain in the background) for reviewing this, and giving me their comments. Yesterday, I received my Newton's Telecom Dictionary by Harry Newton, and another interesting book: Making the Cisco Connection by David Bunnell. I just scanned Newton's, but in a short while I made it through one quarter of the Cisco book. That's because it is an easy read (And I was supposed to be getting ready to go to Korea! I always seem to do other things when I have less fun tasks ahead -- my wife could tell when I had a paper due for graduate school, because I'd start cleaning the kitchen floor). Anyway, Cisco Connection, gives a very good background on the development of networking and is worth reading.
I'll be in Korea for the next two weeks, but I'll still be on the discussion boards, and my column will be sent from over there. To discuss this column, please visit those boards linked below. Until next week, stay Foolish!