|
Previous
|
Content
|
Next
|
|
| 2.4.2.4 WFQ queuing discipline |
|
|
|
| WFQ queuing discipline belong to the family of Fair Queuing (FQ) algorithms. FQ was proposed by John Nagle in 1987. This queuing discipline was designed to ensure that each flow has fair access to network resources and to prevent bursty flows from consuming more than its share output bandwidth. WFQ queuing discipline was developed independently in 1989 by Lixia Zhang and by Alan Demers, Srivinasan Keshav and Scott Shenke. |
| Again I'm going to steal next figure from Cisco that explains better than a hundred words; I added some color for better understanding. Have a look to figure #9 below. |
|
|
| WFQ is like having several doors. When a packet arrives it is classified by the classifier and assigned to one of the doors. The door is the entry to a queue that is served together with some
other in a weighted round-robin order. This way the service is 'fair' for every queue. |
| The key to classify a flow is a conversation, this means, a numeric representation based on information taken from the packet header (source address, source port, destination address, protocol, ip precedence, etc.) for classification. Because it is not practical to have one queue for each conversation, WFQ employs a hashing algorithm which divides the traffic over a limited number of queues to be selected by the user or fixed by default. This way increasing as large as possible the number of queues helps the fairness of the algorithm. |
| What all this means? That you can have several flows sharing the same queue; it can be seen in the figure above when packets of different colors share the same queue. Let's repeat again the entire process: the packet arrives, then the classifier snoops its header and using information contained on it (source address and port, destination address, ip precedence, protocol, etc.) calculates a number between "1" and "number of queues". Then, it locates the packet in the queue identify by this number. |
| Process is really a little bit complicated because Cisco WFQ implementation is almost an automatic state-of-the art specialty queuing discipline. A lot of "class A" Cisco technology has been implemented on it. For example, WFQ is IP precedence-aware. Let us bring here the IP header diagram to understand this better: |
|
|
| First three bits of the IP header TOS byte are called precedence-bits. Then WFQ is able to detect higher priority packets marked with precedence bits by the IP forwarder (router) and can schedule them faster. This way as soon as precedence increase, WFQ allocates more bandwidth to these flows against to
other. |
| WFQ is used as the default queuing discipline on most Cisco router's serial interfaces configured to run at or below E1 speeds (2.048 Mbps). Beyond being IP precedence-aware, WFQ can classify traffic into different flows (queues) based on source and destination network or MAC address, protocol, source and destination port, socket number of the session, Frame Relay data-link connection identifier (DLCI) value and type of service (TOS byte) value. |
|
|
|
It can work in conjunction with RSVP (Resource Reservation Protocol) to build Integrated Service architecture implementations (an architecture designed to guarantee network bandwidth from end to end for IP networks); in conjunction with Frame Relay congestion notification scheme by adjusting weights of queues to respond to forward explicit congestion notification (FECN) and backward explicit congestion notification (BECN); and, because is less than obvious, to build partial compliance Differentiated Service architecture implementations (an architecture designed to lend differentiated service on IP networks) using IP-precedence bits. Partial because Cisco, instead of Linux, has not yet a complete Differentiated Service architecture implementation available. |
|
| Note: for all of you interested in Differentiated Service architecture, be pending because I'm writing a very complete work about this model using Linux to implement it. It must be ready really soon. Have a look to my site at
http://opalsoft.net/qos frequently. I will submit it to the Linux Document Project at
http://www.tldp.org for publishing, I hope. |
| Continuing back with Cisco WFQ implementation it is good to know that this beautiful micro-beast is almost automatic. Configuration is very simple. Let's see how to start to run one of these marvels. Just type: |
|
|
| Ready!! Incredible, isn't it? That's why I told you before that this beast works almost automatically. Command above installs a WFQ on router's serial interface 3/0. If you want to specify something (to feel yourself as important as
WFQ is) you could type instead: |
|
|
| First parameter is the length, in number of packets, of each of the queues. According to this our queues are going to be of 128 packets each. And, how many queues do you want, estimable fellow? That's our second parameter, it means, our WFQ will have 512 queues to make its work. |
| Well, WFQ time is over. Our next friend will be Commited Access Rate (CAR). Let's go ahead. |
|
|
|
|
|
Previous
|
Content
|
Next
|
