Flow RED (FRED): adapting RED for UDP traffic

Strengths of the RED method
- The Random Early Detection (active) queue method can solve the Synchronized Packet Drop problem (that cause global TCP synchronization)
- Achieves a form of fairness: Packets from each flow have the same drop probability (but this is NOT the form of fairness: that we would want to achieve !!!)

Deficiencies of the RED method

The authors of the paper "Dynamics of Early Random Drop" discovered the following short-comings in RED:

RED has a bias against low band width flows
RED can exhibit unfair behavior among identical flows
RED cannot reduce the transmission rate of UDP flows
(UDP is a less commonly used Transport Protocol that are mostly used to transmit real time data, such as video and audio)
The UDP protocol is concerned about speed and it is completely unconcerned about packet losses
In particular, the UDP protocol will NOT reduce its transmission rate when packets are lost
(It's even worst, UDP does NOT detect packet loss, so it won't even KNOW if some packets are lost)

Categorizing packet flows on the Internet

The data traffic on the Internet is very diverse

Lin and Morris distinguish 3 different categories of flows in their paper "Dynamics of Early Random Drop":

Non-adaptive (UDP) traffic:

Robust TCP flow (large CWND):

Robust TCP flows are TCP flows that is using a large CWND
The TCP connection is transfering a large amount of data (e.g., large file transfer)
An occasional packet loss will be detected and recovered through triple duplicate ACK
(because there is large number packets outstanding that can generate duplicate ACKs)

In a robust TCP flow, packet losses seldom cause timeout recovery
Consequently, robust TCP flows have large CWND values.
(Because they do not perform slow start that makes CWND = 1 !)

Example robust TCP flows: file transfer

BTW, robust TCP flows are called "elephants"

Fragile TCP flows:

Fragile TCP flows are TCP flows with a small CWND
The TCP connection sends data only occasionally
A packet loss will often ends in timeout recovery because there are not enough packets following the lost packet to generate 3 duplicate ACK

In fragile TCP flows, packet losses often cause timeout recovery
Consequently, fragile TCP flows will (keep) use small CWND values

Example: telnet. SSH, HTTP connections

BTW, the fragile TCP flows are called "mice"

Experiment that show the short-comings of RED

Experiment that shows:

RED favors robust flows and is biased against fragile flows

Simulation Network:

Notes:

(Packet size used = 512 bytes)

Competing flows:

4 robust flows
Simulated using very short RTT (6 msec) to increase CWND rapidly
The Advertised Window is set to very high
1 fragile flows
Simulated using large RTT (36 msec) to increase CWND slowly
The Advertised Window is set to 16
The maximum throughput of the fragile flow is then:

Ideal bandwidth sharing

The bandwidth of the bottle neck link is = 45 Mbps

45 Mbps is shared equally among 5 flows:

Each flow should get: 9 Mbps

The maximum throughput of the fragile flow is 0.11 Mbps - well below the fair share.

If RED is fair , then:

the fragile flow should get 0.11 Mbps ....

Simulation result:

Notes:

When Buffer space = 16 packets, the fragile flow obtains 45% of the rightful 0.11 Mbps bandwidth
At best, (when Buffer space = 56 packets), the fragile flow obtains 71% of the rightful 0.11 Mbps bandwidth
Conclussion: RED is unfair to fragile flows

RED can exhibit unfair behavior among identical flows

Simulation Network: (2 identical flows)

The simulation is ran many times

The CWND values of the two identical flows in some of the experiements:

Notes:

CWND values diverges after t = 0.32 sec

Reason:

RED drops packets arbitrarily
Therefore, occasionally muiltiple packets of the same flow are dropped
That flow will perform a slow start while the other flow increases its CWND
One of the flow has become a fragile flow while the other flow remains a robust flow....

The throughput plot of the two identical flows in some of the experiements:

Note:

Throughput alos diverges after t = 0.32 sec

RED is completely useless for controlling UDP flows

Simulation Network: (1 UDP flow with 1 TCP flow)

Notes:

The UDP flow and the TCP flow shares a bottle neck link of 10 Mbps
The UDP flow transmits data at 8 Mbps
Fair sharing:

The Throughput plot for the UDP/TCP experiment:

Result:

The UDP flow's throughput is approximately 8 Mbps
- much higher than the fair share of 5 Mbps
The TCP flow's throughput is about 2 Mbps - much lower than the fair share of 5 Mbps

The Flow RED (FRED) method: Overview

Notable requirement:
(BTW, requiring additional information inside an Internet router will almost always guarantee that your method will only be academically relevant
Because no company will ever put the information in their routers)

FRED uses similar parameters as RED:

min_threshold (queue threshold to start random drop)
max_threshold (queue threshold to start deterministic drop)
max_p (max. random drop probability)
w_q (expontial averaging factor)

FRED's operation:

FRED counts the number of active flows
FRED counts the number of packets in each flow (i.e., per flow accounting)
FRED compute the average number of packets sent per flow (= avgcq)
FRED tries to make sure that:
FRED will penalize flows that has:
(these flows use more than the average)

FRED remembers persistently misbehaving flows :

When a packet is dropped from a flow f, a strike is recorded for flow f.
Packets from flows with 2 or more strikes are more likely to be dropped...

The Flow RED (FRED) method: Implementation Details

Various parameters and variables

Parameters: w_q = 0.002 (exponential factor in averaging queue size) min_th = min. threshold = min(buffer size/4, RTT) max_th = 2 * min_th min_q = safe threshold (no drops) (2 for small buffers, 4 for large buffers)
Global variables (one such variable only): q = current (INSTANTANEOUS) queue size avg = AVERAGE queue size time = current time count = number of packets since last drop avgcq = average queue size / # flows max_q = max. # packets allowed per flow
Per flow variables (one variable per flow): qlen_f = # packets of flow f in queue strike_f = # packets dropped from f
Mapping functions: conn(P) = connection ID of packet P f( time ) = linear function of variable "time"

