How are Weighted Fair Queuing and Weighted Random Early Detection related?

Question

I'm trying to understand how QoS systems work and I'm not sure how exactly would WFQ and WRED interact.

At first, I thought that WFQ is a queuing mechanism and that WRED is a congestion avoidance mechanism. WFQ should schedule packets in queues and WRED is there to drop them when queues are full. If I'm setting up QoS on for example an L3 switch, I'd set up a queuing mechanism and a congestion avoidance mechanism, so I could in theory have WFQ and WRD working together. For example, this document seems to imply that I they would be set up in such way. Some other Cisco documents mention that I could use them independently.

Then I wanted to learn more about how they worked and started searching the Internet. As a result, now I have no idea what they are and how they work.

Some sites (at least to my understanding of the content) claim that packet scheduling algorithms and congestion avoidance algorithms are basically the same. For example in this Wikipedia article, they are all placed in a same group. Some random articles mentioned that I could use WFQ XOR WRED.

So what I wanted to ask is how related are WFQ and WRED? When would I use one or another and when both, if that's even possible?

Answer 1

Weighted Fair Queueing (WFQ) is as the name implies a queueing algorithm. Queueing is used when there is congestion on an interface. This is usually detected through that the Transmit Ring (TX-Ring) is full. This means that the interface is busy sending packets. Queuing does not take place unless there is congestion on the interface. In some cases the size of the TX-ring can be manipulated. A small TX-ring gives the software queue more power as to which packets get sent out first but it's not very effective. A too large TX-ring would make the software queue almost useless and lead to higher latency and jitter for important packets.

The default queueing algorithm is usually First In First Out (FIFO). This means that packets are delivered in exactly the order as they arrive on the input of the interface. This is not usually desirable because some packets should be prioritized.

It is quite common that a customer buys a service from an Internet Service Provider (ISP) at subrate. That is, the customer buys a 50 Mbit/s service but the physical interface is running at 100 Mbit/s. In this case there will be no congestion but the ISP will be limiting the amount of traffic from the customer. To introduce artificial congestion in these cases a shaper can be applied.

So now that there is congestion a queueing algorithm can be applied. Note that queueing algorithms don't provide any extra bandwidth, they just let us decide which packets are more important to us. WFQ is an algorithm that takes several parameters and makes a decision based on that. The algorithm is quite complex and uses weight (IP Precedence), packet size and scheduling time as parameters. There is a very detailed explanation from INE here. WFQ is a good choice if one does not want to fiddle too much with queueing as it provides adequate bandwidth to small size flows like SSH, Telnet, voice and that means that a file transfer won't steal all the bandwidth.

Weighted Random Early Detection (WRED) is a congestion avoidance mechanism. WRED measures the size of the queues depending on the Precedence value and starts dropping packets when the queue is between the minimum threshold and the maximum threshold. Configuration will decide that 1 in every N packets are dropped. WRED helps to prevent TCP synchronization and TCP starvation. When TCP loses packets it will go into slow start and if all TCP sessions lose packets at the same time they could become synchronized which provides a graph like this:

As can be seen if WRED is not configured the graph goes full blast, then silent, then full blast and so on. WRED provides a more average transmit rate. It is important to note that UDP does not get affected by dropping packets because it has no acknowledgement mechanism and sliding window implemented like TCP. Therefore WRED should not be implemented on UDP based class like a class handling SNMP, DNS or other UDP based protocols.

Both WFQ and WRED can and should be deployed together.

Answer 2

First of all, don't believe everything you read on the Internet ;-)

Sometimes algorithms (or the way they are physically implemented) don't fit neatly into a theoretical category. What you call it is less important than understanding what it does.

The whole point of WFQ (or any other scheduling algorithm) is to share the limited link bandwidth among the various flows. WFQ tries to allocate the bandwidth proportionally to each flow. CBWFQ does the same to each "class." In a perfect world, with unlimited queues and unlimited memory, that would be all you need -- you share the bandwidth and everyone is happy.

But because devices don't have unlimited queues and memory, some "shortcuts" have to be made. Because a queue has a limited size, there is the danger that the queue will fill up, causing tail drops and traffic synchronization. Essentially, if my queue is overflowing, I'm no longer controlling the bandwidth.

To avoid my queues overflowing, I use Random Early Detection. This algorithm randomly drops packets from the queue according to how full the queue is (depth) -- the fuller the queue, the more packets will be dropped. The goal is to keep the queue from overflowing, so that the scheduling algorithm can work.

Then some bright Cisco engineer noticed that one could use fewer queues (simpler hardware) and randomly drop different kinds of traffic at different queue depths. WRED drops traffic from the queue at different depths depending on the type of traffic. Although you might call WRED a congestion avoidance mechanism, since the depth where traffic is dropped varies with the type of traffic, the effect is that different types get less space in the queue and therefore less of the bandwidth. So it also acts as a scheduling algorithm. You say po-tay-to and I say po-tah-toe.

One more difference: FQ and WFQ work on all types of traffic, since they essentially count bytes. RED and WRED only work with TCP, becuase they depend on TCP's flow control mechanism to slow down the traffic and keep the queue from overflowing.

(Note: for the sake of explanation, I'm ignoring priority queues and LLQ. That's another answer).

I agree with everything Mike said too.

Answer 3

Here is an example of CBWFQ and WRED:

policy-map OUT

class Voice
priority percent 20

class Video
bandwidth percent 30

class P1
bandwidth percent 10
random-detect dscp-based
random-detect dscp af31 26 40 10

class P2
bandwidth percent 15
random-detect dscp-based
random-detect dscp af21 24 40 10

class class-default
fair-queue
random-detect dscp-based