Gentlemen, I was reading this thread with interest and perhaps I have missed something...... but here is what comes to mind; As pointed out by Zhang et. al. in the late 80's, real-time applications over a store-and-forward datagram service is very problematic because IP is a best-effort service and there are no bandwidth/delay guarantees in the IP paradigm. ST-II build another unreliable service (with a smaller IPv5 header) and created an odd-ball, no tool set, ST/SCMP paradigm that continues to be unreliable without addition transport services. Hence, the goal of a real-time QoS for datagrams over a routed topology was not reached. RSVP, building with lessons learned from ST-II and the added IP feature of interdomain multicasting, has a better chance to survive and to become accepted on a wider scale because it is built on IPv4 with existing IPv4 tools and toolsets. But never-the-less RSVP cannot guarantee packet delivery and completely reliable real-time services. Resource reservation does *not* guarantee a time-critical packet arrives from source to sink and requires a transport protocol (like TCP or some other flow control). Therefore, for applications where packet loss is acceptable, RSVP works; but in a real-time distributed internetwork where data MUST be delivered within a specific QoS, RSVP hold little real promise. On the other hand, for many applications of datagram voice and video, packet losses are acceptable so RSVP/IP is acceptable as well. On the other hand, ATM (based on the original ATM charter) was envisioned to offer a guaranteed QoS. As pointed out by numerous people in this thread and before, IP/ATM is not efficient; and it is for this reason and others that many IP protagonists love to bash ATM, and with good reason from an IP perspective. But, will all the cross fire and debate raging and the ATM - IP debate raging the fact remains: There is no current architecture to *guarantee* a close to zero packet loss in the IP world. Do we need a real-time protocol that is highly reliable in the world? The answer, is of course YES. Will a datagram service ever provide the .99999++++ delivery service required by distributed, network based real-time systems? Maybe. But IP based solutions alone will more-than-likely not solve the problem. Finally, as pointed out TCP/IP/ATM is not efficient. On the other hand, transmitting packets, losing them in the network and retransmitting them or just dropping packets from the stream is not the most efficient method of delivery either. Highly efficient, guaranteed packet delivery services with a close to zero packet loss is an oxymoron and does not exist and will not exist with RSVP (but will help but not to .99+++ as required by real-time network services). On the other hand, it is possible that a transport technology that can deliver a guaranteed QoS under IP will work, perhaps inefficiently, but it can deliver real-time data. I am not necessarily a protagonist for ATM, and my personal opinion is that ATM is too complex and tries to be all things to everyone, and that rarely if ever works. But, there are real-time applications where unreliable datagrams with heavy transport protocol overheads similar to TCP/IP are undesirable as well; and this paradigm is not so efficient either. Best Regards, Tim postscript: The reader is invited to read and comment on a draft paper http://www.silkroad.com/working/stii-rsvp.ps related to this subject (but not addressing the ATM issue). +------------------------------------------------------------------------+ | Tim Bass | | | Principal Network Systems Engineer | "... the fates of men are bonded | | The Silk Road Group, Ltd. | one to the other by the cement | | | of wisdom." | | http://www.silkroad.com/ | Milan Kundera | | | | +------------------------------------------------------------------------+