RE: QOS or more bandwidth
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 days ago. They will probably find themselves on the NANOG web site soon, if they are not there already. 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. I hope that helps answer your question about what technologies are needed to improve VOIP sound quality, rather than the interesting ones about directories. Sean.
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.
So, what problem is QoS solving?
QoS is about choosing the packets that you are willing to drop or delay when congestion arises. If you aren't willing to drop/delay any of them, then you must over-provision. Regarding the existant thread, adding engineers and equipment will not give you more bandwidth, but instead it allows you to be more efficient in your packet disposal routines. They are not a substitue for pipe. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
On Tue, 29 May 2001, Pete Kruckenberg wrote:
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.
It has even a larger impact on a 128K frac T1 (~93ms). QoS is a big help, but at slower speeds you also need to deal with fragmentation and the layer 2 transport. I am surprised that there has been so little movement as far as QoS and efficiency in regards to VoIP. Take a standard voice call using G.726 at 32 kbps, you get 40 bytes of voice every 10 ms. Now add on your 20 byte IP header, 8 bytes UDP, and 12 byte RTP header. So now we are at 80 bytes and most of the time we are shoving this on ATM so our 32K voice stream now sucks 84.8 kbps. If you are interested in more info on QoS and Voice/Data over last mine networks check out my website: http://www.robotics.net/papers/integratedvoice.html
<> Nathan Stratton CTO, Exario Networks, Inc. nathan@robotics.net nathan@exario.net http://www.robotics.net http://www.exario.net
On Tue, May 29, 2001 at 03:39:40PM -0400, Nathan Stratton wrote:
On Tue, 29 May 2001, Pete Kruckenberg wrote:
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.
It has even a larger impact on a 128K frac T1 (~93ms). QoS is a big help, but at slower speeds you also need to deal with fragmentation and the layer 2 transport. I am surprised that there has been so little movement as far as QoS and efficiency in regards to VoIP. Take a standard voice call using G.726 at 32 kbps, you get 40 bytes of voice every 10 ms. Now add on your 20 byte IP header, 8 bytes UDP, and 12 byte RTP header. So now we are at 80 bytes and most of the time we are shoving this on ATM so our 32K voice stream now sucks 84.8 kbps.
If you are interested in more info on QoS and Voice/Data over last mine networks check out my website:
Adding control through layering has been something of a pet peeve of mine for quite a while (especially when ATM is involved in the mix and now with MPLS, it just gets a tad worse). As Nathan has demonstrated, usually added overhead just means added headaches. It seems to me that there ought to be better ways to go about this whole thing. -Wayne
On Tue, 29 May 2001, Nathan Stratton wrote:
On Tue, 29 May 2001, Pete Kruckenberg wrote:
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.
It has even a larger impact on a 128K frac T1 (~93ms). QoS is a big help, but at slower speeds you also need to deal with fragmentation and the layer 2 transport. I am surprised that there has been so little movement as far as QoS and efficiency in regards to VoIP. Take a standard voice call using G.726 at 32 kbps, you get 40 bytes of voice every 10 ms. Now add on your 20 byte IP header, 8 bytes UDP, and 12 byte RTP header. So now we are at 80 bytes and most of the time we are shoving this on ATM so our 32K voice stream now sucks 84.8 kbps.
If you are interested in more info on QoS and Voice/Data over last mine networks check out my website:
http://www.robotics.net/papers/integratedvoice.html
<> Nathan Stratton CTO, Exario Networks, Inc. nathan@robotics.net nathan@exario.net http://www.robotics.net http://www.exario.net
On Tue, 29 May 2001, Nathan Stratton wrote:
On Tue, 29 May 2001, Pete Kruckenberg wrote:
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.
It has even a larger impact on a 128K frac T1 (~93ms). QoS is a big help, but at slower speeds you also need to deal with fragmentation and the layer 2 transport. I am surprised that there has been so little movement as far as QoS and efficiency in regards to VoIP. Take a
Because VoIP is mostly being deployed in the enterprise and at the core of the LD network. I am surprised with all of the CLEC's a few years ago who were deploying IP "Soft Switches" that had VoIP capabilities, I don't know of anyone selling VoIP services over DSL (which seem like at least one way to break into the local voice market). Sprint initially focused ION on selling user-configured on-demand residential services over DSL, and were drivers for VoIP improvements at sub-T1 speeds, but I guess that didn't make it (the ION presentation at N+I looked completely unrelated). I'd guess the financial driver for the last mile now is pretty much the phone company (who now also owns the cable company and the competitive phone company as well as the DSL company). I don't see what motivation they would have to run multiple services on the same line, and QoS just doesn't seem to fit in the same phrase as "phone company" (or "cable company"). Biggest driver for the last mile: support your local community network, or start one with your neighbors. Pete.
On Tue, 29 May 2001, Pete Kruckenberg wrote:
I am surprised with all of the CLEC's a few years ago who were deploying IP "Soft Switches" that had VoIP capabilities, I don't know of anyone selling VoIP services over DSL (which seem like at least one way to break into the local voice market).
Well sell it over SDSL with a MOS of 4.8 or better, but we focus mostly on frac T1 and ATM services. They also have limited last mile bandwidth so the same issues need to be dealt with.
Sprint initially focused ION on selling user-configured on-demand residential services over DSL, and were drivers for VoIP improvements at sub-T1 speeds, but I guess that didn't make it (the ION presentation at N+I looked completely unrelated).
I'd guess the financial driver for the last mile now is pretty much the phone company (who now also owns the cable company and the competitive phone company as well as the DSL company). I don't see what motivation they would have to run multiple services on the same line, and QoS just doesn't seem to fit in the same phrase as "phone company" (or "cable company"). Biggest driver for the last mile: support your local community network, or start one with your neighbors.
Sure, for me it is about putting service creation in my users hands. -Nathan
Hi Sorry about the previous (content free :-( ) Email May I suggest reading (and following links from) <http://www.cisco.com/warp/public/788/voice-qos/voip-mlppp.html> (Scanning for "cRTP" & "Interleaving" should be useful) Also you could follow some interesting links from the above URL For Example: <http://www.cisco.com/warp/public/788/pkt-voice-general/bwidth_consume.html> Enjoy Rafi On Tue, 29 May 2001, Nathan Stratton wrote:
On Tue, 29 May 2001, Pete Kruckenberg wrote:
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.
It has even a larger impact on a 128K frac T1 (~93ms). QoS is a big help, but at slower speeds you also need to deal with fragmentation and the layer 2 transport. I am surprised that there has been so little movement as far as QoS and efficiency in regards to VoIP. Take a standard voice call using G.726 at 32 kbps, you get 40 bytes of voice every 10 ms. Now add on your 20 byte IP header, 8 bytes UDP, and 12 byte RTP header. So now we are at 80 bytes and most of the time we are shoving this on ATM so our 32K voice stream now sucks 84.8 kbps.
If you are interested in more info on QoS and Voice/Data over last mine networks check out my website:
http://www.robotics.net/papers/integratedvoice.html
<> Nathan Stratton CTO, Exario Networks, Inc. nathan@robotics.net nathan@exario.net http://www.robotics.net http://www.exario.net
On Tue, 29 May 2001, Rafi Sadowsky wrote:
Hi
Sorry about the previous (content free :-( ) Email May I suggest reading (and following links from)
<http://www.cisco.com/warp/public/788/voice-qos/voip-mlppp.html>
(Scanning for "cRTP" & "Interleaving" should be useful)
Ya, it is funny because cisco was one of the authors of CRTP (RFC 2508) and they don't comply with the RFC on any of their products. CRTP is great, but frankly it does not help at all without other changes. Lets say we have 10 ms sample of G.726 that is 40 bytes + 2 byte CRTP header + 8 byte AAL5, we are still at two cells and just have more space for padding. What I am doing is changing the frame size to odd sizes like 9.5 ms giving me a 38 byte payload + 2 byte CRTP + 8 byte AAL5, fits in one ATM cell. -Nathan
cisco was one of the authors of CRTP (RFC 2508)
<pedantry> the ietf and ietf document authors are individuals, not companies. though, of course, many of the individuals' work is supported by their employers, hence the acknowledgements of affiliation. it's also nice to be alerted to possible bias. i.e. that steve and van worked at cisco did not in any way imply that cisco supported, believed in, would implement, ... </pedantry> randy
participants (7)
-
Eric A. Hall -
Nathan Stratton -
Pete Kruckenberg -
Rafi Sadowsky -
Randy Bush -
smd＠clock.org -
Wayne Bouchard