TCP Congestion Control Beyond Bandwidth-Delay Product for Mobile Cellular Networks

Transcription

1 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

2 Mobile Internet usage exceeds Desktop 2

3 What's different about cellular? Negligible random packet losses Hybrid ARQ scheme As compared to Wi-Fi Large buffers In the Megabytes Asymmetric uplink/downlink ACK delay Fair scheduling at base station No contention with other users 3

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

5 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

6 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

7 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

8 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

9 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

10 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

11 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

12 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

13 Putting it together Estimate Receive Rate/Bandwidth Detect Congestion from Queuing delay Pure Rate-based Mechanism 13

14 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

15 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

16 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

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 17

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 18

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 19

20 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

21 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

22 Parameters Throughput is maximum because buffer is always filled Average latency can be adjusted Packets in buffer/ Queuing Delay T Average latency Time 22

23 Parameters Throughput is maximum because buffer is always filled Average latency can be adjusted Packets in buffer/ Queuing Delay T Time Average latency 23

24 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

25 Please read our paper Parameter tuning Specify target latency to set the parameter Updating Threshold Due to network volatility Some math 읽으십시오 25

26 Evaluation 26

27 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

28 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 uplink downlink Two scenarios: stationary (in our lab) and mobile (on a bus) MIT traces [Winstein et al.] 28

29 Results Local ISP, Stationary Good throughput/bad latency Good latency/ Bad throughput 29

30 Results Local ISP, Mobile Good throughput/bad latency Good latency/ Bad throughput 30

31 Results Real LTE Network 31

32 Results PropRate more optimal than other TCP variants Achieves higher throughput or, lower latency 32

33 Congested/Saturated Uplink Mobile USB Tether LTE Server Smartphone congested uplink downlink 33

34 Congested Uplink Real LTE Network 34

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

36 Performance Frontiers 36

37 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

38 Fairness Self Contention 38

39 Fairness Contention from others 39

40 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

41 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

42 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

43 Thank You 감사합니다 QUESTIONS? 43