Friday, September 7, 2018

WRED and WFQ

My oversimplified description of both, after an afternoon buried in Cisco documentation:

WRED is a congestion avoidance mechanism, which seeks to prevent congestion before it occurs. It specifically addresses the issue of global synchronization for TCP flows egressing a router interface, by selectively and semi-randomly dropping segments even before queues have become full. This is designed to cause staggered slow start for all TCP flows, resulting in more efficient use of link bandwidth, as opposed to all TCP flows entering slow start at once with tail-drop.

WFQ is a congestion management mechanism, which seeks to deal with congestion, as reasonably as possible, once it occurs. In its most basic default configuration, it prioritizes low-bandwidth flows such as ICMP and de-prioritizes high-bandwidth flows, in a very basic attempt at ensuring timely delivery of realtime traffic. It also divides bandwidth between flows, so no single flow can starve other flows during congestion. It is enabled by default on all Cisco interfaces at or below E1 speeds.

According to Cisco docs, WRED and WFQ are mutually exclusive:

You cannot configure WRED on the same interface as Route Switch Processor (RSP)-based custom queueing (CQ), priority queueing (PQ), or weighted fair queueing (WFQ).

But it goes on to say:

However, you can configure both DWRED and DWFQ on the same interface.

So, I enabled default WFQ on both sides of a saturated T1 link (I'm not sure why they were set to FIFO in the first place). Several measurements and subjective tests show improvement over FIFO: realtime stuff is way more responsive, and sflow shows bandwidth is shared more equitably between sources.

Based on an afternoon reading up on WRED, it sounds like that might also benefit this scenario, since sflow confirms 99% of the traffic egressing the interface is TCP. Also, this Cisco StackExchange post says it's advisable to enable both WFQ and WRED.

Questions:

  1. Is it, in fact, advisable to enable both WFQ and WRED on congested interfaces?
    1. If so, what is the simplest configuration that enables both, e.g.: just apply WRED to all TCP traffic and use WFQ for everything?
    2. If not, should I prefer one over the other? (I assume WFQ, but unsure).


No comments:

Post a Comment