cancel
Showing results for 
Search instead for 
Did you mean: 
Create Post

How do you handle QoS for your VoIP environment?

Level 11

Let's face it, you cannot talk about VoIP without hearing about QoS (Quality of Service) for many companies a VoIP deployment is the only reason they implement QoS. After I think about it for a while, I realize 90% of the companies I've deployed QoS for/at were in preparation for or to improve a previous voice deployment. The first question I used to get is 'Why do I need to deploy QoS? I have 1Gb links that's more than enough bandwidth, well let's go back to basics. In my mind voice is a pretty stable and timid IP stream it’s the rest of the non-VoIP IP traffic that is bursty and rude so from my perspective it's not always a case of managing low-bandwidth links for VoIP traffic, it's a matter of protecting the VoIP RTP streams from all the other day-to-day data traffic. Plus, we also have to consider not every company can afford 1Gb+ private WAN links at every site, so in that case it does become a matter of reserving bandwidth for VoIP traffic.

QoS is definitely one of my favorite topics to discuss & design for, especially because it's one of the topics that every company does differently and they usually have different goals for the QoS implementation.  I'll kick it off with a few points I like to mention out of the gate.

Don't queue TCP & UDP traffic together! This is definitely one of my favorites, I've seen many people out there lump up a bunch of applications together and throw them in a single queue, it sounds like a good idea but remember how TCP & UDP fundamentally behave when packet loss occurs. If the congestion avoidance mechanisms (RED/WRED) kick in and a UDP packet is dropped the flow continues like nothing happened. Where-as if a TCP packet is dropped the stream decreasing the window size and less data gets transferred over time until the endpoints negotiate the window size back up to where it was. You might find yourself in a situation where TCP throughput is suffering but the UDP applications function like normal because they have essentially taken up the whole queue. This is a rather tough situation to troubleshoot.

Get Sign-off from Management - This may sound odd or trivial at first but it is usually best to work with the business (was that layer 8 or 9 again I always confuse those two?) to determine what traffic allows the company to bring in the money. You also might want to take that a step further and ask that same management/business team to put a priority on those business applications, so they can decide which applications can/should be dropped first if bandwidth is not sufficient. After all, the last thing you want to do is explain to your own management or business teams why you are dropping business critical traffic. It is a good idea to make sure they are standing behind your QoS configuration.

Trust boundaries - Deciding where you place your trust boundary can change your configuration & design drastically, after all if you decide to place your trust boundary on a sites edge/WAN router then you only need to worry about the queuing outbound on the WAN and the inbound markings. However if you setup your trust boundary on your access switches then you may also need to consider layer 2 QoS mechanisms and the queuing from the layer 2 device to the upstream layer 3 WAN router. 


Trust Boundary.PNG

Those are a few considerations I take into account when working with a QoS, what else do you consider for deploying QoS in your environment?

30 Comments
Level 9

I let Cisco do it for me.

auto qos voip cisco-phone

Level 11

Sometimes the easy way is the best way. Auto-QoS takes care of a good portion of the leg work from a layer-2 perspective.

MVP
MVP

when we started these discussions with our vendor, it all started with the mentality of ensuring that voice quality was maintained.

still really only putting toes to the water with a limited start.

Level 12

We tried autoconfiguration with CenturyLink and they ended up leaving it at default... 5 - 95 I think it was.

Level 12

I find that even with the bigger vendors QoS is not a strongsuit for most pre-sales guys and even a lot of the techs aren't very competent with it.  You have to find someone who specializes and then dig in to find out what your and their systems require.  Often they will say something like "go 40-20-20-20" and then won't explain why that specific configuration is best (it may or may not be).  That doesn't even include your template type which determines what happens when you reach a limit.  It can be a sticky mess when you first jump into it.  We had one site that had a template and ratios set which shot the standard ping from 23ms to 250+ms by applying the settings (no bueno). Live and learn.

Level 13

We had to coordinate this with our circuit vendor (multi-site cloud). We have a default configuration for typical sites and tweak on a per-site basis for unique scenarios.

