Congestion Avoidance

1. Introduction

Congestion Avoidance is a set of mechanisms designed to prevent packet loss before it happens.

When more packets arrive at an outgoing interface than it can transmit, the excess is stored in its output queue. If the queue becomes full, new packets are dropped. This not only reduces performance but also triggers unnecessary TCP slowdowns.

Figure 1 – Outgoing Interface congestion

As the name suggests, the goal of congestion avoidance is to prevent congestion before it happens.

Before exploring these mechanisms, it is important to first understand how TCP windowing works, since TCP’s behavior directly interacts with congestion.

2. TCP Windowing Basics

TCP uses a mechanism called TCP windowing to control how much data the sender can transmit before waiting for acknowledgments.

How It Works

1. Slow Start – The sender begins cautiously by transmitting just 1 segment.

2. Acknowledgment (ACK) – Once the receiver confirms delivery, the sender doubles the number of segments for the next round.

3. Exponential Growth – With each ACK, the number of segments doubles (2, 4, 8…), allowing the transmission rate to increase very quickly.

Figure 2 – TCP windowing process.

This exponential growth continues until the network or the receiver cannot keep up with the flow of data.

Now let's see how TCP react when the server cannot keep up with the flow.

Packet Loss

Suppose the sender transmits Segments 8–15:

• Segments 8–11 arrive successfully.

• Segments 12–15 are lost due to congestion.

• The receiver responds with ACK 12, confirming it has received everything up to Segment 11 but is still waiting for Segment 12.

Figure 3 – TCP packet loss and acknowledgment

TCP’s Reaction to Packet Loss

When TCP detects the loss:

• It immediately reduces its congestion window by half.

  • Before the loss: 8 segments in flight.

  • After the loss: 4 segments in flight.

• The sender retransmits the lost packets (12–15).

• Once they are delivered, the receiver replies with ACK 16, and normal transmission resumes.

Figure 4 – TCP retransmission of lost segments.

Impact of Packet Loss on TCP Behavior

TCP interprets packet loss as a sign of network congestion. Each time it happens, TCP slows down by cutting its sending rate in half.

The issue is that not all packet losses come from true congestion. In many cases, the loss happens because a device’s output queue becomes full. When that queue overflows, packets are dropped even though the network itself may still have available capacity.

3. Network Congestion

We’ve seen that TCP reacts to packet loss by reducing its window size. But where do those losses come from?
In many cases, they are not caused by true network overload, but by a full output queue on a device.

What is Network Congestion?

Network congestion happens when traffic arriving at a device is greater than what its outgoing interface can forward.

• Incoming packets are placed in an output queue.

• This type of packet loss is called a queue drop.

• If the queue fills up completely, new packets have nowhere to go and are dropped.

Tail Drop

Let’s take an example: three PCs send traffic toward a server through router R1. All flows converge on the outgoing interface G0/3.

Figure 5– Network congestion and tail drop.

When the output queue on G0/3 reaches its maximum capacity, new packets arriving at the tail are discarded. This mechanism is known as tail drop.

Why Tail Drop is a Problem

• Impact on TCP traffic – Every dropped packet looks like congestion to TCP. The sender reduces its congestion window, even if the link could still carry more traffic.

• Wasted bandwidth – As TCP slows down, the network may be underutilized, leaving available capacity unused.

In short: tail drop drops packets only when the queue is full. It keeps the queue under control, but it penalizes TCP flows unnecessarily.

Preparing for Congestion Avoidance

To overcome these issues, modern devices implement congestion avoidance mechanisms.
Instead of waiting until the queue is completely full, these mechanisms start dropping a small number of packets earlier, in a controlled way.

The two main techniques are:

• Random Early Detection (RED)

• Weighted Random Early Detection (WRED)

4. Random Early Detection (RED)

In the previous section, we saw that tail drop discards packets only when the queue is completely full. This approach is too harsh: it causes multiple TCP flows to drop packets at the same time, leading to global synchronization and reduced throughput.

Random Early Detection (RED) provides a smarter solution. Instead of waiting for the queue to overflow, RED starts dropping packets earlier and randomly when the queue depth reaches a certain level.

This proactive action keeps queues under control and avoids the sudden burst of packet loss caused by tail drop.

How RED Works

• Queue Monitoring
  RED continuously measures the average depth of the output queue

Figure 6 – Random Early Detection (RED) thresholds.

• Thresholds and Packet Dropping

  • Below minimum threshold → No drops; packets are forwarded normally.

  • Between minimum and maximum thresholds → RED starts randomly dropping a small percentage of packets. The closer the queue is to the maximum threshold, the higher the drop probability.

  • Above maximum threshold → The queue is considered full, and all new packets are dropped (like tail drop).

By dropping packets early, RED keeps queues from overflowing and reduces the risk of global synchronization. But RED has a limitation: it treats every packet the same. This is where WRED improves the process by protecting high-priority traffic and discarding lower-priority packets first when congestion builds up.

5. Weighted Random Early Detection (WRED)

WRED is an enhancement of RED that adds the ability to differentiate between traffic classes.

While RED treats every packet equally, WRED uses DSCP markings to decide which packets to protect and which to drop first when congestion builds. This ensures that WRED protects high-priority traffic, while low-priority traffic absorbs the losses.

How WRED Differentiates Between Priorities

WRED looks at packet DSCP values and applies different thresholds:

• CS5 (High Priority) – Packets marked CS5 are dropped only when the queue is almost full, ensuring reliable delivery.

• CS4 (Medium Priority) – Dropped earlier as the queue grows, but still treated better than low-priority traffic.

• CS3 (Low Priority) – Dropped aggressively as soon as the queue passes its minimum threshold, freeing space for more important packets.

Figure 7 – WRED profiles with DSCP priorities

Example: WRED in Action

Let’s imagine three classes of traffic entering a congested interface:

• CS3 (Low Priority) → Dropped once the queue exceeds 25 packets.

• CS4 (Medium Priority) → Dropped once the queue exceeds 30 packets.

• CS5 (High Priority) → Dropped only after the queue exceeds 35 packets.

This way:

• CS3 is sacrificed first.

• CS4 is moderately affected.

• CS5 is protected until the very end.

The graph illustrates how WRED selectively drops packets based on queue depth and DSCP marking:

• Low-priority packets → dropped aggressively.

• Medium-priority packets → dropped less often.

• High-priority packets → dropped only as a last resort.

6. Conclusion

Congestion avoidance is about anticipating problems instead of reacting to them.
While tail drop only reacts when a queue is already full, RED and WRED prevent this by managing packet loss earlier and more intelligently.

• WRED – Improves RED by protecting high-priority traffic and dropping low-priority traffic first, ensuring that critical applications remain stable during congestion.

• RED – Drops packets proactively to avoid full queues and reduce global synchronization, but treats all traffic equally.

Summary Table

Table 1 - Congestion Avoidance Summary