The Flow RED algorithm for packet arrival:

P = arriving packet
f = conn(P); // connection ID of packet P

The program below processes an arriving packet of flow f

if ( f not found in the "flow state table" ) { qlen_f = 0; // Initial entry for new flow strike_f = 0; } if ( queue = empty ) CalculateQueueLength(); \\ see below // ======================================== // Choose max. number of packets per flow // ======================================== max_q = min_th; // Default choice if ( avg >= max_th ) // Change default when queue is full max_q = 2; // Queue full, allow 2 packets per flow.... black magic ! // ======================================================================= // The following code segment is used to manage NON-ADAPTIVE (UDP) flows: // 1. flow f has more than max_q packet in queue, or // 2. avg queue length is "large" (RED test) and flow f uses more than 2*avg. // 3. flow f uses more than avg. and flow f has been misbehaving // ======================================================================== if ( qlen_f >= max_q || ( avg >= max_th && qlen_f >= 2*avgcq ) || ( qlen_f >= avgcq && strike_f >= 2 ) ) { drop packet P; strike_f ++; return; // Note: terminate algorithm ! } // ================================================================== // The following code segment is used to manage ADAPTIVE (TCP) flows: // ================================================================== if ( min_th <= avg < max_th ) { // CASE 1: Random drop mode count++; // Count increases drop probability and // makes sure we drop ASAP /* ----------------------------------------- Drop ONLY from Robust flows !! Do NOT drop packets from fragile flows !!! ------------------------------------------ */ if ( qlen_f >= min_q && qlen_f >= avgcq [flow is deemed robust] ) { // Calculate Drop Probability (same as RED) avg - min_th p_b = ------------- max_th - min_th p_b p_a = ---------------- *** bug in RED fixed (see *** below) 1 - count * p_b if ( random() < p_a ) { drop packet P; count = 0; return; } } } else if ( avg < min_th ) { // CASE 2: NO drop mode count = -1; // *** They corrected a BUG in RED // Count should be 0 the first time we use p_a } else [ i.e. avg > max_th ] { // CASE 3: FULL QUEUE drop mode (always drop) drop packet P; count = 0; return; } // ----------------------------------- // Check if flow f is still active... // ----------------------------------- if ( qlen_f == 0 ) { NActive--; Delete flow f's state from state table }

Flow RED packet transmission algorithm:

P = transmitted packet
f = conn(P)

The program below processes an arriving packet of flow f

CalculateQueueLength(); \\ see below if ( qlen_f == 0 ) { NActive--; Delete flow f's state from state table }

Average Queue Length computation in the FRED method

When does RED compute avg. queue length:

RED , compute the average queue length only when a packet arrives

Problem:

The average queue length can be wrong for long period of time

Case in point:

In a period where there are no arrival (and packets are begin transmitted), the queue length is dropping
Yet, the average queue length in RED does not get updated

Changes in FRED queue update algorithm:

The average queue length is computed:
FRED also maintain per flow queue lengths
(I.e., FRED computes the (current) queue length for each flow)

CalculateQueueLength(): compute average queue length

NOTE:

CalculateQueueLength()

FRED

once when a packet is received and
once when a packet is transmitted

- see above algorithms

CalculateQueueLength() { // ------------------------------------------- // This is RED's avg. queue lenght algorithm // ------------------------------------------- if ( q > 0 || packet was transmitted ) { avg = ( 1 - w_q ) * avg + w_q * q; // avg is computed every time a packet is // transmitted (was omitted in RED) } else { m = f ( time - q_idle_time ); avg = (1 - w_q)^m * avg; q_idle_time = time; } // ---------------------------------------------- // Compute the average occupancy for each flow // ---------------------------------------------- if ( NActive > 0 ) { avgcq = avg / NActive; // That's how many packet a flow should have in queue } else { avgcq = avg; // Just a choice the author made... } // Fix "underflow problem" if ( avgcq < 1 ) avgcq = 1; if ( q == 0 || packet was transmitted ) q_idle_time = time; }

Performance Evaluation of the RED method
- FRED can prevent NON-ADAPTIVE from hogging the bandwidth
  4 TCP flows are started at different times: 20 sec, 40 sec, 60 sec and 80 sec.
  Throughput plot:
  - The simulation clearly shows that FRED can effectively drop packets from the un-responsive UDP flow without penalizing the adaptive TCP flows.
- FRED is able to distinguish robust flow and fragile flow:
  Results:
  - Relatively more packets are dropped from the robust flow(s) than from the fragile flow(s)
  - As a result, the fragile flow(s) achieves nearly 100% of its fair share of bandwidth(s)
Final Notes
- The "basic" FRED algorith does not do very well when a large number of (TCP) flows share a bottle neck link.
- If there is a large number of (TCP) flows, the queue in the router may be near its capacity
- When the queue is nearly full, a short burst of packet arrival will cause a queue overflow
- When a queue overflow happens, the FRED algorithm degenerates into drop tail
  And we know that drop tail cannot protect anything.
- The authors propose to allocate 2 packet buffer space for each flow when there are "many" flows (i.e., buffer is nearly full).
- This is a simulation scenario of many (16) TCP flows:
  This is the throughput results using "basic" FRED:
  This is the throughput results using "limited buffer size" FRED:
- We can conclude that - like RED - FRED also have "parameter setting problems" (hard to fix a set of parameters that will be suitable for all situations)