Paul,
I'm sure there's some good stuff in you response but I'm going to have to go back and read it in detail later. I do however want to get clear on one thing before I do.
If we're talking about making a case for ATM in the LAN, we are in complete agreement! ATM will never succeed in the LAN. I think this has been decided already. However ATM in the WAN...that's clearly going to stick and will be huge. Do we agree here?
Also, about vendors building multiservice IP products.. True many vendors have this "stuff". However none of these products compare in quality to what ATM can deliver today. In the short term we'll see this technology (voice on IP) work well in leased line environments, but putting voice, video and IP over an IP backbone...that's years away since infrastructure will have to be upgraded to support RSVP and WFQ to build in the queuing archectures. Are we agreed here?
I'm simply searching for a starting place for this discussion.
Looking forward to your response.
Gary
Oh... I'm sure this was a typo..but for clarification...
>>ATM is connectionless:
>>ATM only has a CRC bit in each cell as an acknowledgment that there >>is a problem with the cell. All traffic following will continue to >>flow. It is the responsibility of the reciever/sender (the >>application) to detect this, and re-send the data.
ATM is Connection oriented...Not connection-less. IP is connection-less. That is, it does not need a connection (VC) to be pre-determined. Frame relay is also connection oriented. These technologies came about because end points had error correction built into them. Since this was the case it made no sense to have error correction in the network. This took time and performance (the reasons you cited for not fragmenting traffic). In order to provide better network performance, and given that the network was digital (not old barbed wire copper of the pre-70's) error-correction was eliminated in the infrastructure and relegated to the end points and higher layer protocols. So, my response about traffic management didn't specifically address your first issue. But, cell loss usually happens because of bad traffic management (buffers getting filled), not because of packet loss, bad CRC, etc.. This just doesn't happen often enough anymore (in the states) where the overhead is worth worrying about... That's why error correction was removed. Comparing the overhead of error correcting each frame versus the overhead of re-sending a lost frame every so often weighed in favor of not error correcting. This decision was made over 10 years ago. Are you suggesting we go back to this technology and error correct and check each packet as it winds its way through the bacbone? Can you imagine a voice call going through the internet given the response times we all experience?
Gary |
