WFQ is a simple yet important queuing mechanism on Cisco routers for two important reasons: first, WFQ is the default queuing on serial interfaces at 2.048 Mbps (E1) or lower speeds; second, WFQ is used by CBWFQ and LLQ, which are two popular, modern and advanced queuing methods. (CBWFQ and LLQ are discussed in the following sections of this topic.) WFQ has the following important goals and objectives:
■ Divide traffic into flows
■ Provide fair bandwidth allocation to the active flows
■ Provide faster scheduling to low-volume interactive flows
■ Provide more bandwidth to the higher-priority flows WFQ addresses the shortcomings of both FIFO and PQ:
■ FIFO might impose long delays, jitter, and possibly starvation on some packets (especially interactive traffic).
■ PQ will impose starvation on packets of lower-priority queues, and within each of the four queues of PQ, which are FIFO based, dangers associated to FIFO queuing are present.
WFQ Classification and Scheduling
WFQ is a flow-based queuing algorithm. Arriving packets are classified into flows, and each flow is assigned to a FIFO queue. Flows are identified based on the following fields from IP and either TCP or UDP headers:
■ Source IP address
■ Destination IP address
■ Protocol number
■ Type of service (ToS)
■ Source TCP/UDP port number
■ Destination TCP/UDP port number
A hash is generated based on the preceding fields. Because packets of the same traffic flow end up with the same hash value, they are assigned to the same queue. Figure 4-4 shows that as a packet arrives, the hash based on its header fields is computed. If the packet is the first from a new flow, it is assigned to a new queue for that flow. If the packet hash matches an existing flow hash, the packet is assigned to that flow queue.
Figure 4-4 Weighted Fair Queuing
Figure 4-4 does not show that, based on how full the interface hold queue is, and based on whether the packet queue size is beyond a congestive discard threshold value, the packet might end up being dropped. It is worth mentioning that when a packet arrives, it is assigned a sequence number for scheduling purposes. The priority of a packet or flow influences its scheduling sequence number. These concepts and mechanisms are discussed next.
NOTE The sequence number assigned to an arriving packet is computed by adding the sequence number of the last packet in the flow queue to the modified size of the arriving packet. The size of the arriving packet is modified by multiplying it by the weight assigned to the packet. The weight is inversely proportional to the packet priority (from the ToS field). To illustrate this, consider two packets of the same size but of different priorities arriving at the same time. The two queues that these packets are mapped to are equally busy. The packet with the higher priority gets a smaller scheduling sequence number and will most likely be forwarded faster than the packet with the lower priority.
If all flows have the same priority (weight), WFQ effectively divides the interface bandwidth among all the existing flows. As a result, low-volume interactive flows are scheduled and forwarded to the hardware queue and do not end up with packets waiting in their corresponding queues (or at least not for long). Packets of high-volume flows build up their corresponding queues and end up waiting and delayed more and possibly dropped.
It is important to note that the number of existing queues in the WFQ system is based on the number of active flows; in other words, WFQ dynamically builds and deletes queues. The interface bandwidth is divided among the active flows/queues, and that division is partially dependent on the priorities of those flows. Therefore, unlike CQ (and indeed CBWFQ, to be discussed in the next section), WFQ does not offer precise control over bandwidth allocation among the flows. Also, WFQ does not work with tunneling and encryption, because WFQ needs access to packet header fields to compute the hash used for assigning packets to flow-based queues.
The number of queues that the WFQ system can build for the active flows is limited. The maximum number of the queues, also called WFQ dynamic queues, is 256 by default. This number can be set between 16 and 4096 (inclusive), but the number must be a power of 2. In addition to the dynamic flows, WFQ allows up to 8 queues for system packets and up to 1000 queues for RSVP flows. When the number of active flows exceeds the maximum number of dynamic queues, new flows are assigned to the existing queues. Therefore, multiple flows might end up sharing a queue. Naturally, in environments that normally have thousands of active flows, WFQ might not be a desirable queuing discipline.
WFQ Insertion and Drop Policy
WFQ has a hold queue for all the packets of all flows (queues within the WFQ system). The hold queue is the sum of all the memory taken by the packets present in the WFQ system. If a packet arrives while the hold queue is full, the packet is dropped. This is called WFQ aggressive dropping. Aggressive dropping has one exception: if a packet is assigned to an empty queue, it is not dropped.
Each flow-based queue within WFQ has a congestive discard threshold (CDT). If a packet arrives and the hold queue is not full but the CDT of that packet flow queue is reached, the packet is dropped. This is called WFQ early dropping. Early dropping has an exception: if a packet in another queue has a higher (larger) sequence number than the arriving packet, the packet with the higher sequence number is dropped instead. The dropped packet is assumed to belong to an aggressive flow. It can be concluded that the early drop of WFQ punishes packets from aggressive flows more severely and that packet precedence does not affect WFQ drop decisions.
Benefits and Drawbacks of WFQ
The main benefits of WFQ are as follows:
■ Configuring WFQ is simple and requires no explicit classification.
■ WFQ does not starve flows and guarantees throughput to all flows.
■ WFQ drops packets from the most aggressive flows and provides faster service to nonaggressive flows.
■ WFQ is a standard and simple queuing mechanism that is supported on most Cisco platforms and IOS versions.
WFQ has some limitations and drawbacks:
■ WFQ classification and scheduling are not configurable and modifiable.
■ WFQ is supported only on slow links (2.048 Mbps and less).
■ WFQ does not offer guarantees such as bandwidth and delay guarantees to traffic flows.
■ Multiple traffic flows may be assigned to the same queue within the WFQ system.
Configuring and Monitoring WFQ
WFQ is enabled by default on all serial interfaces that are slower than or equal to 2.048 Mbps. If WFQ is disabled on an interface and you want to enable it or if you want to change its configurable parameters, you can use the fair-queue command in the interface configuration mode. The following shows the optional parameters that can be configured while you enter the fair-queue command:
This syntax also shows how the overall size of the WFQ system can be modified: the number of packets an interface can hold in its outbound software queue can be set using the hold-queue max-limit out command.
As you can see in this command syntax, configuring WFQ on an interface is simple. The cdt parameter (congestive discard threshold) sets the number of packets allowed in each queue. The default is 64, but you can change it to any power of 2 in the range from 16 to 4096. If a queue size exceeds its CDT limit, new packets that are assigned to this queue are discarded. The dynamic-queues parameter allows you to set the maximum number of flow queues allowed within the WFQ system. This number can be between 16 and 4096 (inclusive) and must be a power of 2. (The default is 256.) The parameter reservable-queues sets the number of allowed reserved conversations. This number must be between 0 and 1000 (inclusive). (The default is 0.) Reservable queues are used for interfaces that are configured for features such as Resource Reservation Protocol (RSVP).
You can check the settings for the WFQ configurable parameters by using the output of the show interface interface command. Example 4-1 displays sample output of this command. The queuing strategy is stated to be weighted fair queuing. For the output queue, the current size, maximum size (hold-queue max-limit), congestive discard threshold (per queue), and number of drops are stated to be 0, 1000, 64, and 0, respectively. The current number of conversations is stated to be 0, while it shows that a maximum of 10 conversations has been active during the measurement interval. The maximum allowed number of concurrent conversations is shown to be 256, which is the default value.
Example 4-1 Sample Output of the show interface Command
Example 4-1 Sample Output of the show interface Command
You can obtain detailed information about the WFQ system on a particular interface (including a particular virtual circuit) by using the show queue interface command. Example 4-2 shows sample output of this command for your review. Observe that the output of this command for each queue (conversation) displays the IP packet header fields that distinguish one flow from another. Furthermore, for each conversation (queue), its depth (size), weight (related to distribution of bandwidth), and other statistics are displayed individually.
Example 4-2 Sample Output of the show queue interface Command
