1. Advanced Computer Networking
Active Queue Management

2. TCP & AQM Example congestion measure pl(t) Loss (Reno)
DropTail
RED
REM,PI,AVQ
xi(t)
TCP:
Reno
Vegas
Example congestion measure pl(t)
Loss (Reno)
Queuing delay (Vegas)
behnam shafagaty

3. Active queue management
Main idea :: provide congestion information by some indications.
Issues
How to measure congestion?
How to feed back congestion info?
behnam shafagaty

4. Active Queue Management
Goals:
The primary goal is to provide congestion avoidance by controlling the average queue size such that the router stays in a region of low delay and high throughput.
To avoid global synchronization (e.g., in Tahoe TCP).
To control misbehaving users (this is from a fairness context).
behnam shafagaty

5. Algorithm 1: Drop Tail
FIFO queuing mechanism that drops packets from the tail when the queue overflows.
Introduces global synchronization when packets are dropped from several connections.
behnam shafagaty

6. Early Random Drop Router
Drop level
If the queue length exceeds a drop level, then the router drops each arriving packet with a fixed drop probability p.
Reduces global synchronization
Does not control misbehaving users (UDP)
behnam shafagaty

7. RED/ECN Router Mechanism1
Dropping/Marking Probability
maxp
minth
maxth
Queue Size
Average Queue Length
behnam shafagaty

8. RED Algorithm
for each packet arrival calculate the average queue size avg if minth ≤ avg < maxth calculate the probability pa with probability pa: mark the arriving packet else if maxth ≤ avg mark all the arriving packet.
behnam shafagaty

9. avg - average queue length
avg=(1–wq)xavg+wq xq
where q is the newly measured queue length.
This exponential weighted moving average is designed such that short-term increases in queue size from bursty traffic or transient congestion do not significantly increase average queue size.
behnam shafagaty

10. RED drop probability ( pa )
pb = maxp x (avg - minth)/(maxth – minth)
then
pa = pb/ (1 - count x pb)
Where, count is number of consecutive packets queued since last discard while in the critical region.
behnam shafagaty

11. RED parameter settings
wq suggest <= wq <=
authors use wq = for simulations
minth, maxth depend on desired average queue size
bursty traffic  increase minth to maintain link utilization.
maxth depends on the maximum average delay allowed.
RED is most effective when maxth - minth is larger than typical increase in calculated average queue size in one round-trip time.
“parameter setting rule”: maxth at least twice minth . However, maxth = 3 times minth is used in some of the experiments shown.
behnam shafagaty

12. Packet-marking probability
The goal is to uniformly spread out the marked packets. This reduces global synchronization.
Method 1: geometric random variable
When each packet is marked with probability pb,, the packet inter-marking time, X, is a geometric random variable with E[X] = 1/pb.
This distribution will both cluster packet drops and have some long intervals between drops!!
behnam shafagaty

13. packet-marking probability
Method 2: uniform random variable Mark packet with probability pb/ (1 - count x pb) where count is the number of unmarked packets that have arrived since last marked packet.
behnam shafagaty

14. Method 1: geometric p = 0.02 Method 2: uniform p = 0.01
Result :: marked packets more clustered for method 1  Uniform is better at eliminating “bursty drops”
behnam shafagaty

15. {This is not a robust recommendation.}
Setting maxp
“RED performs best when packet-marking probability changes fairly slowly as the average queue size changes.”
This is a stability argument in that the claim is that RED with small maxp will reduce oscillations in avg and actual marking probability.
They recommend that maxp never be greater than 0.1
{This is not a robust recommendation.}
behnam shafagaty

16. RED Implementation Performance Probabilistically drop packets
Probabilistically mark packets
Marking requires ECN bit (RFC 2481)
Performance
Desynchronization works well
Extremely sensitive to parameter setting
Fail to prevent buffer overflow as #sources increases
behnam shafagaty

17. Variant: ARED (Feng, Kandlur, Saha, Shin 1999)
Motivation: RED extremely sensitive to #sources
Idea: adapt maxp to load
If avg. queue < minth, decrease maxp
If avg. queue > maxth, increase maxp
No per-flow information needed
Feng, Kandlur, Saha and Shin, “A self-configuring RED gateway”, IEEE Infocom, pp , March, 1999, New York, NY
ARED = Adaptive RED
behnam shafagaty

