QOS :- The unknown facts of CBWFQ

vivkalra · ‎12-12-2009

The unknown facts of CBWFQ

CBWFQ allows user-defined traffic classes as compared to standard WFQ. WFQ applies weights to identified traffic to classify traffic into conversations and allocate bandwidth to each conversation. WFQ is enabled by default on all interfaces less than or equal to 2.048 Mbps.

For CBWFQ, traffic classes are defined matching protocols, ACLs and input interfaces. Packets satisfying the match criteria for a class constitutes the traffic for that class. A FIFO queue is reserved for each class, and traffic belonging to the class is directed to the queue for that class. A maximum of 64 classes/queues can be defined by a user in CBWFQ.

The characteristics of a particular class include bandwidth of the class, weight (derived from the "bandwidth" of the class), maximum packet limit and even queue limit.

If a default class is configured with bandwidth command, all unclassified traffic is put into a single FIFO queue and given treatment according to the configured bandwidth.

If a default class is configured with a fair-queue command, all unclassified traffic is flow classified and given best-effort treatment.

The mechanics behind "bandwidth" command:

    1) CBWFQ shares interface bandwidth inversely proportional to flow weights.

        If there are N number of flows and flow(i) has weight value Weight(i), then CBWFQ guarantees flow(i) the following share of bandwidth:

            Share(i) = ( Weight(1) + .... + Weight(i) + ... + Weight(N) )/ Weight(i)

    2) CBWQF assigns weights to dynamic conversations (non-user defined classes) using the formula-

            Weight(i) = 32384/ (IP_Prec(i) + 1)

    3) CBWFQ assigns weights to user-defined classes using the formula-

            Weight(i) = Constant * Interface_BW / Class_BW if the bandwidth of the class is configured explicitly
                OR
            Weight(i) = Constant * 100 / BW_percent is the bandwidth of the class is configured as bandwidth percent or bandwidth remaining percent commands.

The Constant depends on the number of flow queues in WFQ.

Number of flows	Constant Value
16	64
32	64
64	57
128	30
256	16
512	8
1024	4
2048	2
4096	1

The queues are allocated to different classes as below- if N is the number of dynamic flows of CBWFQ.

Flow / conversation number	Weight	Description
Below 2^N	Weight(i) = 32384/ (IP_Prec(i) + 1)	Dynamic Queues (e.g. non-user defined classes
2^N - 2^N+7	Weight(i) = 1024	Link Queues (e.g. routing updates, Keepalives)
2^N+8	Weight(i) = 0	LLQ or Priority Queue.
Above 2^N+8	Weight(i) = Constant * Intf_BW/ Class_BW OR Weight(i) = Constant * 100 / BW_percent	User defined classes

Pavel Bykov · ‎01-28-2010

I'd just like to point out a couple of facts for completion

1. The requlting sequence numbering is what actually defines the algorithm's decision of what to send and what not to send from the saturated queues. Without sequencing, the algorithm would work purely as a strict priority queuing mechanism.

2. Developers "trick" for LLQ's in the CBWFQ case also has a certain impact of priority queue behavior. Weight 0 means that resulting sequence number will always be zero, since zero times anything is zero. But when the queue crosses the set threshold (e.g. flow over 128Kbps when "priority 128" is set), the queue is actually not policed on software platforms, but some high Weight is set, probably using "32384/ (IP_Prec(i) + 1)". Therefore the queue is treated very unprefferentially, but it is not policed

3. This very well points to the queue starvation, when "bandwidth" parameter is not defined. Without "bandwidth" parameter, the weight is very high, and makes the packet departure very unlikely

Wailess84 · ‎04-09-2018

Hi Dear

i want to know how did u get these numbers of CBWFQ Const in below table

The Constant depends on the number of flow queues in WFQ.

Number of flows	Constant Value
16	64
32	64
64	57
128	30
256	16
512	8
1024	4
2048	2
4096	1