QoS isn't necessarily about throwing packets away. It is more like making voice packets 'go to the head of the line'. Of course, if you have saturation, some packets will get dropped, but at least the voice packets won't get dropped since they were prioritized higher. Ray Burkholder
-----Original Message----- From: Bill Woodcock [mailto:woody@pch.net] Sent: February 10, 2003 14:05 To: Charles Youse Cc: nanog@nanog.org Subject: RE: VoIP QOS best practices
> That doesn't seem to make a lot of sense - is it that QoS doesn't work as advertised?
That's generally true as well. But why would you need it? What's the advantage to be gained in using QoS to throw away packets, when the packets don't need to be thrown away?
> As someone who is looking to deploy VoIP in the near future this is of particular interest.
Go ahead and deploy it. It's easy and works well. It certainly doesn't need anything like QoS to make it work.
-Bill
> QoS isn't necessarily about throwing packets away. It is more like > making voice packets 'go to the head of the line'. Of course, if you > have saturation, some packets will get dropped, but at least the voice > packets won't get dropped since they were prioritized higher. Why bother? It's a pain in the ass, and doesn't give any noticable benefit. -Bill
On Mon, Feb 10, 2003 at 10:34:14AM -0800, Bill Woodcock wrote:
> QoS isn't necessarily about throwing packets away. It is more like > making voice packets 'go to the head of the line'. Of course, if you > have saturation, some packets will get dropped, but at least the voice > packets won't get dropped since they were prioritized higher.
Why bother? It's a pain in the ass, and doesn't give any noticable benefit.
So QoS on the access link can do two things: - Reduce jitter on selected packets (by moving them to the head of the queue) - Reduce packet loss on selected packets (by preferentially dropping non-selected packets, _if_ there is congestion). So, has anyone done measurements to see if either of these makes a difference in the real world? IP phones have jitter buffers to reduce the effects of jitter. Does reducing packet jitter make a noticable difference? VoIP can withstand a small amount of packet loss without too much loss of quality. Does normal TCP backoff keep the UDP packet loss low enough in the event of congestions? It seems that Bill's experience with a real-world deployment indicates that, _subjectively_, percieved quality without QoS is "good enough". Anyone have real counter-examples, or real measurements? Steve
On Mon, 10 Feb 2003, Ray Burkholder wrote:
QoS isn't necessarily about throwing packets away. It is more like making voice packets 'go to the head of the line'. Of course, if you have saturation, some packets will get dropped, but at least the voice packets won't get dropped since they were prioritized higher.
Thats what I meant too... To qualify further on where it needs to be deployed, its required on whatever the slowest link in the typical path to "the Internet". What I mean is that if you download your email you will utilise the whole bandwidth of the slowest link in the chain, this may be a dialup modem but more likely in the office to be your T1, you dont want this full utilisation of the link (which will occur in small bursts of a few seconds, dont forget with voice we are interested in per second traffic volumes not 5 minute averages!) to affect the jitter you need to implement priorities at this point. Steve
Ray Burkholder
-----Original Message----- From: Bill Woodcock [mailto:woody@pch.net] Sent: February 10, 2003 14:05 To: Charles Youse Cc: nanog@nanog.org Subject: RE: VoIP QOS best practices
> That doesn't seem to make a lot of sense - is it that QoS doesn't work as advertised?
That's generally true as well. But why would you need it? What's the advantage to be gained in using QoS to throw away packets, when the packets don't need to be thrown away?
> As someone who is looking to deploy VoIP in the near future this is of particular interest.
Go ahead and deploy it. It's easy and works well. It certainly doesn't need anything like QoS to make it work.
-Bill
participants (4)
-
Bill Woodcock -
Ray Burkholder -
Stephen J. Wilcox -
Steve Feldman