Delay-based Congestion Control Schemes for the Internet

1. Delay-based Congestion Control Schemes for the Internet Pu Jian Supervisor: Prof. Mounir Hamdi HKUST 13 October 2005

2. Congestion Control (CC) in TCP • The stability of today's Internet relies on the congestion control built into the Transmission Control Protocol (TCP). • 1974, the original TCP is introduced, but does not contain congestion control mechanism. • 1986, congestion collapse is observed. • 1988, Van Jacobson devised the congestion control algorithm for TCP. • V. Jacobson, "Congestion avoidance and control," in Proceedings of ACM Sigcomm, 1988.

3. Window-based CC • TCP maintains a congestion window (cwnd) governing how many bytes of data a sender may send without acknowledgment from the receiver. • adapt cwnd to the capacity of the network • AIMD: Additive Increase Multiplicative Decrease • TCP throughput can be estimatedusing cwnd cwnd: congestion window size (Bytes) RTT: Round-Trip Time

4. Problem in AIMD • In AIMD, cwnd increases by 1 packet per RTT if no congestion happen • take a long time to acquire available bandwidth • e.g., 2 flows share a 10Gbps link, 200ms RTT, 1500 Bytespacket size • one flow finishes available bandwidth is 5Gbps • the other flow needs 16,667 s (or 4.63 hours) to acquire the available bandwidth

5. Problem inPacketLoss • Congestion-related loss: • large window requires extremely low loss rate  unsustainable in practice • “For a standard TCP connection with 1500-byte packets and a 100 ms round-trip time, achieving a steady-state throughput of 10 Gbps would require … a packet drop rate of at most one congestion event every 5,000,000,000 packets (or equivalently, at most one congestion event every 1 2/3 hours).” (S. Floyd) • Non-congestion-related loss: • confuse transport protocols that assume loss as the implicit congestion signal, such as TCP • e.g., low throughput on wireless links

6. Problem in Packet Loss Best possible TCP with no errors (1.30 Mbps) TCP Reno (280 Kbps) Sequence number (bytes) Time (s) 2 MB TCP transfer over 2 Mbps Lucent WaveLAN (from Hari Balakrishnan)

7. Other Loss-based CC • TCP (AIMD): • HighSpeed TCP: • Scalable TCP (MIMD):

8. XCP • Explicit Control Protocol (XCP) is a congestion control protocol designed for high bandwidth-delay-product networks. • proposed by MIT people in 2002 • generalize the Explicit Congestion Notification (ECN) proposal • router-assistant • decouple utilization control from fairness control • To control congestion: use MIMD which shows fast response • To control fairness: use AIMD which converges to fairness

9. TCP congestion control performs poorly as bandwidth or delay increases 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 Bottleneck Bandwidth (Mb/s) Round Trip Delay (sec)

10. Round Trip Time Round Trip Time Congestion Window Congestion Window Feedback Feedback Congestion Header How does XCP Work? Feedback = + 0.1 packet

11. Round Trip Time Congestion Window Feedback = + 0.1 packet How does XCP Work? Feedback = - 0.3 packet

12. How does XCP Work? Congestion Window = Congestion Window + Feedback XCP extends ECN Routers compute explicit feedback on window increment/decrement

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

14. 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) the details … Congestion Controller Fairness Controller No Per-Flow State No Parameter Tuning

15. Performance of XCP • Simulations show that XCP outperforms TCP in both conventional and high bandwidth-delay-product environments. • fair bandwidth allocation • high utilization • small standing queue size • near-zero packet drops

16.  and  chosen to make XCP robust to delay XCP increases proportionally to spare bandwidth XCP Remains Efficient as Bandwidth or Delay Increases Utilization as a function of Bandwidth Utilization as a function of Delay Avg. Utilization Avg. Utilization Bottleneck Bandwidth (Mb/s) Round Trip Delay (sec)

17. Start 40 Flows Start 40 Flows Stop the 40 Flows Stop the 40 Flows XCP Shows Faster Response than TCP

18. (RTT is 40 ms 330 ms ) XCP is Fairer than TCP Same RTT Different RTT Avg. Throughput Avg. Throughput Flow ID Flow ID

19. Problem in XCP • Unfair to new or short flows • new flows get a small bandwidth allocation • prolong the duration of short flows • Complex per-packet computation • require at least 1 division and 3 multiplications per-packet (if ignore addition and subtraction) • add heavy computing burden to routers • 5 M mul/div per second for one 10 Gbps interface (if packet size 1000 Bytes)

20. RCP • Rate Control Protocol (RCP) is a congestion control protocol emulatingProcessor Sharing (PS) • proposed by Stanford people in 2005 • The router assigns a single rate to all flows that pass through it. • The router does not store per-flow state, and does no per-packet calculations. • feedback is computed periodically, not per-packet

21. RCP – Framework

22. RCP – Rate Update Algorithm

23. RCP vs. TCP vs. XCP

24. Flow Completion Time

25. Problem in RCP • Inaccurate estimation of the number of flows: N(t) = C / R(t-d0) • It is true only when the link has just been filled up by flows and queue size is 0; • Otherwise, either overestimate or underestimate the flow number. • Thus, affect convergence and link utility.

26. Throughput - RCP

27. Link Utility - RCP

28. QSFCP • Quick-Start Flow Control Protocol (QSFCP) • Use the same framework as XCP and RCP • Feedbacks from routers piggy-backed on ACKs • Rate Upgrade Formula:

29. Throughput - QSFCP

30. Link Utility - QSFCP

32. QSFCP is robust to variant RTTs

33. Compare with XCP

34. Evaluation of QSFCP • Don’t store any per-flow state • No per-packet calculation • Quick Start • high initial sending rate • fair to new arrival flows • shorten the duration of flows • Quick Convergence • fast response to congestion • fast redistribute available bandwidth to flows • fair to long-lived flows • e.g., multimedia flows who don’t care duration but bandwidth

35. List of Protocols • TCP (1988) • HighSpeed TCP (2002) • Scalable TCP (2002) • XCP (2002) • RCP (2005) • QSFCP (unpublished)

36. Conclusions • CC in TCP is not suitable for high-speed, high-delay, or lossy networks. • Simply making network faster doesn’t help • Flow performance (durations, throughput, etc.) is also constrained by CC protocols. • New CC is needed for the future networks. • high-speed links, wireless links, satellite links • fairness, short convergence time, high utility, low drop rate, small queue size

37. Tank you!