Actually I am shocked that this is still going on. All of these technologies are trying to accomplish what ATM accomplished long ago. I find it even more amusing that most of the MPLS networks I have seen or read about use ATM or Frame to get to the MPLS cloud.

With IP, they came up with RTP so that small voice packets could be prioritized. (IP is a 20 byte header instead of ATM's 5 bytes) If a large frame makes it to an interfaces buffer before and RTP packet does then the traffic still has to wait on the buffer to transmit the large frame. Hello Jitter.

Now in MPLS and other protocols they are attempting to build special Asics that will switch frames with connection oriented intelligence and scheduling.

Personally I think that a good carrier would offer the same service the US Military has come to depend on when they do there global combat simulations.

Here is what I would like to see. A carrier with the engineering knowledge to implement a strong ATM network that includes VBR-RT SVC services that not only allow me to make a perfect voice call but let me do a video call too. All of this is done with similar signaling as what they use in the PSTN and zero of the voice and video data inside IP packets, encrypted if you like! Let us get back to real layer 2 transport by the carrier. Then engineers can get back to capacity planning based on circuit usage and not processor load.

If I had that then I could also have:
* a UBR PVC to an internet pop.
* A VBR-NRT PVC for access to the enterprise network

All of these things were available years ago.
Here are a few myths:

*ATM is limited in bandwidth
False ATM interfaces have been tested up to 40Gbit. They could be faster with the development of better Asics.

*ATM has too much overhead
-Well we are adding 20 bytes of overhead for RTP. This is fine for a LAN but why on the WAN?
- MPLS - Here we are doing a 4 byte header but its IP inside there so 20 + 4 is 24 bytes for and RTP packet and we still have no guarantee of delay variation because the MPLS packet is variable length and you can't do statistical time division with variable length frames. IE if a large frame makes it to the interface buffer before the RTP frame you are waiting. On a congested path if that happens on to many successive hops on the path then I notice on my call.

Also, would somebody please tell the marketing department that solutions to problems come from inventors and engineers, not the marketing and sales?