WRED Drop Probability

[Mitrixsen]

Hello, everyone.

I have a quick question about how WRED drops traffic. Consider this example that I found on NetworkLessons.com

IPP3 has the following values configured:
Minimum Threshold: 20 packets
Maximum Threshold: 45 packets
Mark-Probability Denominator: 25%

Once we reach the maximum threshold, I thought we would we would only be dropping 1 out of every 4 packets (25%).

This does appear to be the case if the traffic doesn't exceed the maximum threshold, but if we exceed the maximum threshold, we just drop it all?

So does the logic work like this in my example, then?

average queue depth < minimum threshold - don't drop anything

average queue depth > minimum threshold but < maximum threshold - Randomly drop packets up to the configured mark probability denominator (so if the queue depth is constantly getting larger, the drop probability moves its way up to 25% as we move closer to the maximum threshold).

average queue depth = maximum threshold - drop probability is up to the configured MPD (25%)

average queue depth > maximum threshold - everything is dropped

Thank you.

David

[Torbjørn · Accepted solution]

Hello @Mitrixsen, 

That is correct.

[Joseph W. Doherty]

Yup, all is dropped beyond max and you got the rest correct too.

BTW, you can easily calculate the exact randon drop probability, for any queue depth, using a straight line slope equation as we know x and y for min less 1, zero, and max value.

Also BTW, always keep in mind, for WRED, queue depth is a weighted moving average.  In theory, RED can even drop all packets when actual egress queue depth is empty and conversely drop zero packets when actual queue depth is more than max.

[David Ruess · Accepted solution]

Hello,

Yes, the MPD only comes into effect between the thresholds. It doesn't make sense to drop 25% of the packets if the queue is full (maximum threshold) we need to drop anything that exceeds that to reduce congestion. 

-David

[M02@rt37 · Accepted solution]

Hello @Mitrixsen 

Correct. WRED is the congestion-Avoidance tool so "we need to drop anything that exceeds that to reduce congestion".

[Joseph W. Doherty]

WRED is the congestion-Avoidance tool so "we need to drop anything that exceeds that to reduce congestion".

It can be, but a generally, a very, very crude way to accomplish that.  I.e., with WRED, ideally, you want to see all the drops taking place in the random drop range.

Probably, most often, in general, tail dropping is just used to avoid buffer exhaustion.

Again, not saying tail dropping cannot be used for congestion management, because it can, but with WRED, it's something to avoid.

However, with WRED, as shown in OP, you can drop lower priority traffic sooner, hopefully providing higher priority traffic additional bandwidth.  It can also be used to implement an average WTD approach (set min and max to same value with 100% drop percentage).

BTW, having a real coherent dropping strategy, for congestion management, seems to be rarely done.

Oh, and another reason for specific setting the tail drop vaule, it can be to set a transmission queuing latency boundary.

[M02@rt37]

As I know, WRED is primarily a congestion avoidance tool designed to prevent congestion before it becomes severe. Unlike tail drop, which only acts when the buffer is full, WRED randomly drops packets as the average queue depth increases. By doing so, it signals congestion to TCP flows earlier, causing them to adjust their transmission rates. This behavior helps to prevent global synchronization, where multiple TCP flows simultaneously reduce and increase their rates, leading to instability and inefficiency in the network. Tail drop, in contrast, acts as a last resort to avoid buffer exhaustion but lacks the finesse of WRED’s proactive congestion management.

While tail drop is generally seen as a crude method of congestion management, it does have its uses. Tail drop can set a hard limit on queue depth, effectively defining a transmission latency boundary. This ensures that packets exceeding a certain latency threshold are dropped rather than queued, which is particularly useful for delay-sensitive applications. However, relying solely on tail drop for congestion management often leads to abrupt traffic halts and synchronization of TCP retransmissions, which can worsen congestion rather than alleviate it.

Another potential use of WRED is to implement a Weighted Tail Drop, called 'WTD', approach by setting the minimum and maximum thresholds to the same value with a 100% drop probability. This creates a deterministic boundary for packet drops while still operating within the WRED framework. Such configurations can be useful in specific scenarios where precise control over queue depths is required.

Despite its advantages, WRED’s potential is often underutilized. Many networks rely on default configurations, which may not fully address the needs of their traffic patterns. A well-thought-out WRED strategy, however, can effectively manage congestion, avoid full-buffer scenarios, and provide fairer bandwidth allocation among competing traffic flows. 

[Joseph W. Doherty]

"TCP flows"

BTW, although TCP is the "poster child" for (W)RED), other later protocols that are also flow rate adaptable, to drops, are also candidates for RED like treatment.

". . . and provide fairer bandwidth allocation among competing traffic flows."

Also BTW, somewhat difficult to accomplish, with WRED.

Lastly, I've written WRED can be very difficult to use ideally, and has its "quirks", much of the reason for all the better/improved/(supposedly even)fixed variants.  One interesting variant, that Cisco provided on the Catalyst 4k series was FRED (Flow based RED).

[M02@rt37]

TCP is the classic example of a protocol well-suited for mechanisms like RED and WRED. As a flow-rate-adaptive protocol, TCP responds to packet drops by reducing its transmission rate, aligning with RED's purpose of preemptively signaling congestion by dropping packets probabilistically before queues overflow... However, while TCP is the primary use case, other modern protocols such as QUIC and SCTP, which adapt to drops in a similar fashion, can also benefit from RED-like congestion management.

"One of the goals of WRED is to promote fairer bandwidth allocation among competing traffic flows by selectively dropping packets from more aggressive flows while sparing less intensive traffic" ..... In practice, achieving this fairness is challenging due to various factors. WRED bases its drop probabilities on queue thresholds and traffic volume, which means it inherently favors smaller, less aggressive flows. However, fairness can still be skewed by differences in RTTs, window sizes, or congestion control algorithms, potentially leaving some flows disadvantaged despite the intent.

WRED is also known for being difficult to configure and optimize. Setting the right thresholds, weights, and probabilities for diverse traffic types is complex, and even small misconfigurations can lead to suboptimal performance or unintended consequences, such as synchronized drops. These limitations and quirks have led to the development of improved or specialized variants. One such variant, Flow-based RED, introduced on Catalyst 4K series switches. From my point of view it takes a more granular aproach by managing congestion at the flow level rather than at the aggregate queue level, providing finer control over individual flows and potentially addressing some of WRED's fairness issues.

Thanks for that discussion.

[Joseph W. Doherty · Accepted solution]

Oops, missed it on first reading, but

average queue depth > minimum threshold but < maximum threshold

Should be

average queue depth => minimum threshold but < maximum threshold

and when less than max, drop probability also not max, although it may round to max.

Also, at max, drop probability isn't up to, it's max percentage.