TCP Congestion Control Beyond Bandwidth-Delay Product for Mobile - PowerPoint PPT Presentation

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 CoNEXT ’17 Seoul, Incheon

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 CoNEXT ’17 Seoul, Incheon

Why Traditional TCP does not work IN MOBILE/CELLULAR NETWORKS 4

1. Large/ Deep buffers Buffer overflow Lack of congestion signal Reno CUBIC Packets in flight (buffer) Cwnd Deep buffer causes high latency (hundreds of ms) Actual RTT Time 5 CoNEXT ’17 Seoul, Incheon

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 CoNEXT ’17 Seoul, Incheon

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 CoNEXT ’17 Seoul, Incheon

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 Our Insight: ◦ Try to forecast the condition (Sprout, PROTEUS, Verus, etc.) Timely estimation of the bandwidth + quick reaction to new network ◦ Try to build a model (PCC, Remy) condition is sufficient 8 CoNEXT ’17 Seoul, Incheon

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 CoNEXT ’17 Seoul, Incheon

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 CoNEXT ’17 Seoul, Incheon

Estimating Receive Rate Receiver will send ACK when packet Sender Receiver is received ACK will be timestamped Compute rate by TSval = t r0 ◦ comparing timestamps: t r1 – t r0 = Δ t Δ t Δ ACK/ Δ t = ρ ◦ and bytes ACK: TSval = t r1 11 CoNEXT ’17 Seoul, Incheon

Estimating Buffer/ Queuing Delay Receiver Sender t snd Queuing delay Relative delay t buff = RD – RD min RD = t ack – t snd Actual delay ( RD min ) t ack TSval = t ack Only relative increase/decrease of t buff matters 12 CoNEXT ’17 Seoul, Incheon

Putting it together Estimate Receive Rate/Bandwidth Pure Rate-based Mechanism Detect Congestion from Queuing delay 13 CoNEXT ’17 Seoul, Incheon

Self-oscillating feedback loop Increase in queuing delay 1 Slow S Start rt t buff > T Send burst of Link Congested 10 packets 3 2 Buffer Fi r Fill State Buff ffer D Drain Sta tate ρ and t buff Send faster than Send slower than Estimate constantly updated bandwidth bandwidth bandwidth (ρ) ( σ f > ρ ) ( σ d < ρ ) Decrease in queueing delay t buff < T No Congestion 14 CoNEXT ’17 Seoul, Incheon

Packet Trace, aka Sawtooth Buffer Buffer Fill Takes at least 1×RTT Drain State to get feedback on State queuing delay delay Packets in buffer/ Queuing Delay Latency oscillates T between the peaks and throughs delay Time 15 CoNEXT ’17 Seoul, Incheon

PropRate Sending rate is a proportion of bandwidth/receive rate ◦ σ f = k f ρ ◦ σ d = k d ρ Three parameters controls the sawtooth ◦ k f – proportion to fill buffer ◦ k d – proportion to drain buffer ◦ T – threshold for switching state 16 CoNEXT ’17 Seoul, Incheon

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 CoNEXT ’17 Seoul, Incheon

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 CoNEXT ’17 Seoul, Incheon

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 CoNEXT ’17 Seoul, Incheon

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 CoNEXT ’17 Seoul, Incheon

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 CoNEXT ’17 Seoul, Incheon

Parameters Throughput is maximum because buffer is always filled Average latency can be adjusted Packets in buffer/ Queuing Delay T Average latency Time 22 CoNEXT ’17 Seoul, Incheon

Parameters Throughput is maximum because buffer is always filled Average latency can be adjusted Packets in buffer/ Queuing Delay T Average latency Time 23 CoNEXT ’17 Seoul, Incheon

Two optimization modes Optimizing for Throughput Optimizing for Latency ◦ Buffer to be kept filled ◦ Buffer needs to be emptied ◦ Reduced utilization  reduced ◦ Implies maximum throughput throughput ◦ Latency suffers due to queuing delay ◦ More responsive latencies Queuing Delay T Average Average latency T latency Time Time 24 CoNEXT ’17 Seoul, Incheon

Please read our paper Parameter tuning ◦ Specify target latency to set the parameter Updating Threshold ◦ Due to network volatility Some math 읽으십시오 25 CoNEXT ’17 Seoul, Incheon

Evaluation 26

Performance Evaluation 1. Compare with other TCP Two Scenarios protocols 1. Emulated networks ◦ Traditional TCP: CUBIC, Vegas, Westwood, LEDBAT 2. Real cellular networks ◦ State-of-art Mobile: Sprout, PCC, Three flavours of PropRate Verus, BBR Low, Medium, High 2. Delayed ACK/Saturated Uplink + Frontier 3. Throughput vs Delay tradeoff Enumerate parameter space 4. Fairness/Contention 5. Computation overhead 27 CoNEXT ’17 Seoul, Incheon

Trace-based Emulation Keep network constant – for fair comparison Cellsim Emulator (from MIT) Cellsim Mobile Server wired wired uplink 1010 Actual Network Traces 0010 downlink 0101 ◦ Three local cellular ISPs 1100 1011 ◦ Two scenarios: stationary (in our lab) and mobile (on a bus) ◦ MIT traces [Winstein et al.] 28 CoNEXT ’17 Seoul, Incheon

Results – Local ISP, Stationary Good throughput/Bad latency Good latency/ Bad throughput 29 CoNEXT ’17 Seoul, Incheon

Results – Local ISP, Mobile Good throughput/Bad latency Good latency/ Bad throughput 30 CoNEXT ’17 Seoul, Incheon

Results – Real LTE Network 31 CoNEXT ’17 Seoul, Incheon

Results PropRate more optimal than other TCP variants ◦ Achieves higher throughput ◦ or, lower latency 32 CoNEXT ’17 Seoul, Incheon

Congested/ Saturated Uplink Mobile Server LTE USB Tether Smartphone congested uplink downlink 33 CoNEXT ’17 Seoul, Incheon

Congested Uplink – Real LTE Network 34 CoNEXT ’17 Seoul, Incheon

Results PropRate more optimal than other TCP variants ◦ Achieves higher throughput ◦ or, lower latency Decoupling ACK clocking improves resilience ◦ Towards asymmetric links 35 CoNEXT ’17 Seoul, Incheon

Performance Frontiers 36 CoNEXT ’17 Seoul, Incheon

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 CoNEXT ’17 Seoul, Incheon

Fairness – Self Contention 38 CoNEXT ’17 Seoul, Incheon

Fairness – Contention from others 39 CoNEXT ’17 Seoul, Incheon

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 CoNEXT ’17 Seoul, Incheon

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 CoNEXT ’17 Seoul, Incheon

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 CoNEXT ’17 Seoul, Incheon