AQM & TCP models

1. AQM & TCP models Courtesy of Sally Floyd with ICIR Raj Jain with OSU

2. Agenda • Queue management • Passive • Active • AQM: RED Variants • ECN • TCP models

3. the majority in router • Passive queue management (PQM) • No preventive packet drop • Buffer level > threshold, drop packets • Two dropping schemes • Tail-drop • Drop-from-front

4. Drop-tail Which is better? Drop-from-front

5. Problems with PQM • A trade-off between the buffer size and QoS • Larger buffer results in higher throughput, but longer delay • Lock out: A single connection monopolises the buffer space • Give rise to fairness problem • Full queue: Queue is full for a long period of time • Long queuing delay Global synchronization

6. Global Synchronization • When queue overflows, several connections decrease congestion windows simultaneously

7. Bias Against Bursty Traffic • Bursty traffic more likely to be dropped average queue length V.S.

8. Objective: Congestion Avoidance • Maintains low delay and high throughput • Average queue size kept low • Actual queue size grows enough to handle: • Bursty Traffic • Transient Congestion

9. Active Queue Management (AQM) • Provide preventive measures to manage a buffer to eliminate problems associated with PQM • Characteristics: • Preventive random packet drop is performed before the buffer is full • The probability of preventive packet drop increases with the increasing level of congestion • Goals: • Reduce dropped packets • Support low-delay interactive services • Avoid lock-out

10. Random Early Detection (RED) • A router maintains two thresholds: • Min_th: • Accept all packets until the queue reaches Min_th • Drop packets with a linear drop probability when the queue is greater than Min_th • Max_th: All packets are dropped with probability of 1 when the queue exceeds this threshold

11. RED Algorithm drop probability 1 Max_drop Q minth maxth

12. Selection of Maximum Drop Probability for RED • Selection of Max_drop significantly affects the performance of RED • Too small: Active packet drops not enough to prevent global synchronisation • Too large: Decreases the throughput • Optimal value depends on number of connections, round trip time, etc. • Selection of an optimal value for Max_drop remains an open issue

13. RED: Calculating Average Queue Size • Use low-pass filter (exponential weighted moving average) • wq should be small enough to filter out transient congestion, and large enough for the average to be responsive

14. RED solves the problems • Drop packets when congestion eminent • Select packets at random • Use average queue length as indicator of congestion • Global synchronization • Transient congestion (short queue) • Bias against bursty Traffic

15. RED Variants • RED variants can be classified into two categories: • Aggregate control • Modifying the calculation of the control variable and/or drop function • Determines packet drop probability • Per-flow control • Configuring and setting RED’s parameters • Addresses fairness problem

16. BLUE (aggregate) • RED: depends only on Q length • For optimal operating point, long Q is necessary • Uses packet loss and link utilisation to measure network congestion directly • Fewer configuration parameters • Advantages: • Reduces packet loss rate • Keeps the gateway queue stable

17. BLUE • Increases marking/dropping prob. • when detects packet loss due to buffer overflow • Decreases marking/dropping prob. • when detects that the marking prob. is too aggressive

18. RED Variants Using Per-Flow Accounting • Flow RED (FRED) • Fair Buffering RED (FB-RED) • XRED • Class-Based Threshold RED (CBT-RED) • Balanced RED (BRED) • Stochastic Fair Blue (SFB)

19. Two variants • FRED (Fair RED) • fairness among TCP connection • uses per-active-flow accounting (flow’s use of buffer space) • Scalability problem • FBRED (Fair Buffering RED) • use of individual bandwidth delay product for each link to modify the packet drop probability • inverse of the bandwidth delay product to calculate Max_drop • inverse of the square root of the bandwidth delay product to calculate Max_drop

20. Explicit congestion notification (ECN)RFC 3168

21. Packet dropped or packet marked • Instead of dropping packets, packets could be marked. Such marking is called ECN (explicit congestion notification) • The benefits of ECN • A packet does not have to be retransmitted. (Not that big of a deal when drop probabilities are small, e.g., 1%) • Has a dramatic effect when congestion window is small. • Because timeout is avoided. • But why is the congestion window small • If it small because the link is heavily congested, ECN might not be possible because the queue might truly be full.

22. ECN in IP header ECT: ECN-capable transport

23. TCP should change for ECN • TCP connection setup • Find out whether endpoints are ECN-capable • To inform sender of congestion • ECN-echo (ECE) flag in TCP header • To inform receiver of window reduction • Congestion Window Reduction (CWR) flag

25. TCP throughput modeling

26. Motivation for TCP Modeling • TCP operating scale is very large • Models are required to gain deeper understanding of TCP dynamics • Uncertainties can be modeled as stochastic processes • Drive the design of TCP-friendly algorithms for multimedia applications • Optimize TCP performance

27. TCP Modeling Essentials • Mainly Reno flavors are modeled • Two main features are modeled • Window dynamics • Packet loss process

28. Packet Loss Process • Packet loss triggers window decrease • Packet loss is uncertain • This uncertainty is typically modeled as a stochastic process • E.g. probability p of losing a packet

29. Window Dynamics • Linear increase and multiplicative decrease is modeled • The standard assumption • X(t) = W(t)/RTT

30. Gallery of TCP Models • Periodic model • Detailed packet loss model • Finite state machine • Fluid flow model • And others…

31. Periodic model

32. receiver W sender TCP Congestion Control: window algorithm Window: can send W packets • increase window by one per RTT if no loss, W <- W+1 each RTT • decrease window by half on detection of loss W <- W/2 1 RTT

33. receiver W sender TCP Congestion Control: window algorithm • Window: can send W packets • increase window by one per RTT if no loss, W <- W+1 each RTT • decrease window by half on detection of loss W <- W/2, when receiving 3 DUPACKs

34. Idealized model: W is maximum supportable window size (then loss occurs) TCP window starts at w/2 grows to W, then halves, then grows to W, then halves… one window worth of packets each rtt to find: throughput as function of loss, RTT TCP throughput/loss relationship loss occurs W TCP window size W/2 period time (rtt)

35. period # packets sent per “period”

36. 1 packet lost per period implies where

37. Detailed packet loss model

38. (TDP)

39. b = 2 (delayed ACK) Xi = total number of rounds in TDP i RTT

41. RTT MSS is not shown

42. TCP as an FSM