Quality of Service, Part 10 – Weighted Fair Queuing

Last time we looked at First-In First-Out queue management, in this blog we'll explore the next queue mechanism on our list: Weighted Fair Queuing (WFQ). WFQ is a flow-based queuing algorithm used in Quality of Service (QoS) that does two things simultaneously: It schedules interactive traffic to the front of the queue to reduce response time, and it fairly shares the remaining bandwidth between high bandwidth flows. A stream of packets within a single session of a single application is known as flow or conversation. WFQ is a flow-based method that sends packets over the network and ensures packet transmission efficiency which is critical to the interactive traffic. This method automatically stabilizes network congestion between individual packet transmission flows. There are three types of WFQ:

• Flow based Weighted Fair Queuing
• VIP distributed Weighted Fair Queuing
• Class based Weighted Fair Queuing

The WFQ method has the advantage of being fast, reliable and easy to implement. WFQ follows these main criteria:

• Dedicated queues for each flow (referred to as conversations), messages are sorted into conversations reducing starvation, delay, and jitter within the queue.
• Allocating bandwidth fairly and accurately among all flows, reducing scheduling delay and guaranteeing service.
• IP Precedence is used as weight when allocating bandwidth.

Although bandwidth is allocated fairly among all flows, unfairness is reinstated by giving proportionately more bandwidth to flows with higher IP precedence or lower weight. WFQ has to classify individual flows using the following information taken from the IP/TCP/UDP headers. These parameters are used as input for a hash algorithm that produces a fixed length number that is used as the index of the queue.

• Source IP address
• Destination IP address
• Protocol number to identify TCP or UDP
• Type of service field
• Source TCP/UDP port number
• Destination TCP/UDP port number

There is a fixed number of per flow queues, and the hash algorithm translates flow parameters into a queue number. The number of dynamically allocated queues is based on the interface bandwidth configuration and can be configured in a range between 16 and 4096 in multiples of 2. Here is a list of default dynamic queues based on bandwidth.

WFQ Insertion and Drop Policy WFQ uses two methods to drop packets, Early and Aggressive dropping. Early dropping is when the congestion discard threshold is reached and aggressive dropping is when the hold-queue out limit is reached. WFQ always drops

packets of the most aggressive flows and uses the following two parameters to affect the way WFQ drops packets. In this example, N is the number of packets in the WFQ system when the N-th packet arrives.

• Congestive discard Threshold (CDT) is used to start dropping packets of the most aggressive flows, even before the hold-queue limit is reached.
• Hold-queue out limit (HQO) defines the maximum number of packets that can be in the WFQ system at any time.

WFQ Scheduling For scheduling purposes, in WFQ the length of the queue is not measured in packets but in the time it would take to transmit all the packets in the queue. WFQ adapts the number of flows and allocates equal amounts of bandwidth to each flow. Small packet flows which are usually interactive flows (voice and video) typically receive better service because they do not need a lot of bandwidth. They do need and receive low delay because smaller packets have a lower finish time. Finish time is the sum of the current time and the time it takes to transmit the packet. Current time is zero if there are no packets in the queue. The first packet into this queue will have a finish time of current time + transmission time. For example:

Current time = 0ms (no packets in the queue) First packet = 100ms to transmit this packet Finish time = 0 + 100ms = 100ms

Packet two comes into the queue Current time = 100ms 2nd Packet = 20ms to transmit this packet Finish Time = 100ms + 20ms = 120ms

WFQ will place the packets into the hardware queue based on the finish time lowest to highest. The last piece is to use the finish time and the IP precedence to introduce the weight into the calculation of which queues will be serviced in which order. The calculation to add weight is finish time divided by IP Precedence plus one (to prevent division by zero). In Cisco routers this calculation is done differently to decrease the load on the routers CPU. The Cisco router uses the packet size instead of the transmission time as they are proportional to each other. In addition, the packet size is not divided by IP Precedence; instead the packet size is multiplied by a fixed value (one value for each IP Precedence value). This is done because division is a CPU intensive operation in comparison to multiplication.

Pros and Cons of WFQ Pro

• Simple Configuration
• Guarantees throughput to all flows
• Drops packets of most aggressive flows
• Supported on most Cisco platforms and all IOS versions

Con

• Multiple flows can end up in one queue
• Does not support the configuration of classifications
• Cannot provide fixed bandwidth guarantees

WFQ Configuration WFQ is enabled by default on all interfaces that have a default bandwidth of less than 2Mbps. Use the fair-queue command to enable WFQ on interfaces that do not have WFQ enabled.

Router(config-if)# [cdt [dynamic-queues [reservable-queues]]]

Congestive discard threshold (CDT) – Optional

• Number of packets allowed in the WFQ system before the router starts dropping new packets for the longest queue, with a value of 1 to 4096 (default 64)

Dynamic-queues - Optional

• Number of dynamic queues, with values of 16,32,64,128,512,1024,2048,4096

Reservable-queues - Optional • Number of reservable queues if the RSVP feature is configures on the interface, with values of 0 to 1000

Router(config-if)# hold-queue max-limit out

Hold-queue Max (HQO)

• Maximum number of packets that can be in all output queues on the interface at any time
• Default is 1000

In most cases the hold-queue limit will never be reached because the CDT will start dropping the most aggressive conversations. WFQ Show Commands

Router#show interface interface

Output Queue

• 0 packets in the WFQ system
• 1000 packets allowed in the WFQ system, set by the HQO
• 64 packets in anyone queue before CDT starts dropping aggressive flows
• 0 packets have been dropped

Conversations

• 0 active conversations
• 4 maximum number of concurrent conversations
• 256 total number of WFQ queues

Router#show queue interface-name interface-number

Show queue displays the packets inside a queue for a particular interface

• Depth = number of packets in the queue, the above example displays 1 packet
• Weight = depending on the IOS version the weight is calculated by “IP Precedence + 1” or “32,384/(IP Precedence + 1), the above example displays 4096
• Discards = represents drops due to CDT
• Tail Drops = represents drops due to HQO

Summary This blog discussed Weighted Fair Queuing, the next blog in this QoS series will discuss Class Based WFQ and Low Latency queuing (LLQ). Author: Paul Stryer References

• Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.4T
• End-To-End QoS network Design, by Tim Szigeti and Christina Hattingh – ISBN # 1-58705-176-1
• DiffServ – The Scalable End-To-End QoS Model
• Integrated Services Architecture
• Definition of the Differentiated Services Field
• An Architecture for Differentiated Services
• Requirements for IP Version 4 Routers
• An Expedited Forwarding PHB (Per-Hop Behavior)