RED Enhancement Algorithms

Presented Approaches
 Flow Random Early Drop - FRED
By Dong Lin and Robert Morris

 Sabilized Random Early Drop – SRED

By Teunis J.Ott, T.V. Lakshman, Larry H.Wong
Basic RED - Reminder
 RED- Random Early Drop : Active queue
management algorithm. Tries to keep the
throughput high while maintaining certain
average queue size. This is done by detecting
incipient congestion by computing the
average queue size and notifying connections
of congestion by dropping packets.
At congestion state equal percent of packets
are dropped for each connection independent
of its bandwidth share usage.
 Addressed Problems
 In case of persistent congestion a
minimal loss for all the connections
exists.
 Temporary non-proportional dropping.
 Non-adaptive connections can force
RED to drop packets at a high rate from
all connections.
 Demonstration of RED’s limitations
 Fragile vs. Robust
 Fragile – congestion aware , sensitive to
packet loss.
 Robust - congestion aware , aggressive.
 Symmetric Adaptive TCPs
 Adaptive TCP vs. Non-adaptive CBR
 Non–adaptive – not congestion aware,
aggressive
 Fragile vs. Robust - Setup
d = 1 ms
R -1 mbps 100
d = 2 ms
R-2 mbps 45
RED
Sink
R-3 gateway

d = 16 ms
R-4 mbps 45
Fragile
 Fragile vs. Robust - Results
Performance of long RTT TCP connection
Bs = 56 BS = 48 BS = 40 BS = 32 BS = 24 Bs = 16
71% 70% 70% 69% 67% 45% BW/MAX
0.940 0.911 0.982 1.03 1.05 0.456 BW%/DROP%
0.32% 0.37% 0.40% 0.42% 0.55% 1.13% Fragile’s Loss
Rate
0.33% 0.35% 0.38% 0.38% 0.44% 0.49% R-1’s Loss Rate

Second row shows the ratio of bandwidth allocated over the 4.05%
.maximum possible
Third row shows ratio of percentage of achieved bandwidth over
.percentage of dropped packets
Fourth and fifth rows show the loss rates of the fragile and one of
the robust connections
Fragile vs. Robust - Conclusion
 Proportional dropping doesn’t guarantee
fair bandwidth sharing.
 Symmetric Adaptive TCPs - Setup
d = 0.274
mbps 155 d = 0.274
Sender 1
mbps 77.5
RED
Sink
Gateway
Sender 2
d = 0.274
mbps 155

Two identical TCP connections compete over a RED gateway with

buffer size 32 packets and minth = 8, maxth = 16, wq = 0.002, maxp = 0.02
Symmetric Adaptive TCPs
 RED can accidentally pick the same
connection from which to drop packets
 RED may drop a packet with non-zero
probability even if the connection has
no packets queued.
 Accounted in small percentage of
traces.
 Adaptive TCP vs. Non-adaptive CBR
d = 2 ms
mbps 8 mbps 10 d=2
CBR mbps 10
RED
Sink
Gateway
TCP
Sender d = 2 ms
mbps 10

Adaptive TCP competes with a CBR UDP over a RED gateway with
buffer size 64 packets and minth = 16, maxth = 32, wq = 0.002, maxp = 0.02
Adaptive TCP vs. Non-adaptive CBR
 The TCP sender cannot obtain its fair share
due to the unfair FCFS scheduling which
distributes the output capacity according to
queue occupancy.
 The RED gateway drops packets from both
connections even if the TCP connection is
using less than its fair share.
 RED is ineffective at handling non­adaptive
connections.
FRED-Flow Random Early Drop
 The goal is to reduce the unfairness
effects found in RED.
 The approach is to generate selective
feedback to a filtered set of connections
which have a large number of packets
queued.
 FRED
 per flow variables:
• qlen - number of buffered packets
• strike – number of time flow didn’t respond to congestion
notification.
 global parameters:
• minq – minimal number of buffered packets per flow
• maxq – maximal number of buffered packets per flow
• avgcq – estimate of average per flow buffer count
 Flows with fewer then avgcq packets queued are favored
