Types of RED Queue Disciplines

Random early detection (RED), also known as random early discard or random early drop is a queuing discipline for a network scheduler suited for congestion avoidance. There are different types of RED Queue Disciplines:

• Gentle RED
• Nonlinear RED
• Self Configuring RED
• Adaptive RED Queue Discipline

Gentle RED:

Random Early Detection algorithm increases the drop probability from 0.05 to 0.50 when the average queue length increases from minimum threshold value to maximum threshold value linearly. But when the average queue length increases slightly beyond the maximum threshold the packet drop probability increases directly from 0.50 to 1. This sudden jump is non-gentle. This sudden jump is normalized by the gentle RED algorithm. 

This behavior leads to aggressive packet drops i.e., when average queue length increases beyond the max_th, the drop probability sharply rises to 1.

Working of Gentle RED:

Gentle RED tries to flatten this curve with a slope similar to the original RED when the average queue length is between max_th and twice of max_th. We can calculate the slope of the RED curve and Gentle RED curve easily. The slope of RED is around 79 degrees and the Gentle RED slope is around 73 degrees. The working of Gentle RED is the same as of RED, it just increases the drop probability from 0.5 to 1 linearly.

Calculation of Average Queue Length:

On arrival of every packet, RED calculates the average queue length using Eq. (1). This mathematical model is known as ‘Exponential Weighted Moving Average’ or EWMA.

=> newavg = (1 – wq) x oldavg + wq x current_queue_len Eq. (1)

=> where, newavg = new average queue length being calculated in this sample.

=> oldavg = old average queue length obtained during the previous sample

=> current_queue_len = ‘instantaneous’ queue length at the router

=> wq = weight associated with the ‘current_queue_len’. 

=> Default value: 0.002

Calculation of Drop Probability:

Once the ‘newavg’ is calculated, RED uses the following logic to calculate the drop probability (Pd), where min_th represents the minimum threshold for ‘average queue length’ and max_th represents the maximum threshold for ‘average queue length’. min_th and max_th are in the context of average queue length, not the instantaneous queue length. This is an important takeaway before we go into further depth.

=>  default value of minth in the paper is 5 packets

=> if (newavg ≤ min_th)   enqueue the incoming packet  

=>  default value of maxth in the paper is 15 packets

=> else if (newavg > 2*max_th)  it means Pd= 1 

=> drop the incoming packet   

=> else if(min_th < newavg < max_th)

=> P_d= max_p x [(newavg – min_th) ÷ (max_th – min_th)] 

=> else if(max_th < newavg < 2*max_th)

=> P_d= max_p + (1-max_p) x [(newavg – max_th) ÷ max_th]  where, maxp = maximum drop probability. 

=> Default: 0.5 (previously, it was 0.02)

 Nonlinear RED and Self Configuring RED:

Instead of increasing the P_d linearly, it might be better if P_d is increased slowly when it is near to min_th and increased sharply when it is near to max. If drop probability increases linearly between minimum threshold and maximum threshold then there is a high chance that incoming packet might get dropped even if the average queue length is not large. So, to get the high probability of dropping the packet when the average queue size is nearer to the maximum threshold researcher went on to do the experiments and came up with the quadratic equation for calculating the drop probability when the average queue length is more than the minimum and less than maximum threshold value.

Working of Nonlinear RED:

=> P_d= 0, when newavg <= min_th

=> P_d= 1, when newavg < max_th

=> P_d= (max_p‘)2 * [(newavg – min_th)/(max_th – min_th)] where max_p‘ = 1.5 * max_p = 0.75

Working of Self Configuring RED:

=> It adapts max_p as shown in the pseudocode below: On every update of ‘newavg’:

=> if (min_th < newavg < max_th)

=> status = between;

=> else if (newavg < min_th && status != below)

=> status = below;

=> max_p = max_p ÷ ? 

=> else if (newavg > max_th && status != above)

=> status = above;

=> max_p = max_p x ?

Is there an upper and lower limit for max_p in this algorithm? In the original paper, the lower bound used was 0.02 and the upper bound used was 1.

Adaptive RED Queue Discipline:

The motivation of Adaptive RED is the same as self-configuring RED. Self-configuring RED tries to keep the average queue size with minimum and maximum threshold values. But Sally Floyd says that why don’t keep the average queue size in a tight range just in the center of minimum and maximum threshold values. Also, Adaptive RED removes the knobs and automatically sets them. Maximum drop probability is adapted based on the network availability, it is no longer a knob just like previous versions of RED. 

Main contributions in Adaptive RED

• Automatic setting of minimum threshold (min_th). It is set as a function of the link capacity (C) and target queue delay.
• Automatic setting of maximum threshold (max_th). It is set depending on the value of min_th.
• Automatic setting of wq. It is set as a function of the link capacity (C).
• The adaptive setting of max_p. It is adapted according to the current average queue length.

Adaptive RED vs Self Configuring RED

1. max_p is adapted not just to keep the average queue size between min_th and max_th, but to keep the average queue size within a ‘target range’ halfway between min_th and max_th. Average queue size can fluctuate on a large range in self-configuring due to which packet drops is likely to happen frequently. But what adaptive RED does is that it keeps the average queue size almost constant because it fluctuates in a very close target range which is just half of the minimum and maximum threshold values.

