TCP Congestion Control Beyond Bandwidth-Delay Product for Mobile Cellular Networks Wai Kay Leong, Zixiao Wang, Ben Leong The 13th International Conference on emerging Networking EXperiments and Technologies
Mobile Internet usage exceeds Desktop 2
What's different about cellular? Negligible random packet losses Hybrid ARQ scheme As compared to 802.11 Wi-Fi Large buffers In the Megabytes Asymmetric uplink/downlink ACK delay Fair scheduling at base station No contention with other users 3
Why Traditional TCP does not work IN MOBILE/CELLULAR NETWORKS 4
1. Large/Deep buffers Cwnd Reno CUBIC Buffer overflow Lack of congestion signal Packets in flight (buffer) Deep buffer causes high latency (hundreds of ms) Actual RTT Time 5
2. Uplink Congestion More predominant in slower 3G/HSPA networks ACK gets delayed in return uplink Stuck in deep buffer/ high volume of users Server is prevented from sending new packet even though downlink is clear Idle link Data ACK 6
Rethink congestion control for mobile networks Traditional TCP congestion control Lack of congestion signal (ECN not popular) Long delay/high latency (CUBIC) ACK clocked Rise in new mobile TCP algorithms Sprout Verus PCC BBR 7
Key Idea Purpose of congestion control is to avoid congestion finding the correct rate to send packets ideally keep 1 BDP packets in transit Why not just send at the correct rate? Vary conditions of mobile networks Try to forecast the condition (Sprout, PROTEUS, Verus, etc.) Try to build a model (PCC, Remy) Our Insight: Timely estimation of the bandwidth + quick reaction to new network condition is sufficient 8
Our Approach Abandon ACK clocking Pure rate-based sending of packets 1. Estimate current bandwidth/receive rate 2. Send packets at estimated rate 3. Observe buffer delay 4. Update send rate Takes advantage of large buffer Congestion with others mitigated by fair scheduling in base station 9
We need a means to 1. Estimate the bandwidth/receive rate 2. Detect congestion by measuring one-way delay Make use of TCP timestamp option Enabled by default on most servers and phones 10
Estimating Receive Rate Receiver will send ACK when packet is received ACK will be timestamped Compute rate by comparing timestamps: t r1 t r0 = Δt and bytes ACK: ΔACK/Δt = ρ Sender Receiver TSval = t r0 TSval = t r1 Δt 11
Estimating Buffer/Queuing Delay Sender Receiver t snd Relative delay RD = t ack t snd Queuing delay t buff = RD RD min Actual delay (RD min ) t ack TSval = t ack Only relative increase/decrease of t buff matters 12
Putting it together Estimate Receive Rate/Bandwidth Detect Congestion from Queuing delay Pure Rate-based Mechanism 13
Self-oscillating feedback loop 1 Slow Start Send burst of 10 packets Estimate bandwidth (ρ) Increase in queuing delay t buff > T Link Congested 2 3 Buffer Fill State Send faster than ρ and t buff bandwidth constantly updated (σ f >ρ) Buffer Drain State Send slower than bandwidth (σ d <ρ) Decrease in queueing delay t buff < T No Congestion 14
Packet Trace, aka Sawtooth Packets in buffer/ Queuing Delay T Buffer Fill State delay Buffer Drain State Takes at least 1 RTT to get feedback on queuing delay Latency oscillates between the peaks and throughs delay Time 15
PropRate Sending rate is a proportion of bandwidth/receive rate σ f = k f ρ σ d = k d ρ Three parameters controlsthe sawtooth k f proportion to fill buffer k d proportion to drain buffer T threshold for switching state 16
Parameters By adjusting the parameters, k f, k d and T, we can change the shape of the sawtooth. Packets in buffer/ Queuing Delay T Average latency Time 17
Parameters By adjusting the parameters, k f, k d and T, we can change the shape of the sawtooth. Packets in buffer/ Queuing Delay T Average latency Time 18
Parameters By adjusting the parameters, k f, k d and T, we can change the shape of the sawtooth. Packets in buffer/ Queuing Delay T Average latency Time 19
Parameters By adjusting the parameters, k f, k d and T, we can change the shape of the sawtooth. Packets in buffer/ Queuing Delay T Average latency Time 20
Parameters By adjusting the parameters, k f, k d and T, we can change the shape of the sawtooth. Throughput is maximum because buffer is always filled Packets in buffer/ Queuing Delay T Average latency Time 21
Parameters Throughput is maximum because buffer is always filled Average latency can be adjusted Packets in buffer/ Queuing Delay T Average latency Time 22
Parameters Throughput is maximum because buffer is always filled Average latency can be adjusted Packets in buffer/ Queuing Delay T Time Average latency 23
Two optimization modes Optimizing for Throughput Buffer to be kept filled Implies maximum throughput Latency suffers due to queuing delay Optimizing for Latency Buffer needs to be emptied Reduced utilization reduced throughput More responsive latencies Queuing Delay T Time Average latency T Time Average latency 24
Please read our paper Parameter tuning Specify target latency to set the parameter Updating Threshold Due to network volatility Some math 읽으십시오 25
Evaluation 26
Performance Evaluation 1. Compare with other TCP protocols Traditional TCP: CUBIC, Vegas, Westwood, LEDBAT State-of-art Mobile: Sprout, PCC, Verus, BBR 2. Delayed ACK/Saturated Uplink 3. Throughput vs Delay tradeoff 4. Fairness/Contention 5. Computation overhead Two Scenarios 1. Emulated networks 2. Real cellular networks Three flavours of PropRate Low, Medium, High + Frontier Enumerate parameter space 27
Trace-based Emulation Keep network constant for fair comparison Cellsim Emulator (from MIT) Mobile wired Cellsim wired Server Actual Network Traces Three local cellular ISPs 1010 0010 0101 1100 1011 uplink downlink Two scenarios: stationary (in our lab) and mobile (on a bus) MIT traces [Winstein et al.] 28
Results Local ISP, Stationary Good throughput/bad latency Good latency/ Bad throughput 29
Results Local ISP, Mobile Good throughput/bad latency Good latency/ Bad throughput 30
Results Real LTE Network 31
Results PropRate more optimal than other TCP variants Achieves higher throughput or, lower latency 32
Congested/Saturated Uplink Mobile USB Tether LTE Server Smartphone congested uplink downlink 33
Congested Uplink Real LTE Network 34
Results PropRate more optimal than other TCP variants Achieves higher throughput or, lower latency Decoupling ACK clocking improves resilience Towards asymmetric links 35
Performance Frontiers 36
Results PropRate more optimal than other TCP variants Achieves higher throughput or, lower latency Decoupling ACK clocking improves resilience Towards asymmetric links Frontier hull shows PropRate is always most optimal 37
Fairness Self Contention 38
Fairness Contention from others 39
Results PropRate more optimal than other TCP variants Achieves higher throughput or, lower latency Decoupling ACK clocking improves resilience Towards asymmetric links Frontier hull shows PropRate is always most optimal PropRate can compete with CUBIC flows 40
Whither the future? Resurgence in interest in TCP Different emergent networks: Datacenter, Wi-Fi, Cellular, etc. Traditional TCP: CUBIC/Compound Floods buffer Increased latency Delay-based algorithms: Vegas, Westwood, etc. Good latency Starved by CUBIC 41
Is TCP ready for rate-based algorithms? Pure rate-based algorithms: PropRate & BBR Handles bufferbloat Compete well against CUBIC Can co-exist with CUBIC Facilitate transition to better rate-based TCP algorithms PropRate builds on a framework More optimal algorithms in the future? Better integration with TCP stack in the future? 42
Thank You 감사합니다 QUESTIONS? 43