Cellular Controlled Delay TCP C 2 TCP Soheil

Cellular Controlled Delay TCP (C 2 TCP) Soheil Abbasloo, Tong Li, Yang Xu, H. Jonathan Chao New York University

Cellular NWs: New Demands 1200% increase in cellular data traffic from 2012 to 2017! Online shopping Video streaming, … New demands: VR, AR, RT Gaming, … Lower latencies, higher throughputs New designs 2 Fig from “Akamai: (2017) State of the internet. ”

New Trends • Pushing content close to the end-user – Mobile Edge Computing (MEC) – Mobile Content Delivery Networks (MCDN) • Last-Mile is still the problem – for achieving low latency & high throughput 3

Problems in Cellular Networks 1. Channel unpredictability 2. Link fluctuations 4 Traces from: “Stochastic forecasts achieve high throughput and low delay over cellular networks” NSDI’ 13

Problems in Cellular NWs 3. Burst Scheduling Burst of packets are scheduled DL/UP Scheduling Idle UE 1 UE 2 BBU UE N Figs from: Adaptive Congestion Control for Unpredictable Cellular Networks, Sigcomm’ 15 5

Problems in Cellular NWs 4. Bufferbloat – In Mobile network, Bufferbloat exists in both RAN and Core Network functions. – Existing throughput-oriented congestion/rate control mechanisms are loss based – Deep buffers in network will avoid packet losses which are the critical signals for the current throughput-oriented congestion controls Fast link Fluctuations Scheduling Delay Content Server Large per user buffer BBU 6

Client TCP (Cubic) on Cellular NW Egress Delay= 5 ms BBU Ingress 1 Gbps Server Delay=100 us Per Packet Queuing Delay Considering delay, TCP performs poorly over cellular networks even when 500 ms server is at MEC 1000 100 Overshoot 10 Time (s) Queuing Delay (ms) Throughput (Mbps) Queuing Delay 7

Category of Solutions 1. End-to-End Approach Main Intuition: Predict sending rates without knowledge about the network – • Predicting/Modeling channel adds too Sproute “NSDI’ 13”, Verus ”Sigcomm’ 15”, … much complexity! 2. In-Network Approach Main Idea: Redesigning the queue management in the switch – • “Co. Del” Queue’ 12, “CHOKe” Infocom’ 00 1. High CAPEX costs 2. Cannot support diff. Qo. S for diff. flows 3. Parameter tuning issues 8

Category of Solutions 3. Proxy-Based Approach – Making TCP proxy at BBU: Having two separate sessions one from server to BBU, the other 1 -Violation of Layer-4 end-to-end semantic from BBU to UE. each session uses different rate 2 -Application owners don’t like this violation • TCP-Proxy (IEEE Trans. ’ 10) 4. Feedback-Based Approaches – Use explicit feedback from network • CQIC (Hot. Mobile’ 15), pi. Stream (Mobi. Com’ 15), … 1. Implementation complexity 2. Can cause synchronization effect 9

Design Decisions • Design a cellular TCP for ultralow latency and throughput hungry applications while meeting the following objectives: 1. End-to-End solution, Easy to implement 2. Supporting diff. Qo. S for diff. flows 3. Deployment friendly without changing Network equ. 10

Optimal point of operation Optimal: max BW and min RTT (Gail & Kleinrock. 1981) RTT Delivery Rate Loss-Based TCP Bad news: No distributed algorithm can operate there! (Jaff. 1981) BDP In-Flight packets BDP + buff. size 11

Variable Intrinsic Delay in Cellular NWs RTT In-Flight packets Due to link fluctuations and scheduling delays on downlink/uplink, min RTT changes rapidly through time in cellular NWs 12

Main Intuition 1. Get Target delay from applications: – Delay sensitive applications always have a sense about their desired delay 2. Detect Min RTT in a Moving Interval, compare it with Target, &react accordingly RTT Target Interval Time 13

The Good & the Bad Conditions The Past is as important as the We define two states: Good and Bad conditions Present for controlling rates! Bad Condition Starts RTT Observation Interval Bad Condition Ends, Good condition begins Target Value Good Bad Min RTT Time

C 2 TCP • C 2 TCP works as a plugin for loss-based TCP. • Applications can set their own Target RTT & Observation Interval using socket options • C 2 TCP’s main logic: – Let loss-based TCP do its job – However, when bad-condition is detected: • Our scheme will react as if an AQM design were implemented in the switch • Overrule the decision made by TCP 15

More Details: Case 1 Both “Good Condition” & “RTT < Target” 16

More Details: Case 2 Both “Good Condition” & “RTT > Target” Do nothing 17

More Details: Case 3 Inspired by well-known relationship of drop rate to throughput to get a linear change in throughput Jacobson et al. “Red in a different light” 1999 Mathis et al. “The Macroscopic Behavior of the TCP Congestion Avoidance Algorithm”, 1997 Bad Condition 18

C 2 TCP over Cubic 19

Why C 2 TCP works 1. Proactively adjusts the sending rates 2. Tracks dynamics of cellular channel very fast 3. Makes loss-based TCP delay-aware 20

Evaluation • We use C 2 TCP over Cubic (default TCP in Linux/Android) • Cellular Traces: • T-Mobile’s LTE and 3 G UMTS, AT&T’s LTE, and Verizon’s LTE and 3 G 1 x. EVDO • Metrics: • • Average Delay 95 th percentile Delay Average Throughput Fairness • Parameters: • • • RTT=40 ms Interval=100 ms Target=100 ms 21

Results: Delay & Throughput 22

Results: Delay & Throughput 23

Results: Overall 24

Results: Fairness New Reno & C 2 TCP 25

Impact of Packet Loss @ Wireless link • Stochastic losses should not be misinterpreted as congestion signal 26

Conclusion C 2 TCP: • Is a simple yet powerful end-to-end solution for cellular NWs • Achieves ultralow latency & high throughput • Satisfies diff. Qo. S for diff. flows/applications • Achieves fairness when competes with other TCP flavors • Requires no feedback from network • Requires no changes in the cellular network 27

THANKS 28

BKP 29

Impact of Target • Interval=2. 5 x. RTT=100 ms 30

Impact of Interval • Target=2. 5 x. RTT=100 ms 31