Doing ASA Quality of Service (QOS) on DSL or Cable Internet

PROBLEM

Needed a way to help improve the QOS on our Cisco IP Phones (we use mainly 7940 / 7941 and 7960 / 7961 phones). On our WAN there is no problem as it is all controlled via our own routers and our VOIP provider's routers which we have direct T1's with.  Our Cisco Call Manager is hosted by a VOIP solution provider, the equipment is not at our site (not that it really matters). 

So the problems were at our small remote project sites which usually only have DSL or Cable Internet connections to the internet (not direct to our VOIP provider).  We know and fully understand that we really can't control QOS over the internet but the IP Phones have worked out pretty well in the past with out it.  However, recently these sites have been doing a lot more paperless work which is taking up a lot more outbound bandwidth because of scanning documents and uploading to a project web-site with a document repository.  Whenever someone was scanning documents (which uploaded to an off-site server) the phone quality went down the tubes.  This is mostly noticed by the person on the other (remote) end, not the employee at the project site.  

WHAT TO DO?

We've been replacing PIX 501's with Cisco ASA 5505's as you can't do QOS on a PIX.  However, simply adding the basic QOS commands to the ASA doesn't do the trick.  The problem is that the ASA has a 100MB connection to the DSL router and as far as the ASA is concerned there is no congestion and pushes out the data as fast as it can and never really priorities anything.  Now when the DSL router starts pushing the data up its tiny 1MB pipe, that's where the choppy audio starts.  So what we needed to do was to tell the ASA what the actual available bandwidth was so it could properly "throttle" and packets and properly prioritize the VOIP packets. 

We still have no control over what the vendor provided DSL router (or cable modem, etc.) does with the packets after they leave the ASA, but it does help. With the ASA knowing the speed limit, it can tell the lower priority traffic "whoa... slowdown fellas!", leaving upload bandwidth available for VOIP traffic. 

The main disadvantage is that some available outbound bandwidth may be wasted as we are basically setting it aside for VOIP.  If we have 1MB available from our ISP but we restrict non-VOIP traffic to 600MB, that is the best upload speed available, even if there is no VOIP call in progress.  

SOLUTION

Okay, here are the magic commands.  The only thing you will really need to tweak is the SHAPE AVERAGE value.  The value I have below is for 600K.  This should not be set to your available DSL upload speed, it should be set to how much bandwidth you want to give to lower priority traffic.  It may take a good hour of your time testing different values until you get the results you want.  Make a VOIP call, then start an upload, listen for jitter or watch the stats on the up-stream phone for dropped packets, jitter, and call quality if possible.

This example is doing traffic Shaping vs. Policing.  Shaping seemed to work better.  Policing is similar but allowed low priority traffic to burst for 10 seconds which caused jitter during that time.  

priority-queue outside        Creates the priority queue

!

class-map VOIP-TRAFFIC     defines a class map to match VOIP (EF) traffic

 match dscp ef

policy-map PRIORITY-POLICY     The policy for priority traffic (in this case VOIP based on the class map)

 class VOIP-TRAFFIC

  priority

policy-map QOS-TRAFFIC-OUT        The actual policy map that gets applied to the interfaces and uses the stuff we just defined

 class class-default                                Default traffic policy

  shape average 600000                    Default traffic conforms to this value

  service-policy PRIORITY-POLICY    Exception to the default policy (in this case VOIP traffic which will have no limit)

!

service-policy QOS-TRAFFIC-OUT interface outside    actually applies it to the interface (remove this to test with and without QOS).

You can get a lot more complex with this, giving FTP traffic more or even less bandwidth for example, but this does the trick to prioritize VIOP traffic and restrict everything else.  This example does not discuss prioritizing via a VPN, this could be done also but is not what we wanted to do.

For more detailed info check out: http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_tech_note09186a008084de0c.shtml

WHAT ABOUT INBOUND TRAFFIC

Yes, you can throttle inbound also but it doesn't help very much and probably isn't worth it.  You actually can't do Shaping on outbound and inbound at the same time, but you could do policing (i.e. Police Outbound 6000000 within a CLASS).  I played with it, cutting the bandwidth in half even, but it didn't do much.  It may have helped just slightly but the loss of available download bandwidth wasn't worth it.  The problem really lies in the fact the packets coming down have already traversed the slow link, so once it hits the ASA it is really too late and VOIP prioritization doesn't do much.  I think the slight improvement was only because it caused the download I was doing (for testing) to come down slower, but it didn't give the results I wanted.  So for me, I'm just doing outbound (upload) QOS and that is where the main problem was anyhow.