Advanced Computer Networking Active Queue Management

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

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

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

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

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

RED/ECN Router Mechanism 1 Dropping/Marking Probability maxp minth maxth Queue Size Average Queue Length behnam shafagaty

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

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

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

RED parameter settings wq suggest 0.001 <= wq <= 0.0042 authors use wq = 0.002 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

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

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

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

{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

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

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. 1320-1328, March, 1999, New York, NY ARED = Adaptive RED behnam shafagaty

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

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. 1346-1355, 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

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

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

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

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

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

TCP/AQM Models behnam shafagaty

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

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

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

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