Example: 

=> if minth = 5 packets and maxth = 15 packets, 

=> then: target range = [minth + 0.4 x (maxth – minth),  minth + 0.6 x (maxth – minth)]

=> Hence, target range = [5 + 0.4 (15 – 5), 5 + 0.6 (15 – 5)] = [9, 11]

=> The average queue size will take the values 9, 10, and 11 always. There is no large fluctuation. 

2. maxp is adapted slowly, over time scales greater than a typical round-trip time, and in small steps. Max drop probability is not adapted very frequently. It is adapted in every 500 ms which is typically 4-5 RTT worth of time.

3. maxp is constrained to remain within the range [0.01, 0.5] (i.e., 1% to 50%). Self-configuring RED keeps max drop probability in range (0.02 to 1).

4. AIMD policy is used to adapt maxp, unlike MIMD policy which is used in Self Configuring RED. The max drop probability is increased additively and decreased multiplicatively unlike self-configuring where both were multiplicative.

Automatic setting of minimum threshold (min_th)

• What happens if the min_th is set to a low value? Degradation of throughput. The main goal of RED is to maximize throughput and minimize queue delay time. If the minimum threshold is set to a low value, then the link will not be fully utilized thus throughput will be less which violates the basic goal of the RED algorithm.
• What happens if the minth is set to a high value? Queue delay increases. If a large value is used for the minimum threshold then the queue will be full most of the time and it will increase the queuing delay of packets. Again this violates the goal of RED. So, Sally Floyd says that the minimum threshold must to chosen carefully and it should fulfill the goals of RED.
• What is the best approach to estimate a suitable value for the min_th? Set the min_th to be a function of the link capacity (C). Why? If we fix the min threshold value, say 5, then if the link is slow then it will take more time to pump these 5 packets and it will increase the queuing delays. If the link is high, these 5 packets will be pumped in a short time and now the queue is empty or less occupied. So it will lead to loss of throughput. This minimum threshold should be set according to the available link. Hence, If the link is slow, an incorrect setting of minth can lead to high queuing delays and if the link is fast, incorrect setting of min_th can lead to loss of throughput.

Decide upon a suitable ‘target queue delay’ (i.e., acceptable queue delay). Network admin knows the bandwidth available, we can decide how much delay we can tolerate. Say 5 ms, which means once a packet is enqueued it must leave within 5 ms time. Hence, set the min_th to be a function of the target queue delay.

=> min is calculated as:

=> min_th = (target_queue_delay x C) ÷ 2 

=> where, C = capacity of the link in packets (can be obtained by: Bandwidth ÷ packet size), target_queue_delay is 5ms (is a user configurable parameter)

=> Sally Floyd’s recommendation to set the minth automatically is:

=> min_th = max [5, (target_queue_delay x C) ÷ 2]

=> min_th of 5 packets was found to work well for low and moderate link capacity. So minth of at least 5 packets is recommended to ensure that the throughput is not affected.

Automatic Setting of Maximum Threshold (max_th):

=> max_th is calculated as:

=>  max_th = 3 x min_th

=> This ensures that the ‘target range’ for average queue size is 2 x min_th

=> Suppose, if min_th = 5 packets and max_th = 15 packets, 

 => then target range = [min_th + 0.4 x (max_th – min_th), min_th + 0.6 x (max_th – min_th)]

 => Hence, target range = [5 + 0.4 (15 – 5), 5 + 0.6 (15 – 5)] [9, 11] 

Automatic setting of wq:

• wq is set to be a function of the link capacity (C):

wq= 1 - e(-1/C)

where, C is the link capacity in packets/second (i.e., Bandwidth ÷ packet size). If C is a big value then Wq will be a too-small value. Another way, if C is small then Wq will be larger.

=> The significance of Wq is that: 

=> If the queue size changes from one value (old) to another (new), say 

=> 60 to 61, 0 to 1 or 50 to 55 or anything then, it takes “-1 / ln (1 – wq)” packet arrivals for the ‘average queue size’ to reach 63% of the ‘new queue size’.

=> If current queue size changes from 60 to 61 and Wq=0.002 then if 

=> current queue size remains constant for 500 packet arrivals then average queue size will become 63% of current queue size, i.e. 38.

• Thus, “-1 / ln (1 – wq)” is referred to as a ‘time constant’ of the estimator for the average queue size (but it is specified in packet arrivals, and not actually in time).
• Example: if wq= 0.002, it corresponds to 500 packet arrivals. But suppose if the bandwidth available is 1Gbps, 500 packet arrivals account for a small amount of time. Hence, even smaller values of wq would be better.

Adapting max_p:

=> It is adapted in every 500 ms. 

=> Every interval seconds: if(average_queue_size > target_range and maxp < 0.5)

=> increase maxp;

=> maxp <- maxp + α

=> else if(average_queue_size < target_range and maxp > 0.01)

=> decrease maxp;

=> maxp <- maxp * β

=> interval: 0.5 second

=> target_range: [minth + 0.4(maxth – minth), 

=> minth + 0.6(maxth – minth)]  

=> α: increment factor, α = min(0.01, maxp/4)

=>β: decrement factor, β = 0.9