LLQ and WFQ

saimbt · ‎04-01-2008

Hi Gurus,

I need help. My scenario is as follows, On my corporate network VoIP, Video COnf and data flows. I need to ensure that during congstion VoIP and VC is not affected.

I am planning to allocate priority to VoIP traffic by assigning priority percent. I am planning to allocated 384 Kbps to VC traffic and all other traffic is best effort.

Is this right? Moreover I would like to know the difference between priority percent and bandwidth percent.

-Sai.

mheusing · ‎04-02-2008

Hi,

The queueing mechanisms and differences between "priority percent" (LLQ) and "bandwidth percent" (CBWFQ) are explained in great detail in the congestion management section of the "Cisco IOS Quality of Service Solutions Configuration Guide".

http://cisco.com/en/US/docs/ios/12_2/qos/configuration/guide/qcfconmg_ps6350_TSD_Products_Configuration_Guide_Chapter.html

In principle your approach seems correct, but it is hard to give a definitive comment based on the information given. We do not know anything about your video conferencing system, all involved hardware including all LAN switches, bandwidths and protocols in the WAN, type of routers, etc.

I would recommend you to read the "Enterprise QoS Solution Reference Network Design Guide Version 3.3"

http://www.cisco.com/application/pdf/en/us/guest/netsol/ns432/c649/ccmigration_09186a008049b062.pdf

This document gives you recommendations and configuration examples for different scenarios and platforms. Please note that for QoS the end-to-end behaviour counts, which means LAN switches and routers need to be configured properly. Routers alone will not be sufficient in many cases, especially for voip. Based on the SRND you will the be able to create configurations for your LAN switches and routers.

Hope this helps! Please use the rating system.

Regards, Martin

Joseph W. Doherty · ‎04-02-2008

"Moreover I would like to know the difference between priority percent and bandwidth percent."

"priority percent" sets a cap on bandwidth usage. When there's congestion any traffic that exceeds the cap will be discarded. All traffic within/under the cap will be sent next.

"bandwidth percent" sets a minimum amount of bandwidth. The class may obtain more if it's available. When more traffic is offered then the class minimum, and excess bandwidth is not available for it, it is queued.

The norm for VoIP is priority classification. However, don't forget you might need to also treat voice signaling as special too.

For video conferencing, I prefer priority for it too, but it sometimes will work, not too badly, within a normal class. Amount of bandwidth is dependent on the VC device. Video is often very bursty in bandwidth demands. The latter addressed by either setting more bandwidth for the class than the "average" and/or increase queue depth. The former, setting more bandwidth then "required", also avoids transient queuing delays. (Remember unused bandwidth, regardless of what's configured, is still available to other traffic. What's important is to avoid delays or drops of your real-time traffic.)

saimbt · ‎04-02-2008

Sample config

class-map match-all Voice

match ip dscp ef

class-map match-all Interactive Video

match ip dscp af41 af42

class-map match-any Call Signaling

match ip dscp af31

policy-map WAN-EDGE

class Voice

priority percent

class Interactive Video

priority percent

class Call Signaling

bandwidth percent 5

All other traffic is Best Effort

-Sai.

Joseph W. Doherty · ‎04-02-2008

Should work for starters (assuming traffic has the expected DSCP markings).