1 / 62

Congestion Control and Active Queue Management

Congestion Control and Active Queue Management. Review of TCP Congestion Control A simple TCP throughput formula RED and Active Queue Management How RED works Fluid model of TCP and RED interaction (optional material) Other AQM mechanisms XCP: congestion for large delay-bandwidth product

lovey
Download Presentation

Congestion Control and Active Queue Management

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Congestion Control and Active Queue Management • Review of TCP Congestion Control • A simple TCP throughput formula • RED and Active Queue Management • How RED works • Fluid model of TCP and RED interaction (optional material) • Other AQM mechanisms • XCP: congestion for large delay-bandwidth product • Router-based mechanism • Decoupling congestion control from fairness • DCCP: datagram congestion control protocol • congestion control for non-TCP flows • TCP-Friendly Rate Control (TFRC) Readings: do required and optional readings if interested congestion control and AQM

  2. TCP Congestion Control Behavior TCP runs at end-hosts • congestion control: • decrease sending rate when loss detected, increase when no loss • routers • discard, mark packets when congestion occurs • interaction between end systems (TCP) and routers? • want to understand (quantify) this interaction congested router drops packets congestion control and AQM

  3. Generic TCP CC Behavior: Additive Increase • window algorithm (window W ) • up to W packets in network • return of ACK allows sender to send another packet • cumulative ACKS • increase window by one per RTT W <- W +1/W perACK  W <- W +1 per RTT • seeks available network bandwidth • Ignoring the “slow start” phase during which window increased by one per ACK W <- W +1perACK  W <- 2W per RTT congestion control and AQM

  4. receiver W sender congestion control and AQM

  5. Generic TCP CC Behavior:Multiplicative Decrease • window algorithm (window W) • increase window by one per RTT W <- W +1/W per ACK • loss indication of congestion • decrease window by half on detection of loss, (triple duplicate ACKs), W <- W/2 congestion control and AQM

  6. receiver TD sender congestion control and AQM

  7. Generic TCP CC Behavior:After Time-Out (TO) • window algorithm (window W) • increase window by one per RTT W <- W +1/W per ACK • halve window on detection of loss, W <- W/2 • timeouts due to lack of ACKs -> window reduced to one, W <-1 congestion control and AQM

  8. TO receiver sender congestion control and AQM

  9. Generic TCP Behavior: Summary • window algorithm (window W) • increase window by one per RTT (or one over window per ACK, W <- W +1/W) • halve window on detection of loss, W <- W/2 • timeouts due to lack of ACKs, W <-1 • successive timeout intervals grow exponentially longup to six times congestion control and AQM

  10. Understanding TCP Behavior • can simulate (ns-2) + faithful to operation of TCP - expensive, time consuming • deterministic approximations + quick - ignore some TCP details, steady state • fluid models + transient behavior - ignore some TCP details congestion control and AQM

  11. 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 time (rtt) congestion control and AQM

  12. TCP Throughput/Loss Relationship # packets sent per “period” = W TCP window size W/2 period time (rtt) congestion control and AQM

  13. TCP Throughput/Loss Relationship # packets sent per “period” = W TCP window size W/2 period time (rtt) congestion control and AQM

  14. 1 packet lost per “period” implies: ploss or: TCP Throughput/Loss Relationship # packets sent per “period” W TCP window size W/2 period B throughput formula can be extended to model timeouts and slow start [PFTK’98] (see slide 59 for details) time (rtt) congestion control and AQM

  15. Drawbacks of FIFO with Tail-drop • Sometimes too late a signal to end system about network congestion • in particular, when RTT is large • Buffer lock out by misbehaving flows • Synchronizing effect for multiple TCP flows • Burst or multiple consecutive packet drops • Bad for TCP fast recovery congestion control and AQM

  16. FIFO Router with Two TCP Sessions congestion control and AQM

  17. 1 Marking probability p pmax 0 tmin tmax 2tmax average queue length x Active Queue Management • Dropping/marking packets depends on average queue length -> p = p(x) • Advantages: • signal end systems earlier • absorb burst better • avoids synchronization • Examples: • RED • REM • … • … congestion control and AQM

  18. RED: Parameters • min_th – minimum threshold • max_th – maximum threshold • avg_len – average queue length • avg_len = (1-w)*avg_len + w*sample_len Discard Probability 1 0 min_th max_th queue_len Average Queue Length congestion control and AQM

  19. RED: Packet Dropping • If (avg_len < min_th)  enqueue packet • If (avg_len > max_th)  drop packet • If (avg_len >= min_th and avg_len < max_th)  enqueue packet with probability P Discard Probability (P) 1 0 queue_len min_th max_th Average Queue Length congestion control and AQM

  20. Discard Probability max_P 1 P 0 Average Queue Length queue_len min_th max_th avg_len RED: Packet Dropping (cont’d) • P = max_P*(avg_len – min_th)/(max_th – min_th) • Improvements to spread the drops P’ = P/(1 – count*P), where • count – how many packets were consecutively enqueued since last drop congestion control and AQM

  21. RED Router with Two TCP Sessions congestion control and AQM

  22. Dynamic (Transient) Analysis of TCP Fluids Optional materials (slides 22-33) • model TCP traffic as fluid • describe behavior of flows and queues using Ordinary Differential Equations (ODEs) • solve resulting ODEs numerically congestion control and AQM

  23. Packet Drop/Mark Round Trip Delay (t) Loss Model AQM Router B(t) p(t) Sender Receiver Loss Rate as seen by Sender: l(t) = B(t-t)*p(t-t) congestion control and AQM

  24. A Single Congested Router • focus onsingle bottlenecked router • capacity {C (packets/sec)} • queue length q(t) • discard prob. p(t) • N TCP flows thru router • window sizes Wi(t) • round trip time Ri(t) = Ai+q(t)/C • throughputs Bi(t) = Wi(t)/Ri(t) TCP flow i AQM router C, p congestion control and AQM

  25. - q(t) - x(t) t -> Adding RED to the Model RED: Marking/dropping based on average queue length x(t) 1 Marking probability p pmax tmin tmax 2tmax Average queue length x x(t): smoothed, time averaged q(t) congestion control and AQM

  26. System of Differential Equations Timeouts and slow start ignored Window Size: Loss arrival rate Mult. decrease Additive increase Queue length: Outgoing traffic Incoming traffic congestion control and AQM

  27. Loss probability: Where dp is obtained from the marking profile dx System of Differential Equations (cont.) Average smoothed queue length: Where a = averaging parameter of RED(wth) d = sampling interval ~ 1/C congestion control and AQM

  28. N+2 coupled equations N flows Wi(t) = Window size of flow i Ri(t) = RTT of flow i p(t) = Drop probability q(t) = queue length Equations solved numerically using MATLAB congestion control and AQM

  29. Steady State Behavior • let t → ∞ • this yields • the throughput is congestion control and AQM

  30. A Queue is not a Network Network - set of AQM routers, V sequence Vi for sessioni Round trip time - aggregate delay Ri(t)=Ai+ SvViqv(t) Loss/marking probability -cumulative prob pi (t)= 1-PvVi(1 - pv(qv(t))) Link bandwidth constraints Queue equations congestion control and AQM

  31. 2600 j 2600 j 1300  j t=30 t=90 How well does it work? • OC-12 – OC-48 links • RED with target delay 5msec • 2600 TCP flows OC-12 OC-48 • decrease to 1300 at 30 sec. • increase to 2600 at 90 sec. congestion control and AQM

  32. simulation fluid model instantaneous delay time (sec) Good queue length match congestion control and AQM

  33. window size average window size simulation fluid model simulation fluid model time (sec) time (sec) matches average window size congestion control and AQM

  34. Issues with RED • Parameter sensitivity • how to set minth, maxth, and maxp • Goal: maintain avg. queue size below midpoint between min_{th} and max_{th} • maxth needs to be significantly smaller than max. queue size to absorb transient peaks • maxp determines drop rate • In reality, hard to set these parameters • RED uses avg. queue length, may introduce large feedback delay, lead to instability congestion control and AQM

  35. Other AQM Mechanisms • Adaptive RED (ARED) • BLUE • Virtual Queue • Random Early Discard (REM) • Proportional Integral Controller • Adaptive Virtual Queue • Improved AQMs are designed based on control theory to provide better faster response to congestion and more stable systems congestion control and AQM

  36. Explicit Congestion Notification (ECN) • Standard TCP: • Losses needed to detect congestion • Wasteful and unnecessary • ECN (RFC 2481): • Routers mark packets instead of dropping them • Receiver returns marks to sender in ACK packets • Sender adjusts its window accordingly • Two bits in IP header: • ECT: ECN-capable transport (set to 1) • CE: congestion experienced (set to 1) congestion control and AQM

  37. TCP congestion control performs poorly as bandwidth or delay increases Shown analytically in [Low01] and via simulations Avg. TCP Utilization Avg. TCP Utilization 50 flows in both directions Buffer = BW x Delay RTT = 80 ms 50 flows in both directions Buffer = BW x Delay BW = 155 Mb/s • Because TCP lacks fast response • Spare bandwidth is available  TCP increases • by 1 pkt/RTT even if spare bandwidth is huge • When a TCP starts, it increases exponentially •  Too many drops  Flows ramp up by 1 pkt/RTT, • taking forever to grab the large bandwidth Bottleneck Bandwidth (Mb/s) Round Trip Delay (sec) congestion control and AQM

  38. XCP: eXplicit congestion Control Protocol Solution:Decouple Congestion Control from Fairness High Utilization; Small Queues; Few Drops Bandwidth Allocation Policy congestion control and AQM

  39. Coupled because a single mechanism controls both Example: In TCP, Additive-Increase Multiplicative-Decrease (AIMD) controls both How does decoupling solve the problem? • To control congestion: use MIMD which shows fast response • To control fairness: use AIMD which converges to fairness Why Decoupling? Solution:Decouple Congestion Control from Fairness congestion control and AQM

  40. Characteristics of XCP Solution • Improved Congestion Control (in high bandwidth-delay & conventional environments): • Small queues • Almost no drops • Improved Fairness • Scalable (no per-flow state) • Flexible bandwidth allocation: min-max fairness, proportional fairness, differential bandwidth allocation,… congestion control and AQM

  41. XCP: An eXplicit Control Protocol • Congestion Controller • Fairness Controller congestion control and AQM

  42. Round Trip Time Round Trip Time Congestion Window Congestion Window Feedback Feedback Congestion Header How does XCP Work? Feedback = + 0.1 packet congestion control and AQM

  43. Round Trip Time Congestion Window Feedback = + 0.1 packet How does XCP Work? Feedback = - 0.3 packet congestion control and AQM

  44. How does XCP Work? Congestion Window = Congestion Window + Feedback XCP uses ECN and “Core Stateless” mechanism (i.e. state carried in packet header) Routers compute feedback without any per-flow state congestion control and AQM

  45. AIMD MIMD How Does an XCP Router Compute the Feedback? Congestion Controller Fairness Controller Goal: Matches input traffic to link capacity & drains the queue Goal: Divides  between flows to converge to fairness Looks at aggregate traffic & queue Looks at a flow’s state in Congestion Header Algorithm: If  > 0  Divide  equally between flows If  < 0 Divide  between flows proportionally to their current rates • Algorithm: • Aggregate traffic changes by   ~ Spare Bandwidth • ~ - Queue Size So,  =  davg Spare -  Queue congestion control and AQM

  46. Algorithm: If  > 0  Divide  equally between flows If  < 0 Divide  between flows proportionally to their current rates  =  davg Spare -  Queue Theorem:System converges to optimal utilization (i.e., stable) for any link bandwidth, delay, number of sources if: Need to estimate number of flows N RTTpkt : Round Trip Time in header Cwndpkt : Congestion Window in header T: Counting Interval (Proof based on Nyquist Criterion) Getting the devil out of the details … Congestion Controller Fairness Controller No Per-Flow State No Parameter Tuning congestion control and AQM

  47. Congestion Control without Reliability • So far: congestion control for reliable (TCP-like) data streams • Use AIMD window/rate adjustment • What about “long-lived” UDP flows? • VoIP, video streaming flows • prefer timeliness over reliability • AIMD: too abrupt rate adjustment • DCCP: Datagram Congestion Control Protocol (IETF proposed standard) • Large increase in long-lived UDP flows on Internet • Reduce impact of long-lived UDP flows on TCP flows and among themselves, avoid congestion collapse • Can’t leave it to application developers • May lead to “buggy” implementation, even if they are willing to implement congestion control congestion control and AQM

  48. DCCP Design Goals • Minimalism: • Minimal functionality in line with e2e argument • Few core protocol features, rich in implementation • Leave out other features that can be implemented successfully by apps or intermediate library • Minimize header size • Robustness • in particular to attacks such as DoS • robust and transparent to middleboxes • Framework for modern congestion control • Allow use of a variety of congestion control algorithms • Self-sufficiency • perform congestion control without application intervention • Support timing-reliability trade-offs congestion control and AQM

  49. DCCP Overview • Fundamental Design Choices: • In-band signaling • Alternative: a separate signaling channel • Bi-directional communication • Alternative: one-way data flow • Per-packet sequence number space • including all non-data control packets (even ack pkts!) • Alternative: TCP-like byte stream, per-data pkt • Core Features • Connection management • Synchronization among two end-points • “Negotiation” of congestion control mechanisms • Others: mobility/multi-homed end points, partial checksum congestion control and AQM

  50. 0 8 16 24 source port data offset CsCov (a) res 1 reserved sequence number (low bits) [48 or 24 bits] (b) acknowledgement number checksum sequence number destination port reserved acknowledgment number (low bits) [48 or 24 bits] type (0 to 1008 bytes) head option CCVal DCCP Header Format • generic header: starts every DCCP packet • additional header info depending on packet type possibly followed by options payload starts at data offset congestion control and AQM

More Related