Congestion Control for High BandwidthDelay Product Networks Dina

Congestion Control for High Bandwidth-Delay Product Networks Dina Katabi, Mark Handley, Charlie Rohrs Presented by Yufei Chen

Future Internet • High Bandwidth Large number of high-bandwidth links • High Latency Satellite and wireless links • Bad news to TCP Oscillatory Prone to instability

TCP’s problems • TCP + any Active Queue Management Instability over high-capacity or large-delay • Additive increase policy Acquire spare bandwidth with one packet per RTT • Short flows transfer delay No improvement with increased link capacity • Fairness Throughput inversely proportional to RTT User with different RTT compete for same bottleneck capacity

Rethink • Packet loss (or not) is poor as signal of congestion. Congestion is not binary, should reflect the degree of congestion. • Aggressiveness of the sources should be adjusted according to the delay in the feedback loop. • The dynamics of aggregate traffic should be independent to number of flows. • Decouple efficiency control (control of utilization or congestion) from fairness control.

XCP (e. Xplicit Control Protocol) • Outperforms TCP in conventional environments • Efficient, fair, stable when bandwidth and/or delay increases • Routers inform senders about degree of congestion • Control utilization according to spare bandwidth & feedback delay • Control fairness by reclaiming bandwidth from flows with higher rate • Put control state in the packets • High utilization, small queues, almost no drops • Error distinguishing, deployable

Congestion header H_cwnd (set to sender’s current cwnd) H_rtt (set to sender’s rtt estimate) H_feedback (initialized to demands) • Filled in by sender H_cwnd – sender’s current congestion window H_rtt – sender’s current RTT estimate • Initialized by sender, modified by routers H_feedback – modified by routers along the path

XCP Sender • Maintains cwnd and rtt • Sets the H_cwnd and the H_rtt fileds of a packet to current cwnd and rtt For the first packet of a flow, H_rtt is set to 0 • Initializes H_feedback based on desired window increase (r * rtt – cwnd) / # packets in window, where r is the desired rate • Update sender’s cwnd when acknowledgment arrives cwnd = max(cwnd + H_feedback, s), where s is the packet size • Response to losses Same as TCP

XCP Receiver • Similar to a TCP receiver • Except when acknowledging a packet, it copies the congestion header from the data packet to its acknowledgment.

XCP Router • Compute the feedback • Optimal efficiency & min-max fairness Efficiency Controller (EC) Fairness Controller (FC) • Estimates over the average RTT of the flows • Average RTT computed with congestion header • Single control decision every average RTT (the control interval)

Efficiency Controller (EC) • Maximize link utilization, minimize drop rate and persistent queues Φ= *d*S– *Q • Φ – aggregate feedback • d – average RTT • S – spare bandwidth • Q – persistent queue size • , – constants, 0. 4 and 0. 226 respectively based on stability analysis

Efficiency Controller (EC) • Maximize link utilization, minimize drop rate and persistent queues Φ= *d*S– *Q • Feedback (Φ) proportional to spare bandwidth (S) and queue size (Q) • Allocate the aggregate feedback to H_feedback in single packets Doesn’t matter which packets get the feedback Doesn’t matter how much congestion window changes for each individual flow As long as total traffic changes by Φ over this control interval

Fairness Controller (FC) • Apportion the feedback to individual packets for fairness • Additive-Increase Multiplicative-Decrease (AIMD) principle Φ > 0, allocate, throughput increases of all flows are the same Φ < 0, allocate, a flow’s throughput decrease is proportional to current throughput. • Bandwidth shuffling for Φ = 0 Simultaneous bandwidth allocation/deallocation – consistent total traffic rate Each flow’s throughput gradually converge to fair share h = max(0, γ * y – |Φ|) y is input traffic in an average RTT, γ = 0. 1 Every average RTT, at least 10% of the traffic is redistributed according to AIMD

Fairness Controller (FC) • Apportion the feedback to individual packets for fairness • Per-packet feedback H_feedbacki = • – Basically, positive feedback – negative feedback

XCP Router Sender Feedback = +10 • Router Feedback = +10 Receiver Feedback = +5 Multiplicative-Increase Multiplicative-Decrease (MIMD) for EC Quickly acquire positive spare bandwidth over high capacity links • Additive-Increase Multiplicative-Decrease (AIMD) for FC Converges to fairness • Simple to implement

Simulation • Packet-level simulator ns-2, extended with XCP module • Compare XCP with TCP Reno • Different queuing disciplines. Random Early Discard (RED) Random Early Marking (REM) Adaptive Virtual Queue (AVQ) Core Stateless Fair Queuing (CSFQ) • Different dropping policies Drop-Tail Random Early Discard (RED) Topology used in most simulations

Performance – Capacity • Round trip propagation delay 80 ms • 50 long-lived FTP flows share a bottleneck • 50 flows with reversed paths to simulate 2 -way traffic environment • XCP near optimal • Independent of link capacity Utilization rate – Bandwidth (Mbps) Plot credit: Behnam Shafagaty, http: //slideplayer. com/slide/4703406/

Performance – Feedback delay • Bottleneck capacity of 150 Mbps • 50 long-lived FTP flows share a bottleneck • 50 flows with reversed paths to simulate 2 -way traffic environment • XCP near optimal • Independent of feedback delay Utilization rate – Round trip delay (sec) Plot credit: Behnam Shafagaty, http: //slideplayer. com/slide/4703406/

Performance – Number of flows • Number of FTP flows 0 - 1000 • Bottleneck capacity 80 Mbps • Round trip propagation delay 80 ms • XCP good utilization, reasonable queue size, almost none packet loss

Performance – Short Web-like traffic • Arrival Rate 0 – 1000 per second • Bottleneck capacity 150 Mbps • Round trip propagation delay 80 ms • 50 long-lived FTP flows share a bottleneck • 50 flows with reversed paths to simulate 2 -way traffic environment • XCP good utilization, reasonable queue size, almost none packet loss

Performance – Fairness • Equal RTT flows vs. Different RTT flows • Bottleneck capacity 30 Mbps • Round trip propagation delay 40 ms • 30 long-lived FTP flows share a bottleneck • XCP has a fair bandwidth allocation and does not have any bias against long RTT flows Flow Throughput (Mbps) – Flows

Security • Requires additional mechanism Same as TCP • Facilitates the job of policing agents Unlike TCP • Faster misbehaving source isolation Policing agent use the explicit feedback to test a source • Easier suspicious flow isolation Router sends the flow a test feedback to require cwnd decrease

Deployment and Summary • Gradual deployment Cloud-based approach XCP in multi-protocol network • XCP is TCP-friendly • Good utilization and fairness, low queuing delay, few packet drops • Viable and practical • Increase efficiency in high bandwidth-delay product environments

Discussion questions • Compare XCP with other high-speed TCP extensions such as Scalable TCP, High. Speed TCP, FAST TCP, and BIC-TCP. • Analyzing and solving the deployment issues of XCP on a wide scale as it require changes to the OS of end hosts and routers. Y. Zhang, T. Henderson. An Implementation and Experimental Study of the e. Xplicit Control Protocol (XCP). Published in INFOCOM 2005. 24 th Annual Joint Conference of the IEEE Computer and Communications Societies. Proceedings IEEE.