18. Variant: FRED (Ling & Morris 1997)
Motivation: marking packets in proportion to flow rate is unfair (e.g., adaptive vs unadaptive flows)
Idea:
A flow can buffer up to minq packets without being marked
A flow that frequently buffers more than maxq packets gets penalized
All flows with backlogs in between are marked according to RED
No flow can buffer more than avgcq packets persistently
Need per-active-flow accounting
Source: D. Lin and R. Morris, “Dynamics of RED”, ACM Sigcomm, Sept, 1997
FRED = Flow RED
behnam shafagaty

19. Variant: SRED (Ott, Lakshman & Wong 1999)
Motivation: wild oscillation of queue in RED when load changes
Idea:
Estimate number N of active flows
An arrival packet is compared with a randomly chosen active flows
N ~ prob(Hit)-1
cwnd~p-1/2 and Np-1/2 = Q0 implies p = (N/Q0)2
No per-flow information needed
T. J. Ott, T. V. Lakshman, L. H. Wong, “SRED: Stabilized RED”, Infocom’99, pp , March 1999, New York, NY
Heuristics:
sum of all cwnd’s, sum over all sources, should be roughly Q_0, the target buffer occupancy. This implies a random loss probability p.
m(q) is a piecewise constant probability, taking values in {0, p_max/4, p_max}, as a function of instantaneous queue length q.
behnam shafagaty

20. Variant: BLUE (Feng, Kandlur, Saha, Shin 1999)
Idea: perform queue management based directly on packet loss and link utilization rather than on the instantaneous or average queue lengths.
behnam shafagaty

21. REM (Athuraliya & Low 2000) Congestion measure: price
pl(t+1) = [pl(t) + g(al bl(t)+ xl (t) - cl )]+
Embedding: exponential probability function
Feedback: dropping or ECN marking
behnam shafagaty

22. Key features Clear buffer and match rate Sum prices Clear buffer
behnam shafagaty

23. Active Queue Management
pl(t) G(p(t), x(t))
DropTail loss [1 - cl/xl (t)] (?)
RED queue [pl(t) + xl(t) - cl]+
Vegas delay [pl(t) + xl (t)/cl - 1]+
REM price [pl(t) + g(al bl(t)+ xl (t) - cl )]+
x(t+1) = F( p(t), x(t) )
p(t+1) = G( p(t), x(t) )
Reno, Vegas
DropTail, RED, REM
behnam shafagaty

24. Congestion & performance
pl(t) G(p(t), x(t))
Reno loss [1 - cl/xl (t)]+ (?)
Reno/RED queue [pl(t) + xl(t) - cl]+
Reno/REM price [pl(t) + g(al bl(t)+ xl (t) - cl )]+
Vegas delay [pl(t) + xl (t)/cl - 1]+
Decouple congestion & performance measure
RED: `congestion’ = `bad performance’
REM: `congestion’ = `demand exceeds supply’
But performance remains good!
behnam shafagaty

25. TCP/AQM Models
behnam shafagaty

26. TCP & AQM Example congestion measure pl(t) Loss (Reno)
xi(t)
Example congestion measure pl(t)
Loss (Reno)
Queueing delay (Vegas)
behnam shafagaty

27. Macroscopic View of TCP Control
TCP/AQM: A feedback control system C
TCP Sender 1
TCP Receiver 1
TCP Sender 2
TCP Receiver 2
xi(t) τF
q(t) τB
TCP:
Reno
Vegas
FAST
AQM:
DropTail / RED
Delay
ECN
Fluid models are the most commonly used examples.
There are also discrete time models – timescale is not clear in these discrete time model
c: link
behnam shafagaty

28. Fluid Models Assumptions:
TCP algorithms directly control the transmission rates;
The transmission rates are differentiable (smooth);
Each TCP packet observes the same congestion price (loss, delay or ECN)
behnam shafagaty

29. Protocol (Reno, Vegas, RED, REM/PI…)
Outline
Protocol (Reno, Vegas, RED, REM/PI…)
Equilibrium
Performance
Throughput, loss, delay
Fairness
Utility
Dynamics
Local stability
Cost of stabilization
behnam shafagaty