tcp congestion control beyond bandwidth-delay product for ...bleong/slides/conext17-proprate.pdf ·...

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


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


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


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


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


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


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


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


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


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)


Putting it together

13

Estimate Receive Rate/Bandwidth

Detect Congestion from Queuing delay

Pure Rate-based Mechanism


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


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


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


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



18

Time

Pack

ets i

n bu

ffer/

Que

uing

Del

ay

T

Average latency



19

Time

Pack

ets i

n bu

ffer/

Que

uing

Del

ay T

Average latency



20

Time

Pack

ets i

n bu

ffer/

Que

uing

Del

ay

T Average latency



Throughput is maximum because buffer is always filled

21

Time

Pack

ets i

n bu

ffer/

Que

uing

Del

ay

TAverage latency


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


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


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


Please read our paperParameter tuning◦ Specify target latency to set the parameter

Updating Threshold ◦ Due to network volatility

Some math

25

읽으십시오

Evaluation

26


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


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


Results – Local ISP, Stationary

29

Good throughput/Bad latency

Good latency/Bad throughput


Results – Local ISP, Mobile

30

Good throughput/Bad latency

Good latency/Bad throughput


Results – Real LTE Network

31


ResultsPropRate more optimal than other TCP variants◦ Achieves higher throughput◦ or, lower latency

32


Congested/Saturated Uplink

33

Mobile ServerUSB Tether

congested uplinkdownlink

LTE

Smartphone


Congested Uplink – Real LTE Network

34



Decoupling ACK clocking improves resilience◦ Towards asymmetric links

35


Performance Frontiers

36




Frontier hull shows PropRate is always most optimal

37


Fairness – Self Contention

38


Fairness – Contention from others

39




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 YouQUESTIONS?

43

감사합니다

tcp congestion control beyond bandwidth-delay product for ...bleong/slides/conext17-proprate.pdf ·...

Documents