tcp congestion control beyond bandwidth-delay product for ...bleong/slides/conext17-proprate.pdf ·...
TRANSCRIPT
TCP Congestion ControlBeyond Bandwidth-Delay Product for Mobile Cellular NetworksWai Kay Leong , Zixiao Wang, Ben Leong
The 13th International Conference on emerging Networking EXperiments and Technologies
CoNEXT ’17 Seoul, Incheon
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
Why Traditional TCP does not workIN MOBILE/CELLULAR NETWORKS
4
CoNEXT ’17 Seoul, Incheon
1. Large/Deep buffers
5
Deep buffer causes high latency (hundreds of ms)
Cwnd
Time
Buffer overflow
Packets in flight (buffer)
Actual RTT
Lack of congestion signalCUBICReno
CoNEXT ’17 Seoul, Incheon
2. Uplink CongestionMore 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
6
Data
ACK ……
Idle link
CoNEXT ’17 Seoul, Incheon
Rethink congestion control for mobile networksTraditional 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 IdeaPurpose 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)
8
Our Insight:Timely estimation of the bandwidth
+ quick reaction to new network condition is sufficient
CoNEXT ’17 Seoul, Incheon
Our ApproachAbandon ACK clocking
Pure rate-based sending of packets1. Estimate current bandwidth/receive rate2. Send packets at estimated rate3. Observe buffer delay4. 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 to1. 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 RateReceiver will send ACK when packet is received
ACK will be timestamped
Compute rate by◦ comparing timestamps: tr1 – tr0 = Δt◦ and bytes ACK: ΔACK/Δt = ρ
11
Sender Receiver
TSval = tr0
TSval = tr1
Δt
CoNEXT ’17 Seoul, Incheon
Estimating Buffer/Queuing Delay
Only relative increase/decrease of tbuff matters
12
Sender Receiver
TSval = tack
Relative delayRD = tack – tsnd
Actual delay
Queuing delaytbuff = RD – RDmin
tsnd
tack
(RDmin)
CoNEXT ’17 Seoul, Incheon
Putting it together
13
Estimate Receive Rate/Bandwidth
Detect Congestion from Queuing delay
Pure Rate-based Mechanism
CoNEXT ’17 Seoul, Incheon
Self-oscillating feedback loop
14
Increase in queuing delay
tbuff > TLink Congested
Decrease in queueing delaytbuff < T
No Congestion
Buffer Drain StateSend slower than
bandwidth(σd<ρ)
Buffer Fill StateSend faster than
bandwidth(σf>ρ)
Slow StartSend burst of
10 packets
1
2 3
Estimatebandwidth (ρ)
ρ and tbuffconstantly updated
CoNEXT ’17 Seoul, Incheon
BufferDrainState
Buffer FillState
Packet Trace, aka Sawtooth
15
Time
Pack
ets i
n bu
ffer/
Que
uing
Del
ay
delay
delay
Takes at least 1×RTT to get feedback on queuing delay
Latency oscillates between the peaks and throughs
T
CoNEXT ’17 Seoul, Incheon
PropRateSending rate is a proportion of bandwidth/receive rate◦σf = kf ρ◦σd = kd ρ
Three parameters controls the sawtooth◦ kf – proportion to fill buffer◦ kd – proportion to drain buffer◦T – threshold for switching state
16
CoNEXT ’17 Seoul, Incheon
ParametersBy adjusting the parameters, kf , kd and T, we can change the shape of the sawtooth.
17
Time
Pack
ets i
n bu
ffer/
Que
uing
Del
ay
T
Average latency
CoNEXT ’17 Seoul, Incheon
ParametersBy adjusting the parameters, kf , kd and T, we can change the shape of the sawtooth.
18
Time
Pack
ets i
n bu
ffer/
Que
uing
Del
ay
T
Average latency
CoNEXT ’17 Seoul, Incheon
ParametersBy adjusting the parameters, kf , kd and T, we can change the shape of the sawtooth.
19
Time
Pack
ets i
n bu
ffer/
Que
uing
Del
ay T
Average latency
CoNEXT ’17 Seoul, Incheon
ParametersBy adjusting the parameters, kf , kd and T, we can change the shape of the sawtooth.
20
Time
Pack
ets i
n bu
ffer/
Que
uing
Del
ay
T Average latency
CoNEXT ’17 Seoul, Incheon
ParametersBy adjusting the parameters, kf , kd and T, we can change the shape of the sawtooth.
Throughput is maximum because buffer is always filled
21
Time
Pack
ets i
n bu
ffer/
Que
uing
Del
ay
TAverage latency
CoNEXT ’17 Seoul, Incheon
ParametersThroughput is maximum because buffer is always filled
Average latency can be adjusted
22
Time
TAverage latency
Pack
ets i
n bu
ffer/
Que
uing
Del
ay
CoNEXT ’17 Seoul, Incheon
ParametersThroughput is maximum because buffer is always filled
Average latency can be adjusted
23
Time
T Average latency
Pack
ets i
n bu
ffer/
Que
uing
Del
ay
CoNEXT ’17 Seoul, Incheon
Average latency
Two optimization modesOptimizing 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
24
T
Que
uing
Del
ay
Time
TTime
Average latency
CoNEXT ’17 Seoul, Incheon
Please read our paperParameter tuning◦ Specify target latency to set the parameter
Updating Threshold ◦ Due to network volatility
Some math
25
읽으십시오
Evaluation
26
CoNEXT ’17 Seoul, Incheon
Performance Evaluation1. 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 Scenarios1. Emulated networks
2. Real cellular networks
Three flavours of PropRateLow, Medium, High
+ FrontierEnumerate parameter space
27
CoNEXT ’17 Seoul, Incheon
Trace-based EmulationKeep network constant – for fair comparison
Cellsim Emulator (from MIT)
Actual Network Traces◦ Three local cellular ISPs◦ Two scenarios: stationary (in our lab) and mobile (on a bus)◦ MIT traces [Winstein et al.]
28
Mobile Cellsim Serverwired wired
uplinkdownlink
10100010010111001011
CoNEXT ’17 Seoul, Incheon
Results – Local ISP, Stationary
29
Good throughput/Bad latency
Good latency/Bad throughput
CoNEXT ’17 Seoul, Incheon
Results – Local ISP, Mobile
30
Good throughput/Bad latency
Good latency/Bad throughput
CoNEXT ’17 Seoul, Incheon
Results – Real LTE Network
31
CoNEXT ’17 Seoul, Incheon
ResultsPropRate more optimal than other TCP variants◦ Achieves higher throughput◦ or, lower latency
32
CoNEXT ’17 Seoul, Incheon
Congested/Saturated Uplink
33
Mobile ServerUSB Tether
congested uplinkdownlink
LTE
Smartphone
CoNEXT ’17 Seoul, Incheon
Congested Uplink – Real LTE Network
34
CoNEXT ’17 Seoul, Incheon
ResultsPropRate 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
ResultsPropRate 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
ResultsPropRate 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
Thank YouQUESTIONS?
43
감사합니다