over flows with more.
 FRED penalizes flows with high strike values.
Protecting Fragile Flows
 Each connection can buffer minq
packets without loss.
 All the additional packets are subject to
random drop.
 At the same simulation setup as the
first one, the long RTT TCP connection
was able to run at the maximal possible
speed.
 Managing Heterogeneous Robust
Flows
 When the number of active connections is small (N <<
minth/ minq),FRED allows each connection to buffer
minq packets without dropping.
 If the queue averages more than minq packets, FRED
will drop randomly selected packets.
 FRED will impose the same loss rate on all the
connections that have more than minq packets
buffered.
 FRED fixes this problem by dynamically raising the minq
to avgcq when the system is operating with a small
number of active connections.
Managing Non-adaptive Flows
 FRED never lets a flow buffer more then maxq
packets and counts the number of times each
flow tries to exceed maxq
 Flows with high strike are not allowed to
queue more then avgcq packets.
 This allows adaptive flows to send bursts of
packets, but prevents non-adaptive flows
from consistently monopolizing the buffer
space.
Adaptive TCP vs. Non-adaptive CBR
 For the same simulation setup FRED
performed much better.
 FRED limited the UDP connection’s
bandwidth by preventing it from using
more then average number of buffers.
 The TCP connection was able to receive it’s
fair share of the link capacity.
Symmetric Adaptive TCPs
 For the same simulation setup FRED’s
ability to protect small windows has
completely prevented the TCP
connections from losing packets during
ramp up.
 None of the 10000 simulations
produced a retransmission timeout.
FRED - Advantages
 FRED's ability to accept packets preferentially
from flows with few packets buffered achieves
much of the beneficial effect of per­connection
queuing and round­robin scheduling, but with
substantially less complexity.
 FRED is more likely to accept packets from
new connections even under congestion.
 Because TCP detects congestion by noticing
lost packets, FRED serves as a selective binary
feedback congestion avoidance algorithm.
Supporting Many Flows
 Problem- There are more flows then
packets of storage at the gateway.
 The gateway buffers are kept full and
some of the connections are forced to
timeout.
 How to allocate buffers fairly under
these conditions?
FRED- extension
 The timeouts and associated high delay
variation could potentially be eliminated
by adding buffer memory.
 Proposition: When the number of
simultaneous flows is large, the
gateway should provide exactly two
packet buffers for each flow.
FRED Extension- problem
 This extension may cause TCP to
operate with small congestion window.
This can cause trouble for some TCP
implementation that need to receive a
triple Ack to resend a lost packet. If the
window is too small they will need time-
out to recover.
FRED Extension - simulation
 Setup : 16 TCP 100mbps connections
share a gateway with 32 packet buffer
and a bottleneck of 10mbps.
 Results:
 RED caused 2006 timeouts
 FRED with the extension caused 20
timeouts.
Conclusions
 Demonstrated that discarding packets in
proportion to the bandwidth used doesn’t
provide fair bandwidth sharing.
 FRED’s selective dropping based on per-
active-flow buffer count provides fair sharing
for flows with different RTTs and window
sizes.
 FRED protects adaptive flows from non-
adaptive ones by forcing dynamic per-flow
queuing limits.
SRED: Stabilized RED
SRED provides a way to stabilize the gateways
buffer occupation at a level independent of
the number of active connections.
This is done by estimating the number of active
connections without collecting or analyzing
state information on individual flows.
The same mechanism is used to identify
misbehaving flows.
 The Algorithm
 Build a Zombie list:
 as long as the list isn’t full for each arriving packet add
