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 X plicit C ontrol P rotocol) 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 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 H_cwnd (set to sender’s current cwnd) H_rtt (set to sender’s rtt estimate) H_feedback (initialized to demands)

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 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) Fairness Controller (FC)

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 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_feedback i = – Basically, positive feedback – negative feedback

XCP Router 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 SenderReceiverRouter Feedback = +10 Feedback = +5

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 80ms 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,

Performance – Feedback delay Bottleneck capacity of 150Mbps 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,

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

Performance – Short Web-like traffic Arrival Rate 0 – 1000 per second Bottleneck capacity 150Mbps Round trip propagation delay 80ms 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 30Mbps Round trip propagation delay 40ms 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, HighSpeed 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 eXplicit Control Protocol (XCP). Published in INFOCOM th Annual Joint Conference of the IEEE Computer and Communications Societies. Proceedings IEEE.