What is RED?

Random Early Drop (RED), also called Random Early Detection, is a congestion-avoidance technique that tracks the average queue length on a network interface and begins probabilistically dropping packets before the queue fills completely, signaling senders to slow down early rather than waiting for a hard, all-at-once tail drop.

Key takeaways

• RED drops packets probabilistically before a queue fills, not all at once.
• It prevents the bursty, synchronized loss that plain tail-drop queuing causes.
• Drop probability rises with average queue length between two thresholds.
• In Versa DoS/flood profiles, RED is an action between Allow and hard Drop.
• Weighted RED (WRED) applies different drop thresholds per traffic class.

On this page: Why it matters · How it works · Types · RED & Versa · FAQ

Why is RED important?

Without a technique like RED, a congested interface using plain tail-drop queuing waits until its buffer is full, then drops every arriving packet until space opens up. Many TCP flows sharing that link lose packets at once and slow down at once, then ramp back up together – global synchronization, a pattern that produces oscillating throughput and wastes capacity.

RED matters because it intervenes earlier and more fairly. Dropping a small, random sample of packets once the queue starts growing – well before it is full – means only the flows that get hit back off, at different moments rather than in lockstep. That keeps average queue depth, and latency, low while still absorbing bursts, giving operators an early signal instead of an abrupt, all-or-nothing cutoff.

What is RED?

RED operates against two configured thresholds and an average queue-length calculation – typically an exponentially weighted moving average, not the instantaneous depth, so a brief burst doesn’t itself trigger a reaction. Below the minimum threshold, nothing is dropped. Between the minimum and maximum, drop probability rises toward the maximum: a small number of packets are sacrificed early to signal TCP senders, which back off before the queue overflows. Once the average reaches the maximum, RED drops every arriving packet, behaving like ordinary tail drop – and because the earlier drops are chosen effectively at random, the signal spreads across many connections instead of concentrating on whichever flow arrives when the buffer is already full.

Types of RED

Several variants extend the base algorithm. Weighted RED (WRED) applies different thresholds and drop probabilities per traffic class – typically keyed to a DSCP or IP-precedence marking – so lower-priority traffic drops earlier than latency- or loss-sensitive classes sharing the same queue. RED with In/Out (RIO) is a DiffServ-oriented variant that keeps separate drop curves for in-profile and out-of-profile packets. Adaptive RED automatically tunes the maximum drop probability to hold the average queue length near a target, reducing the need to hand-tune parameters for a given link.

All of these keep RED’s core mechanism – probabilistic, threshold-bounded dropping based on average queue length – and differ mainly in how many drop curves they maintain.

RED & Versa

On Versa Titan-managed SASE gateways, RED is a configurable action inside DoS protection profiles, referenced from a DoS protection policy that matches traffic by zone, address, and protocol. Each profile sets flood thresholds per protocol – ICMP, ICMPv6, TCP, UDP, SCTP, and other IP traffic – including an Alarm Rate, an Activate Rate, and a hard Maximum Rate, in packets per second.

Once the Activate Rate is breached, the Action field lets an administrator choose Random Early Drops or SYN Cookies, a TCP-specific defense that acknowledges connections without committing session state; SYN Cookies is the default. Traffic past the Maximum Rate is dropped outright regardless of action – RED governs only the band in between. Administrators build these profiles from the Security tab in Titan Portal, Versa’s console for SASE gateway branch devices.

A related but distinct mechanism is Versa’s NPU-based QoS traffic policing, where policers mark packets green, yellow, or red against CIR/CBS/PIR/PBS thresholds – deterministic marking, not RED’s probabilistic drop.

Frequently asked questions

What is the difference between RED and tail drop?

Tail drop lets a queue fill completely, then discards every packet until space frees up – a sudden, synchronized loss for every flow on the link. RED drops a random fraction earlier, spreading the signal instead of one abrupt burst.

Why does RED drop packets randomly instead of by a fixed rule?

Random selection avoids penalizing one flow disproportionately. A fixed rule could let a single high-volume flow absorb most of the loss while others passed through untouched. Randomizing spreads the response roughly in proportion to each flow’s traffic share.

Does RED replace TCP’s own congestion control?

No. RED works alongside TCP. Dropping a packet early triggers TCP’s existing congestion-control response – the sender reads the loss as a signal to slow down, the same reaction a late tail-drop loss causes, just sooner and more gently.

Is RED still relevant on modern high-speed networks?

Yes, though later IETF guidance broadened its recommendation from RED specifically to active queue management (AQM) in general, since RED’s fixed parameters are hard to tune across varying link speeds. The underlying principle – dropping early and probabilistically – remains standard.

When does Versa use Random Early Drops instead of SYN Cookies?

Both are alternative actions in a DoS profile’s flood settings, applied once a protocol’s Activate Rate is breached. SYN Cookies specifically defends TCP SYN floods and is the default; Random Early Drops applies more broadly across any flood-protected protocol when selected.

More on RED

If you want to learn more, these are sources we trust.

Related terms

If you’re reading about RED, these are worth looking at next.