WFQ

 CBWFQ uses a scheduler similar to CQ and MDRR, reserving link bandwidth for each queue. LLQ combines the bandwidth reservation feature of CBWFQ with a PQ-like high priority queue, called a Low Latency Queue, which allows delay-sensitive traffic to spend little time in the queue.

 

WFQ classifies packets based on flows. A flow consists of all packets that have the same source and destination IP address, and the same source and destination port numbers. So, no explicit matching is configured.

 

The other large difference between WFQ versus PQ and CQ is the scheduler, which simply favors low-volume, higher-precedence flows over large-volume, lower-precedence flows. Also because WFQ is flow based, and each flow uses a different queue, the number of queues becomes rather large--up to a maximum of 4096 queues per interface. And although WFQ uses tail drop, it really uses a slightly modified tail-drop scheme-yet another difference.

 

WFQ classification

 

Flow-based WFQ classifies traffic into flows. Flows are identified by at least five items in an IP packet.

Source IP address
Destination IP address
Transport layer protocol (TCP or UDP)
TCP or UDP source port
TCP or UDP destination port
IP Precedence

 

WFQ considers a flow to exist only as long as packets from that flow need to be enqueued. With WFQ, the number of flows, and therefore the number of queues, changes very quickly.

 

WFQ scheduler

The WFQ scheduler has two main goals.

• The first is to provide fairness among the currently existing flow.
• The second goal of the WFQ scheduler is to provide more bandwidth to flow with higher IP precedence values.

In short, WFQ simply could not be implemented by assigning a percentage of bandwidth, or a byte count, to each queue.

 

The WFQ scheduler is actually very simple. When the hardware queue frees a slot, WFQ can move one packet to the hardware queue, just like any other queuing tool. The WFQ scheduler takes the packet with the lowest SN (sequence number) among all the queues, and moves it to the hardware queue. The SN is assigned when the packet is placed into a queue, which is where the interesting part of WFQ scheduling takes places.

 

WFQ calculates the SN before adding a packet to its associated queue. In fact, WFQ calculates the SN before making the drop decision, because the SN is part of the modified tail-drop logic. The WFQ scheduler considers both packet length and precedence when calculating the SN. The formula is as follows:

 

Previous_SN + (Weight*new_packet_length)
Weight=32384/(IP_precedence+1)

 

So the lower-volume, but lower-precedence flows will have some degradation in service relative to the higher-volume, but higher-precedence flows.

Finally, a router using WFQ can experience a phenomenon called too fair. With many flows, WFQ will give some bandwidth to every flow. The packets that are already in the existing queues will have to wait on all the new packets. In an effort to give each flow some of the link bandwidth; WFQ may actually not give some or most the flows enough bandwidth for them to survive.

 

WFQ drop policy

 

WFQ uses a slightly modified tail-drop policy for choosing when to drop packets. The decision is based on several factors, one being the SN of the packet.

WFQ places an absolute limit on the number of packets enqueued among all queues; this value is called the hold-queue limit. If a new packet arrives, and the hold-queue limit has been reached, the packet is discarded. That part of the decision is based not on a single queue, but on the whole WFQ queuing system for the interface.

The next decision is based on an individual queue. If a packet needs to be placed into a queue, and that queue's congestive discard threshold(CDT) has been reached, the packet may be thrown away.CDT is a little like a maximum queue length for each flow's queue, but WFQ puts a little twist on how the concept is used.

The hold-queue size limits the total number of packets in all of the flow or conversation queues. However, CDT limits the number of packets in each individual queue. If CDT packets are already in the queue into which a packet should be placed, WFQ considers discarding the new packet. Normally, the new packet is discarded. If a packet with larger SN has already been enqueued in a different queue, however, WFQ instead discards the packet with the large SN!

In short, WFQ can discard a packet in another flow when the queue for a different flow has exceeded CDT but still has lower sequence number. You can configure the CDT to a value between 1 and 4096.

 

Finally, WFQ can be configured for a maximum of 4096 queues.

 

Special WFQ Queues

 

Although you do not really need to know much detail for the QOS exam, there are a couple of types of WFQ queues about which you should at least be aware. First, WFQ keeps eight hidden queues for overhead traffic generated by the router. WFQ uses a very low weight for these queues in order to give preference to the overhead traffic.

The other type of queue isn't really hidden, but most people simply don't notice them. To reserve the bandwidth, RSVP asks WFQ to create a queue for each RSVP-reserved flow, and to give it a very low weight

 

WFQ configuration

None of WFQ's parameters can be set for an individual queue; so at most, the WFQ configuration will be one or two lines long.

 

R1(config-if)#fair-queue 128 512 16

R1(config-if)#do show queueing    

Current fair queue configuration:

 

  Interface           Discard    Dynamic  Reserved  Link    Priority

                      threshold  queues   queues    queues  queues

  Serial1/0           128        512      16        8       1   

  Serial1/1           64         256      0         8       1   

  Serial1/2           64         256      0         8       1   

  Serial1/3           64         256      0         8       1   

 

Current DLCI priority queue configuration:

Current priority queue configuration:

Current custom queue configuration:

Current random-detect configuration:

Current per-SID queue configuration:

R1(config-if)#

 

R1(config-if)#hold-queue 2000 out

R1(config-if)#do show inter s1/0

Serial1/0 is up, line protocol is up

  Hardware is M4T

  Internet address is 12.0.0.1/24

  MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,

     reliability 255/255, txload 1/255, rxload 1/255

  Encapsulation HDLC, crc 16, loopback not set

  Keepalive set (10 sec)

  Restart-Delay is 0 secs

  Last input 00:00:05, output 00:00:03, output hang never

  Last clearing of "show interface" counters never

  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0

  Queueing strategy: weighted fair

  Output queue: 0/2000/128/0 (size/max total/threshold/drops)

     Conversations  0/1/512 (active/max active/max total)

     Reserved Conversations 0/0 (allocated/max allocated)

     Available Bandwidth 1158 kilobits/sec

  5 minute input rate 0 bits/sec, 0 packets/sec

  5 minute output rate 0 bits/sec, 0 packets/sec

     89 packets input, 7660 bytes, 0 no buffer

     Received 59 broadcasts, 0 runts, 0 giants, 0 throttles

     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

     98 packets output, 8718 bytes, 0 underruns

     0 output errors, 0 collisions, 5 interface resets

     0 output buffer failures, 0 output buffers swapped out

     5 carrier transitions     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up

 

R1(config-if)#

 

WFQ Summary

WFQ requires no classification configuration. As a result, WFQ provides a great default queuing choice, particularly when traffic characteristics are unpredictable and difficult to qualify.

WFQ works poorly for voice and interactive video traffic, because both need low delay and low jitter. WFQ does not provide a priority queue in order to minimize delay and jitter. Also delay can increase when too many concurrent flows occur, due to WFQ being "too fair", allowing some bandwidth to each flow, which may cause the voice or video flows to not get enough bandwidth.

 

WFQ Functions and features

Classification: flow based without configuration
Drop policy: modified tail drop
Number of queues: 4096
Maximum queue length: congestive discard threshold per queue (max 4096), with an overall limit based on the hold queue for all queues(max 4096)
Scheduling inside a single queue: FIFO
Scheduling among all queues: Serves lowest SN. The SN is assigned when the packet is placed into the queue, as a function of length and precedence.