|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: SONET Interconnect (was RE: MCI)
Tim Bass wrote: >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. Real time applications are about as problematic with any transport method in a public network, period. Bandwidth reservation is nothing more than another name for "higher priority". It works fine until your high priority traffic does not overload the network -- with or without resource reservation of any kind. As soon as that point reached (i.e. network is overloaded) resource-reservation starts to deny service; simple per-packet prioritization starts to drop packets "fairly". That's the real difference. >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. Worse than that, ATM is unable to fulfill its promise of "guaranteed QoS" in global networks. ATM folks didn't appear to understand that all routing stability problems won't disappear just because somebody shreds packets; in fact, it is easily demonstrable that those problems will be worse than with IP. >There is no current architecture to *guarantee* a close to zero >packet loss in the IP world. Moreover, nobody needs it. Packet loss is a necessary component of distributed congestion control, and works better than previously implemented ECN schemes. (That intuitively makes sense, as packet loss removes packets from congested network, while ECN doesn't). >Do we need a real-time protocol that is highly reliable in the >world? The answer, is of course YES. NO. Name the single application which couldn't be run over lossy protocol. >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. Yawn. ATM also loses packets, in a screwy way. It was a way worse since it used to lose _cells_. >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. No, it is simply a bell-head's idea of a data network. If they no longer can shred things to bits they would shred them to cells. --vadim
|