I had a discussion with my manager today and I wanted to run it by you guys to see your thoughts.
We run a Centralized voice environment, we have a site that is setup with LLQ on their edge router, the centralized site also runs LLQ, our provider honors our QOS markings in both directions. This site continues to run over its MPLS port speed, sometimes as much as 500% (most of the traffic is âINâ to the remote site).
Note - all traffic outside of normal pc to pc traffic goes over this MPLS link (internet, email, apps, etc)
My manager's comment was if we had QOS setup "properly" it shouldn't matter if we are bursting above port speed, QOS should be able to see a voice packet come in and send it out before any additional packet? Thoughts?
I said QOS does not solve over utilized circuit issues.
Thoughts and comments are welcome.
if the link is over utilized then there's nothing qos can do to help it and at times can make it worst. depending on how you changet it. if you wanted to you could make your current qos policy a child policy of a policing.
Once again it could make it worse
with QoS and LLQ you can provide better treatment to outbound packets.
But when it deals with incoming packets the router can only try to receive what the network is sending to it.
So voice quality can be good in direction remote site to HQ an HQ listener can hear well and the other side can have a totally different experience.
You should implement at the VoIP level call admission control (CAC) to control the number of concurrent calls between the HQ and the remote site.
if this is done VoIP packets have some hope to be treated better also in the HQ to remote site direction.
That would mean that exceeding traffic is made of data flows.
However, there are some limitations on what QoS can do when the link is so much congested (500%) so in practice even with a correct CAC and LLQ configuration some impairments happen.
Hierarchical QoS with a parent shaper policy at an appropriate rate calling a child policy with LLQ for VOIP and CBWFQ can help but doesn't solve.
Some critical data application may suffer from this heavy congestion.
Hope to help
I don't quite get what you mean by setting up QoS "properly":
If you create an LLQ with a priority queue for the voice traffic, let's say a bandwitdh garantee for 30% of the interface bandwidth, with the "priority percent 30" command (which is the recommended maximum), then your voice traffic will get a 30% guaranteed bandwidth.
Of course, voice traffic will get priority over any other data packets to the extent of the 30% bandwidth.
Voice packets arriving above the 30% bandwidth are dropped (that will deteriorate the voice quality of all existing calls, therefore Call Admission Control exists).
If you fully utililize the 30% guaranteed bandwidth for voice, all other traffic will be able to utilize only the remaining 70 percent of the bandwidth.
This will come with the price of having higher response times for all other (non-voice) applications and a lot of packet drops for those applications when the link is oversubscribed.
You could also consider different compression techniques to reduce the bandwidth requirements for different applications:
For voice traffic: rtp header comression
For data traffic: tcp header compression
But header compression is only efficient when the packet sizes are relatively small.
Before turning to the final solution of increasing link bandwidth, I would inspect the different traffic types that traverse the link:
For example, users may run internet web browsing not related to their job and the business of the company that eats up a significant amout of bandwidth.
That can be handled with proper QoS classification, marking and policing.
Another aspect of the problem may be that transactional applications aren't optimized enough and use a lot more bandwidth than necessary.
Hi Istvan - Thanks for the response. To be clear, the 5 min avg for the LLQ for this int is
Class-map: gold (match-any)
132294716 packets, 25807276130 bytes
5 minute offered rate 56000 bps, drop rate 0 bps
Match: ip dscp af41 (34) af42 (36) af43 (38) cs5 (40) ef (46)
132294712 packets, 25807275628 bytes
5 minute rate 56000 bps
Output Queue: Conversation 264
Bandwidth 1024 (kbps) Burst 25600 (Bytes)
(pkts matched/bytes matched) 6658821/1311932722
(total drops/bytes drops) 0/0
We currently have
configured for this queue.
So out of the 8mb we have purchased only a small portion of this 500% is voice traffic, my netflow server shows 1% of the total bandwidth being EF traffic.
So that bring me to my question of, if I have "reserved" 1mb for my LLQ, how is my voice call affected when we burst to 500%?
If my providers PE router is also setup with 1MB of the LLQ, why is voice still being affected... I'm assuming it's affected because the interface is receiving more than it can handle on (CE router)....
I agree with your manager, if QoS is, indeed, is set up "properly". This also assumes there's sufficent bandwidth for the VoIP traffic.
LLQ, alone, is not always enough, although often a crucial component of a CBWFQ policy supporting VoIP.
Unclear what you mean by being 500% over port speed. Also unclear what you might consider "over utilized circuit issues" and that QoS can not solve them.
BTW, I also read your 2nd post - still unclear what your issue might be - insufficient information.
Thanks for your reply. At the site mentioned we have a DS3, however we have only purchased 8mb of the 45mb.
When I look at our net flow server it shows the in and out consistently running at 500% utilized of the 8mb configured.
So my comment to my manager was, no QOS policy would fix this issue, that a circuit upgrade was necessary (purchasing the entire DS3). If I am wrong could you supply a reason why? Thanks again!
"If I am wrong could you supply a reason why?"
Well, you could shape to 8 Mbps, and manage bandwidth allocations within that limit. That might be one solution; might not too. Still insufficient information to know.
If you (commonly) exceed the 8 Mbps commited rate, what might work or not with QoS depends on how your MPLS vendor treats oversubscription. Some make a major distinction between real-time class, and everything else (some also charge for such differently too).
Much also depends what's on the other end, i.e. whether your remote site also has DS3. Also much depends whether you have more than two sites and if it's possible for multiple sites to send to one site (common with MPLS clouds).
Again, insufficient infomation to truly offer good suggestions. Would need to information on your WAN topology and MPLS provider's service and QoS offering.
A possible example of insufficient information, in your (2nd) post of your CBWFQ policy, I notice you map multiple DSCP tags into the LLQ, but didn't remap these tags. Have no idea how your MPLS vendor processes them or even if they do (not all do by default), but the MPLS providers I've worked with, usually distingish between IP Prec 5 vs. IP Prec 4 (and the DSCP variants).
If you have VoIP quality issues, also keep in mind you need to consider QoS end-to-end. I.e. the problem might not be with your HQ DS3 circuit, per se.