the packet source and destination data to the list, set the
count to zero.
 For each arriving packet (after the Zombie list is full:
 Compare it with a randomly chosen packet from the
Zombie list.
 If the packets are of the same flow declare a Hit and
increase the count.
 If not declare No Hit and with probability p overwrite the
chosen for comparison zombie with the new packets flow.
Observations
 The time it takes for the zombie list to
lose it’s memory can be estimated by
M/p packets.
 If an arriving packet causes a hit this
might be an evidence of misbehaving
flow, if also the count of the zombie is
high the evidence becomes stronger.
 Relationship Between Hits and
Number of Active Flows
Let define :

0 if no hit
and Hit (t )  
 1 if hit

P(t )  (1   ) P(t  1)  Hit (t )

Then P(t) is an estimate of the frequency of hits for
approximately the most M/p packets before packet t.
In this presentation  = 1/M = .001
 Estimation of number of active flows

Proposition : P (t ) is a good estimate for

1

the effective number of active flows in the

time shortly before the arrival of packet t.
 Proposition Argumentation
Suppose there are flows 1,2,… Every time a packet
arrives it belongs to flow i with probability i.
Then for every arriving packet the probability
that it causes a hit is
P{Hit (t )  1}    i
2

There are N active flows of identical traffic intensity:

1 1
i  for 1  i  N this gives P{Hit (t )  1} 
N N
In this symmetrical case, Proposition is exact or at
least roughly unbiased.
Simple Stabilized RED
 No computation of average queue
length.
 Packet loss probability depends only on
the instantaneous buffer occupation
and the estimated number of active
flows.
 Target buffer occupation
 Optimal value of the drop probability p depends on
the number of active flows N.
 Under drop probability p every flow will have a
1

congestion window of the order of p 2
MSSs.
 For N flows the sum of congestion windows will be
1

of the order of N  p 2
.
Target buffer occupation
 The sum of the congestion windows
and Q0 (target buffer occupation) must
be of the same magnitude.
 Let’s require equality:
2

1
 N 
Np 2
 Q0 , or p   
 Q0 
2
 Thus p must be of the order of N
Drop probability function
For packet t, buffer containing q :
1
p zap  psred (q )  min(1, )
(256  P (t )) 2

while  1
if B  q  B
 pmax 3
 1 1 1
psred ( q )    pmax if B  q  B
4 6 3
 0 1
if 0  q  B
 6
Drop probability function
motivation
 Drop probability should depend on the buffer
occupancy.
 psred insures that the drop probability
increases when the buffer occupancy
increases.
 The ratio 4 quadruples the drop probability
when the buffer occupancy increases. =>
Long term effect of halving the congestion
window.
 Drop probability function
motivation - continued
 As can be observed from the drop
probability function :
1
while  P (t )  1
256
psred 1 psred
then p zap     (num of flows) 2

65,536 ( P (t )) 2 65,536
1
when however 0  P (t ) 
256
then p zap  psred
 SRED:Stabilized Random Early Drop
 Simple SRED drop probability depends on:
 Instantaneous buffer occupation q.
 Hit estimate P(t).
 Full SRED drop probability also depends on
whether the packet caused a hit.
Drop probability function
Full SRED drop probability function:
1  Hit (t ) 
p zap  psred  min(1, )  1  
(256  P(t )) 2
 P(t ) 
If a fraction  i of all packets are from flow i,
then for flow i the probability is multiplied by
i
(1  )
j j
2

This increases the drop probability of overactive

flows.
Misbehaving Flows
 Hit mechanism can be used to identify
candidates for misbehaving flows.
 Simulation : 100 persistent TCP flows
and one “misbehaving” UDP.
 Result : UDP connection load is 2.58
times average load of any TCP
connection, hit/packet ratio about 1.74
as large.
Misbehaving Flows-continued
 Even stronger indication of misbehaving
is a hit with a high Count for the zombie.
 For the “overactive” connection a
fraction 0.085 of all hit that have
Count1. For the TCP connection this
fraction is 0.047.
Misbehaving Flows - Conclusion
 Hit indicate a higher probability that the
flow is misbehaving.
 A hit with high count increases the
probability.
 These mechanisms can be used to filter
flows and find a small subset of flows
that are possibly misbehaving.
SRED - Conclusions
 Presented a mechanism for statistically
estimating the number of active flows.
 The mechanism doesn’t require keeping per
flow state.
 Presented schemes for adjusting drop
probability such that the buffer occupancy
hovers around a preset value.
 The mechanism can also be used to identify
misbehaving flows.
SRED: Simulations
 Goal: To show that SRED is successful
in keeping the buffer occupancy close
to a specific target and away from over
flow or underflow.