TCP EX MACHINA: COMPUTER-GENERATED CONGESTION CONTROL KEITH WINSTEIN AND HARI BALAKRISHNAN. Presented by: Angela Jiang

Transcription

1 TCP EX MACHINA: COMPUTER-GENERATED CONGESTION CONTROL KEITH WINSTEIN AND HARI BALAKRISHNAN Presented by: Angela Jiang

2 Network congestion Cause: Sources trying to send data faster than the network can process Result: QoS deterioration of network Queuing delays Packet losses Congestion collapse

3 Congestion control Prevent congestion collapse Allocates network resources Link bandwidth Queue space End-to-end or network assisted

4 End-to-end congestion control No support from network layer Hosts must infer presence of congestion Packet loss Queueing delay ECN marks Individually control transmission rate

5 Challenge: evolving networks Wireless Short connections Bursty traffic Datacenters

6 Evolution of congestion control

7 Challenge: rational choice of scheme Different goals? Different assumptions about network? One scheme just plain better?

8 Current congestion control Inflexible; doesn t allow network evolution Unclear what an algorithm is optimized for

9 Remy Program that generates end-to-end congestion control schemes offline Given Network representation Objective of app (e.g. high throughput) Generates RemyCC; a congestion control algorithm

10 Objective function Fairness vs. efficiency Delay vs. throughput Objectives used flow that receiv U a (x)= x1 a 1 a U a (x) d U b (y), U = log(throughput) d log(delay), U = 1 throughput. emycc with only a

11 Prior assumptions of network Model of network uncertainty Link speed distribution Delay distribution Degree of multiplexing Traffic model Off-to-on model Web browsing, MapReduce, VoIP

12 RemyCC maps state to an action Rule(r ewma, s ewma, rtt ratio)!hm, b, i m b Multiple to congestion window Increment to congestion window Minimum interval between two outgoing packets

13 Find the best value r_ewma <?,?,?> s_ewma

14 Best single action r_ewma <0.90,4,3.3> s_ewma

15 Subdivide most used rule <0.90,4,3.3> <0.90,4,3.3> r_ewma <0.90,4,3.3> <0.90,4,3.3> s_ewma

16 s_ewma Optimize each new action <0.90,5,2.8> <0.70,6,53.5> r_ewma <0.60,19,76.2> <0.80,5,4.1>

17 Split most used rule <0.90,5,2.8> <0.70,6,53.5> r_ewma <0.80,5,4.1> <0.80,5,4.1> <0.60,19,76.2> <0.80,5,4.1> <0.80,5,4.1> s_ewma

18 Final RemyCC rule table s_ewma r_ewma <1.70,256,10.4> <0.70,-256,44.4> <1.10,-256,5.0> <0.10,255,2.7> <1.60,252,3.0> <1.40,254,1.8> <1.30,256,3.4> <1.20,256,4.5> <1.00,256,10.8> <1.00,256,3.2> <0.10,256,3.2> <0.50,256,3.7> <0.50,256,3.8> <0.40,256,5.7> <0.70,256,2.9> <0.20,256,2.3> <2.00,256,3.5> <1.80,254,2.6> <0.90,256,3.9> <0.50,256,2.0> <0.90,256,4.0> <0.50,256,2.9> <1.10,256,4.6> <1.00,256,3.8> <0.80,256,3.7> <0.80,256,4.9> <1.40,256,4.2> <0.40,256,2.7> <0.50,256,4.5> <2.00,256,2.7> <1.20,256,2.7> <1.00,256,3.1> <0.90,256,2.5> <0.40,256,3.1> <1.90,256,3.0> <1.00,256,3.9> <1.70,256,4.1> <1.60,256,4.8> <1.10,256,4.3> <1.20,256,3.0> <1.90,256,5.6> <0.70,256,3.7> <0.50,256,3.3> <1.20,256,5.1> <0.20,256,5.5> <0.30,256,3.9> <1.60,256,8.3> <1.50,256,2.5> <1.60,256,4.7> <1.60,256,3.4> <1.40,256,5.5> <0.70,256,3.0> <0.50,256,12.9> <0.20,256,4.9> <1.70,256,3.2> <0.40,256,7.4> <1.30,256,3.6> <1.90,256,3.0> <0.10,256,8.6> <1.60,256,5.4> <0.50,256,4.5> <0.10,256,20.1> <0.60,256,11.8> <1.10,256,5.1> <1.00,256,12.3> <1.80,-256,5.4> <0.40,256,6.7> <0.50,256,20.2> <1.00,256,9.3> <0.30,256,4.1> <0.30,256,22.6> <1.60,256,10.6> <1.50,256,7.3> <1.40,256,6.7> <0.60,256,14.2> <1.70,256,8.3> <0.80,256,23.4> <1.70,256,9.9> <1.20,256,7.0> <1.20,256,13.1> <0.70,256,7.9> <1.00,256,9.9> <1.40,256,43.4> <1.60,256,10.9> <0.10,256,9.9> <0.70,227,56.1> <1.30,228,27.0> <1.10,227,19.6>

19 Evaluation 3 RemyCCs with d =.1, 1, 10 Generating one RemyCC Takes a few hours $5-$10 on EC2 Compared against end-to-end and network assisted congestion control schemes

20 Single bottleneck ( dumbbell ) Remy =0.1 Remy =1 Throughput (Mbps) Cubic/sfqCoDel Cubic XCP Better Compound Remy = NewReno Vegas Queueing delay (ms) 2 1

21 Varying throughput ( cellular ) 3 Remy = Throughput (Mbps) Cubic Cubic/sfqCoDel Compound NewReno XCP Remy =1 Remy =10 Vegas Queueing delay (ms) 8

22 Cellular: n=8 2 Remy = Cubic Remy =1 Throughput (Mbps) Compound NewReno Cubic/sfqCoDel Remy =10 Vegas 0.8 XCP Queueing delay (ms) 16

23 Fairness for varying RTTs 1 Cubic-over-sfqCoDel RemyCC ( = 0.1) RemyCC ( = 1) RemyCC ( = 10) Normalized throughput share RTT (ms)

24 Datacenters Issues Many synchronous requests -> incast Diverse mix of short and long flows Simulation 64 connections, 10 Gpbs link Objective function maximizes throughput Comparable throughputs to DCTCP DCTCP has shorter RTTs

25 Sensitivity of design range log(normalized throughput) - log(delay) CubicoversfqCoDel RemyCC 1x (link speed known a priori) RemyCC 10x (designed for link speeds in shaded region) link speed (megabits/sec)

26 Discussion: practicality Providing network assumptions Scalability Using CC algorithms we don t understand Coexisting with other protocols

27 Approaching congestion control differently Complex rules but consistent behavior Objective and environment driven Able to evolve