Level 14

You have to take into account the links that you are going across.  Especially if there are small WAN links and there are no local call managers or gatekeepers.  You also need to calculate what is needed for optimal performance based on the codec and which protocols are being used (SIP, H.323, MGCP, or SKINNY).

Level 12

Good point about the WAN links.  I believe that was part of the issue I was talking about above.  I think it was partially a saturation issue when you got more than a few people working and phoning from that site.

Level 14

I am sure it was.  There is usually no one size fits all approach when dealing with multiple sites and WAN links.  It should be a site by site basis, of course based on site surveys (flow collection data and montoring VoIP P+Ps is a good idea for "real" data) and the "high end" needs of the site with at least room for 25% growth. 

Level 11

Bookmarking for later.

Our QoS implementation is rather complicated (from my perspective; though I'll admit I'm a little new to the idea of QoS), but it seems to do well.

Level 17

Most of what I see is Auto. We have some queuing built in, but while I have never deployed QoS I would know not where to start with the priorities.

Level 11

Been following this discussion.  Again, not a VoiP guy so my participation (currently) is simply letting Cisco do the work for me and getting things in their correct voice vlan. 

Level 11

As long as voice quality is maintained, and the bandwidth is sufficient for the rest traffic sometimes that is all you need.

Level 11

Your statement is so true, many people usually just 'guess' at some good values to base a QoS. Without even looking at something like NetFlow statistics to get a feel for the type and amount of that type traffic that flows through their network to plan queues accordingly. NetFlow can be one of the most useful tools with designing a QoS policy.

The ping response time is also a great call-out. I've seen situations where people have assigned assigned ICMP to their own queue and operated under the false assumption that since ping response time was good the site was performing well, when in reality the ICMP queue when setting false assumptions.

It's interesting how QoS can change the perspective one takes in basic troubleshooting.

Level 11

Very true, since each codec has different bandwidth requirements you must plan your Voice queue accordingly.

Level 11

With a piece-meal deployment, just make sure you mark & queue along the entire path during each phase. Marking and queuing in one part of the network but not the other may negate your prioritization.

Level 11

Good call out there, you can have the perfect marking and queuing policies on your CE equipment but unless the WAN provider is honoring those markings properly it was all nothing. WAN transport is a very important aspect of a good QoS design.

Level 11

Another great call out there Christopher Good many of the larger vendors out there like Cisco provide SNMP access for monitoring queuing class-maps for drops, and NetFlow is a commonly overlooked tool for QoS planning.

Level 12

cisco does the bulk of this for us but we use VNQM to monitor the VoIP

MVP
MVP

I am also not a QoS or VoIP guy.  I know QoS is set up here since we have a large amount of voice traffic to coincide with data.

This is all handled by the network team...so it's out of sight but not forgotten as I know it's there.

I like the thought of queuing TCP and UDP seperately.  I'll need to research that more....

Level 11

We are just getting into VoIP and we let Cisco handle most of the QoS for us. We just downloaded an eval of the VNQM to monitor the phones we just installed. So far we are really impressed.

Level 11

Don't have much opportunity to get into the weeds of this subject, but the information is always good.

Level 9

Never have stopped to think about what you mention about TCP and UDP when doing QoS, but definitely a great tip that will be very useful next time I set that up. Thanks man!

MVP
MVP

I take all the above into consideration. The thing that is equally important but hasn't been mentioned yet is that if you're using a software based VoIP solution or server helper then you need to make sure that the Server is configured with QoS as well. Remember to create QoS policies in Windows with the correct DSCPs as suggested by the vendor. This is especially crucial if you're using something like Lync.

Level 11

Very trueDeltona there are those times when you may need to trust the marking from end-devices.

You are definitely correct about MS Lync, I've seen way more Lync deployments in the enterprise than soft-phone software running as desktop applications.

Level 11

Entertaining posts, thanks.

Level 12

very entertaining indeed.

Level 10

Often i do the same

Level 9

Good info for future use!

Level 15

Not in an environment that is using VOIP at this time but this is good reference material for the future.