CS268: Beyond TCP Congestion Control

Transcription

1 TCP Problems CS68: Beyond TCP Congestion Control Ion Stoica February 9, 004 When TCP congestion control was originally designed in 1988: - Key applications: FTP, - Maximum link bandwidth: 10Mb/s - Users were mostly from academic and government organizations (i.e., well-behaved) - Almost all links were wired (i.e., negligible error rate) Thus, current problems with TCP: - High bandwidth-delay product paths - Selfish users - Wireless (or any high error links) TCP Behavior For Web Traffic (B+98) TCP Reno Fast Recovery Workload: 1996 Olympic Game Site Web servers implement TCP Reno Path asymmetric NAP Cluster: IBM/RS 6000 (Connect by Token Ring) Load balancer cwnd Slow Start Timeout Congestion Avoidance Time Fast recovery Client Fast retransmit: retransmit a segment after 3 DUP Acks Fast recovery: reduce cwnd to half instead of to one 3 4 Findings: Single TCP Solutions: Single TCP Finding 1: retransmission due to % due to fast retransmission - 56.% due to RTOs (6.9% due to RTOs in slow start) Finding : window size is limiting factor in 14% of cases Finding 3: Ack compression is real, and there is a pos. correlation between Ack compression factor and packet loss TCP SACK (Selective Acknowledgement) - Would help only with 4.4% of retransmission timeouts Right-edge recovery - When receiving a DUP Ack send a new packet (why?) - Take care of 5% of retransmission timeouts 5 6 1

2 Available Findings: Parallel TCPs Solutions: Parallel TCPs The throughput of a client is proportional to the number of connection it opens to a server (relevant for HTTP 1.0) - Additive increase factor for n connections: n - Multiplicative decrease factor for n connections: 0.75 TCP-Int: - One congestion window for all TCPs to the same destination - TCPs are served in a round-robin fashion Advantages - New TCPs start faster - Less likely for a loss to cause RTO Disadvantages (?) 7 8 High Delay High Bandwidth Challenges: Slow Start High Delay High Bandwidth Challenges: AIMD TCP throughput controlled by congestion window (cwnd) size In slow start, window increases exponentially, but may not be enough example: 10Gb/s, 00ms RTT, 1460B payload, assume no loss - Time to fill pipe: 18 round trips = 3.6 seconds - Data transferred until then: 38MB - Throughput at that time: 38MB / 3.6s = 850Mb/s - 8.5% utilization not very good Loose only one packet drop out of slow start into AIMD (even worse) In AIMD, cwnd increases by 1 packet/ RTT bandwidth could be large - e.g., flows share a 10Gb/s link, one flow finishes available bandwidth is 5Gb/s - e.g., suffer loss during slow start drop into AIMD at probably much less than 10Gb/s Time to reach 100% utilization is proportional to available bandwidth - e.g., 5Gb/s available, 00ms RTT, 1460B payload 17,000s 9 10 Simulation Results Shown analytically in [Low01] and via simulations Avg. TCP Utilization 50 flows in both directions Buffer = BW x Delay RTT = 80 ms Bottleneck Bandwidth (Mb/s) Avg. TCP Utilization 50 flows in both directions Buffer = BW x Delay BW = 155 Mb/s Round Trip Delay (sec) 11 Proposed Solution: Decouple Congestion Control from Fairness Coupled because a single mechanism controls both Example: In TCP, Additive-Increase Multiplicative- Decrease (AIMD) controls both How does decoupling solve the problem? 1. To control congestion: use MIMD which shows fast response. To control fairness: use AIMD which converges to fairness 1

3 Characteristics of Solution 1. Improved Congestion Control (in high bandwidth-delay & conventional environments): Small queues Almost no drops. Improved Fairness 3. Scalable (no per-flow state) 4. Flexible bandwidth allocation: min-max fairness, proportional fairness, differential bandwidth allocation, XCP: An explicit Control Protocol 1. Congestion Controller. Fairness Controller How does XCP Work? How does XCP Work? Round Trip Round Time Trip Time Congestion Congestion Window Window Feedback Feedback = packet Round Trip Time Congestion Window Feedback = packet Congestion Header How does XCP Work? How Does an XCP Router Compute the Feedback? Congestion Controller Goal: Matches input traffic to link capacity & drains the queue Fairness Controller Goal: Divides between flows to converge to fairness Congestion Window = Congestion Window + Feedback Routers compute feedback without any per-flow state 17 Looks at aggregate traffic & queue MIMD Algorithm: Aggregate traffic changes by ~ Spare Bandwidth ~ - Queue Size So, = α d avg Spare - β Queue Looks at a flow s state in Congestion Header AIMD Algorithm: If > 0 Divide equally between flows If < 0 Divide between flows proportionally to their current rates 18 3

