Class-Based Weighted-Fair Queuing (CBWFQ)

CBWFQ

Class-Based Weighted-Fair Queuing (CBWFQ) is a queuing algorithm that combines the capability to guarantee bandwidth with the capability to dynamically ensure fairness to other flows within a class of traffic.

CBWFQ allows for the creation of up to 64 classes of traffic, each with its own reserved queue. Each queue is serviced in a weighted-round-robin (WRR) fashion based on the bandwidth assigned to each class. Bandwidth might be assigned to a class in terms of absolute kbps (with the bandwidth command), as a percentage of a link’s bandwidth (with the bandwidth percent command), or as a percentage of bandwidth remaining, after the strict-priority Low-Latency Queue has been serviced (with the bandwidth remaining command).

To better understand how CBWFQ works, Example 1 begins by constructing a simple CBWFQ policy.

Example 1: CBWFQ Policy Example

---

Router(config)# policy-map CBWFQ
Router(config-pmap)# class NETWORK-CONTROL
Router(config-pmap-c)# bandwidth percent 5
Router(config-pmap-c)# class TRANSACTIONAL-DATA
Router(config-pmap-c)# bandwidth percent 20
Router(config-pmap-c)# class BULK-DATA
Router(config-pmap-c)# bandwidth percent 10
Router(config-pmap-c)# class class-default
Router(config-pmap-c)# fair-queue

---

Next, look at the underlying CBWFQ mechanisms that correspond with this policy, as illustrated in Figure 1.

 
Figure 1: Class-Based Weighted-Fair Queuing mechanisms

In Figure 1, you see a router interface that has been configured with a 4-class CBWFQ policy, with an explicit CBWFQ defined for Network Control, Transactional Data, and Bulk Data, respectively, and the default CBWFQ queue, which has a Fair-Queuing (FQ) pre-sorter assigned to it.

Note

CBWFQ is a bit of a misnomer because the pre-sorter that can be applied to certain CBWFQs, such as class-default, is not actually a Weighted-Fair Queuing (WFQ) pre-sorter, but rather a Fair-Queuing (FQ) pre-sorter, and as such, it ignores any IP Precedence values when calculating bandwidth allocation traffic flows. To be more technically accurate, this queuing algorithm would be better named Class-Based Fair-Queuing or CBFQ.

Another underlying queuing mechanism is a final (FIFO) output buffer called the Tx-Ring, which serves the purpose of always having packets ready to be placed onto the wire so that link utilization can be driven to 100 percent. The Tx-Ring also serves to indicate congestion to IOS. Specifically, when the Tx-Ring fills to capacity, the interface is known to be congested, and a signal is sent to engage any LLQ/CBWFQ policies that have been configured on the interface.

CBWFQ works in the following manner:

1. Packets are classified according to the class maps and assigned to either explicitly defined CBWFQs or to the default queue. If the packets are assigned to the default queue and fair-queuing has been enabled on the default class with the fair-queue subcommand, packets receive a proportionately equal share of the available bandwidth for the default queue. For example, if there is 100 kbps assigned to the default queue and there are 10 IP flows that are contenting for the default queue, each flow is assigned an equal share (10 kbps) of bandwidth by the FQ pre-sorter.
2. Next, the CBWFQ scheduler dequeues the packets from each CBWFQ in a weighted-round-robin (WRR) manner that reflects the proportionate bandwidth allocations per-class.
3. These packets are then enqueued into the Tx-Ring.
4. Finally, the packets exit the Tx-Ring in a FIFO manner as they are transmitted across the physical interface media.

CBWFQ is a highly efficient queuing algorithm for data applications but lacks the capability to provide strict-priority servicing to real-time applications, such as voice or interactive video. This is because it provides a bandwidth guarantee but not a latency/jitter guarantee. Therefore, to service such real-time applications, a strict-priority queue was added to the CBWFQ algorithm, and the resulting algorithm was named Low-Latency Queuing.