On Tue, 29 May 2001, Sean M. Doran wrote:
Pete Kruckenberg <pete@kruckenberg.com> writes:
| The VoIP QoS problem is interesting. Barring congestion in | the network, VoIP just has a problem with the fact that IP | communications are frame-oriented (and a VoIP packet gets | behind a 1536-byte Ethernet frame in the transmit queue).
You *really* want to study Peter Lothberg's excellent queue graphs in his presentation to the Phoenix NANOG a few
Yes, been waiting...
Speaking of Peter, I often get calls from him which start off with, "you know, Voice Over IP doesn't work without ATM, RSVP, QoS, LAN emulation, MPLS, traffic engineering, and fancy queueing!". It's how I know it's him, when he's making a VOIP call through MAE-EAST, since the connection is much too _clear_ to tell by listening alone.
His presentation, and Steve Casner's provided empirical evidence that there is no QoS problem to be solved, at least in the core. Which raises another (perhaps rhetorical) question, back to Sean Donelan's original question: is the value/importance of QoS inversely proportional to ability to obtain more bandwidth (ie if funding for new bandwidth is less, is QoS more important now). (Most of the arguments in this thread have focused on using more bandwidth to remove the problem that QoS might solve.) So, what problem is QoS solving? Is QoS about ensuring that higher-margin ("differentiated") products like VPN's aren't impacted as much by congestion? Is it about reducing the impact and visibility of congestion (a la WRED, and making ICMP and Keynote measurements 'priority' services).
I hope that helps answer your question about what technologies are needed to improve VOIP sound quality, rather than the interesting ones about directories.
A 1536-byte frame has a fairly significant impact (~8ms) at 1.5Mb/s. QoS appears to have diminishing return as you move beyond 45Mbps, at least as far as multi-service networks go. Maybe QoS isn't necessary or useful in the core if you have line-speed switching and no congestion on an OC-X/DWDM network. But the multi-service traffic has to originate/terminate somewhere, and it's not likely to be much faster than 2Mb/s in most cases, at least not for a while (my 64k ISDN line is more than adequate for email, as long as my calendar app doesn't decide to re-sync). There were two presentations at NANOG Phoenix showing that there isn't a problem (as far as packet loss, jitter or latency) in the core. It'd be interesting to see similar studies at the distribution/access layers, where things get a lot more interesting QoS-wise. Interesting that there is a lot of vendor focus on QoS in the core, where it seems to make much less sense than at the edge. Pete.