4 Congestion Controller = α d avg Spare - β Queue Theorem: System converges to optimal utilization (i.e., stable) for any link bandwidth, delay, number of sources if: π 0< α < and β = α 4 Details Fairness Controller Algorithm: If > 0 Divide equally between flows If < 0 Divide between flows proportionally to their current rates Need to estimate number of flows N N = 1 T ( Cwnd pkts in T pkt / RTT pkt ) 3 4! ;: 963 <: 6<=! #"%$'&)(+*-,.$."#/0&1" (Proof No Parameter based on Nyquist Tuning Criterion) No Per-Flow State RTT pkt : Round Trip Time in header No Per-Flow State Cwnd pkt : Congestion Window in header T: Counting Interval 19 0 Avg. Utilization XCP Remains Efficient as Bandwidth or Delay Increases Utilization as a function of Bandwidth XCP increases proportionally to spare bandwidth Avg. Utilization Utilization as a function of Delay α and β chosen to make XCP robust to delay XCP Shows Faster Response than TCP Start 40 Flows Stop the 40 Flows Start 40 Flows Stop the 40 Flows XCP shows fast response Bottleneck Bandwidth (Mb/s) Round Trip Delay (sec) 1 Avg. Throughput XCP is Fairer than TCP Same RTT Flow ID Avg. Throughput Different RTT Flow ID XCP Summary > XCP - Outperforms TCP - Efficient for any bandwidth - Efficient for any delay - Scalable (no per flow state) > Benefits of Decoupling - Use MIMD for congestion control which can grab/release large bandwidth quickly - Use AIMD for fairness which converges to fair bandwidth allocation (RTT is 40 ms 330 ms 3 ) 4 4

5 Explicit Problem: Solution: No More Max: Smart Sender if Why Selfish Users Ack Division Motivation - Many users would sacrifice overall system efficiency for more performance - Even more users would sacrifice fairness for more performance - Users can modify their TCP stacks so that they can receive data from a normal server at an un-congestion controlled rate. Problem - How to prevent users from doing this? - General problem: How to design protocols that deal with lack of trust? TCP Congestion Control with a Misbehaving. Stefan Savage, Neal Cardwell, David Wetherall and Tom Anderson. ACM Computer Communications Review, pp , v 9, no 5, October, Robust Congestion Signaling. David Wetherall, David Ely, Neil Spring, Stefan Savage and Tom Anderson. IEEE International Conference on Network Protocols, November 001 sends multiple, distinct acks for the same data one for each byte in payload sender can determine this is wrong 5 6 Optimistic Acking Solution: Cumulative Nonce acks data it hasn t received yet robust way for sender to detect this on its own sends random number (nonce) with each packet sends cumulative sum of nonces receiver detects loss, it sends back the last nonce it received cumulative? 7 8 ECN ECN Congestion Notification - Router sets bit for congestion - should copy bit from packet to ack - Sender reduces cwnd when it receives ack can clear ECN bit - Or increase XCP feedback Multiple unmarked packet states - Sender uses multiple unmarked packet states - Router sets ECN mark, clearing original unmarked state - returns packet state in ack must either return ECN bit or guess nonce nonce bits less likelihood of cheating - 1 bit is sufficient

6 TCP Adding Many Transport Link Selfish Users Summary Conclusion allows selfish users to subvert congestion control a nonce solves problem efficiently - must modify sender and receiver other protocols not designed with selfish users in mind, allow selfish users to lower overall system efficiency and/or fairness - e.g., BGP protocol modifications not deployed - SACK was deployed because of general utility Satellite - FEC because of long RTT issues layer solutions give adequate, predictable performance, easily deployable