Koen De Schepper, Inton Tsang . Olga - PowerPoint PPT Presentation

DATA CENTER TO THE HOME Koen De Schepper, Inton Tsang . Olga Bondarenko . Bob Briscoe . koen.de_schepper@alcatel-lucent.com March, 2015 1

DCttH OBJECTIVE: UNIVERSAL SUPPORT FOR LOW LATENCY = SUPPORT FOR ADAPTIVE INTERACTIVE APPLICATIONS UNManaged RGW LL Network Service Service 2

INTERACTIVE APPLICATIONS on the INTERNET ? Home Access Cloud Reno Back-end Server RGW Front- end Reno/Cubic Back-end DCTCP Server Server Cubic Back-end Cubic Server Reno Large queues for high throughput and low drop ECN = No drop = Poor Latency ECN++ = Small queues = Bad for interactive applications = Low latency & High throughput 3

DATACENTER to the HOME ? Home Access Cloud Reno Back-end Server RGW Front- end Reno/Cubic Back-end DCTCP Server Server Cubic Back-end Cubic Server Reno DCTCP available on Public Internet Windows and Linux 3.18 Windows Server and Linux 3.18 does not support DCTCP have DCTCP implementations ready used internally in the data center Clients use Reno and Cubic Can’t use DCTCP without causing trouble 4

MIGRATION OBJECTIVE: LOW LATENCY ACCESS TO THE CLOUD, EQUAL STEADY STATE THROUGHPUT TO RENO/CUBIC Can DCTCP be used as Low Latency congestion controller ? LL AQM Reno LL AQM DCTCP RGW LL Service DCTCP Cubic DCTCP Which AQM to be deployed on queuing bottlenecks ? Support migration ! 5

LOWER LATENCY BY SMARTER USE OF ECN DATA CENTER TCP  TCP (Reno) DCTCP Response to congestion in sender - Half the congestion window when drop detected - Reduce partially per marked packet; half if all in one RTT marked in one RTT  React according to level of congestion ECN feedback in receiver - Echo Congestion Experienced (CE) until sender - Echo marking state of received packets without acknowledges Congestion Window Reduced (CWR) acknowledgement  accurate ECN feedback ECN marking in network - Smooth and delay a drop or mark to allow bursts - Don’t smooth or delay queue size - Shallower marking threshold  immediate ECN marking 6

DEMONSTRATED ON A REAL BB RESIDENTIAL TESTBED Alcatel-Lucent 7302 Alcatel-Lucent 7750 RTT = VPRN 8ms xDSL VLAN be xDSL VLAN fr 40ms 7

LOWER LATENCY BY SMARTER USE OF ECN DATA CENTER TCP TCP (Reno) DCTCP  AQM configuration p p Average Q size Instant Q size 5 Q size variation 42 Measured in a BB DSL testbed 36 RTT = 8 ms (unloaded) 30 Pdf in 250s interval [%] 24 reno BW = 40 Mbps (downstream) 18 dctcp 1 steady state flow running alone 12 6 Reno/Cubic/DCTCP = Linux kernel 3.18 0 0 9 50 100 8 q size [packets]

QUEUE SIZE AT DEQUEUE 1 TCP RENO FLOW (STEADY STATE) p Pdf in 1s interval [%] 12 Average Q size 10 8 Pdf [%] 42 6 36 4 30 24 2 reno 18 dctcp 0 12 6 0 0 50 100 q size [packets] 9

QUEUE SIZE AT DEQUEUE 1 DCTCP FLOW (STEADY STATE) Pdf in 1s interval [%] p 42 36 Instant Q size 30 Pdf [%] 24 42 18 36 12 30 24 6 reno 18 dctcp 0 12 6 0 0 50 100 q size [packets] 10

DCTCP DOES NOT WORK ON TRADITIONAL RED-ECN Single Q Reno|Cubic DCTCP RED AQM  p p dc reno 11

DCTCP SEEMS TO WORK ONLY IN THE DATA CENTER HIGH drop Single Q continuous FULL queues Reno|Cubic DCTCP RED AQM  p p dc reno 12

Cubic (= Reno) flows: THROUGHPUT: 0 1 2 3 4 5 6 7 8 9 10 DCTCP flows: 0 1 RTT = 8 ms (unloaded) 2 BW = 40 Mbps (downstream) 3 BDP = 27 full sized packets 4 AQM = RED with recommended 5 configuration* 6 X-axis: 0 – 250 sec 7 Y-axis: first row: 0 – (80 / <nbr_flows>) Mbps 8 Y-axis: other rows 9 0 – (80 / <nbr_dctcp>) Mbps 10 * tc qdisc add dev eth2 root red limit 1600000 min 120000 max 360000 avpkt 1000 burst 220 ecn bandwidth 40Mbit 13

Cubic (= Reno) flows: Q SIZE PDF: 0 1 2 3 4 5 6 7 8 9 10 DCTCP flows: 0 1 RTT = 8 ms (unloaded) 2 BW = 40 Mbps (downstream) 3 BDP = 27 full sized packets 4 AQM = RED with recommended 5 configuration* 6 X-axis: 0 – 300 packets (450 Kbytes, 90 ms) 7 Y-axis: autoscale count packets 8 9 10 * tc qdisc add dev eth2 root red limit 1600000 min 120000 max 360000 avpkt 1000 burst 220 ecn bandwidth 40Mbit 14

AQMS FOR EQUAL STEADY STATE RATE MIGRATION PATH FOR NEW CC SCHEMES • How should an AQM guarantee an equal steady state rate for flows with different congestion control schemes - classify packets according to CC schemes - align the drop/mark probabilities AQM ? TCP Reno DCTCP DCTCP TCP Reno 15

TCP CONGESTION CONTROL SCHEMES STEADY STATE RATE • Steady state rate has been calculated for existing CC schemes: 1 . 22 1 . 17 r reno  2 cubic   p r r dc 2  3 RTT 1 2 p RTT 4 1 4 p RTT 16

TCP CONGESTION CONTROL SCHEMES STEADY STATE RATE • Steady state rate has been calculated for existing CC schemes: 1 . 22 1 . 17 r reno  2 cubic   p r r dc 2  3 RTT 1 2 p RTT 4 1 4 p RTT • But we calculated that DCTCP running in non-on/off mode behaves as: 2  p r  dc _ p RTT 17

TCP CONGESTION CONTROL SCHEMES FAIRNESS BETWEEN DCTCP AND RENO • Mark/drop probability relation for equal rate and RTT:  r r 1 . 22 2 reno dc    RTT RTT 1 2 p RTT p RTT reno dc reno reno dc dc 2   p    dc p reno   1 . 63 18

TCP CONGESTION CONTROL SCHEMES FAIRNESS BETWEEN DCTCP AND RENO • Mark/drop probability relation for equal rate and RTT:  r r 1 . 22 2 reno dc    RTT RTT 1 2 p RTT p RTT reno dc reno reno dc dc Square is easy! 2   p    dc Compare Q size with 2 random variables p reno   1 . 63  Random()  P  p P f ( Q )    2 p ( Random() P ) & &( Random() P )   2 p max( Random(), Random()) P 19

DCTCP BEHAVES EXACTLY AS RENO IF WE CORRECTLY CORRELATE MARKING AND DROPPING Single Q ECN Classifier Reno|Cubic* DCTCP Coupled AQM 2   p     dc p reno   1 . 63 Instant Q size * Under local DC-access conditions (small BDP) Cubic behaves as Reno Slope starts from the origin to avoid ON/OFF behavior in steady state 20

DCTCP BEHAVES “TOO” EXACTLY AS RENO Works Single Q No Latency gain ECN Classifier Reno|Cubic DCTCP Coupled AQM 2   p     dc p reno   1 . 63 Instant Q size 21

DUAL QUEUE – LOW LATENCY Dual Q DCTCP Scheduler ECN AQM ? Classifier ? TCP_reno 2   p r p RTT 1 . 22   8   dc reno dc dc p reno   r 2 RTT p dc reno reno 22

DUAL QUEUE – LOW LATENCY Dual Q DCTCP Strict ECN AQM ? Classifier Priority TCP_reno 1/5 = 8 ms /(8 + 32) ms 2   p r p RTT 1 . 22   8   dc reno dc dc p reno   r 2 RTT p dc reno reno = 5 23

DUAL QUEUE – LOW LATENCY Dual Q DCTCP 1 ECN Strict priority Classifier scheduler TCP_reno Reno|Cubic DCTCP Coupled AQM 2   p   8  dc p reno   Instant Q time 24

DUAL QUEUE – LOW LATENCY ZERO Dual Q Q latency DCTCP 1 ECN Strict priority Classifier scheduler  TCP_reno Reno|Cubic DCTCP Coupled AQM 2   p   8  dc p reno   Instant Q time Measure Q in time is important for optimal fairness ! 25

Cubic (= Reno) flows: THROUGHPUT: 0 1 2 3 4 5 6 7 8 9 10 DCTCP flows: 0 1 RTT = 8 ms (unloaded) 2 BW = 40 Mbps (downstream) 3 BDP = 27 full sized packets 4 AQM = DualQ Coupled 5 X-axis: 0 – 250 sec 6 Y-axis: all rows: 7 0 – (80 / <nbr_flows>) Mbps 8 9 10 26

Cubic (= Reno) flows: Q SIZE PDF: 0 1 2 3 4 5 6 7 8 9 10 DCTCP flows: 0 1 RTT = 8 ms (unloaded) 2 BW = 40 Mbps (downstream) 3 BDP = 27 full sized packets 4 AQM = DualQ Coupled 5 X-axis: 0 – 300 packets 6 (450 Kbytes, 90/w ms) 7 Y-axis: autoscale count packets 8 9 10 27

THROUGHPUT RATIO (CUBIC / DCTCP) 10.0 RED AQM 1.0 1.0 0.1 0.1 1 10 Cubic 0.01 DCTCP 10 1 1 10 Cubic DualQ Coupled AQM DCTCP 10 1 28

DETAILED IMPLEMENTATION Reno|Cubic DCTCP 3 parameters: p dc Q d >T || (Q r << S d ) > R1 • Reno slope (bits) • DCTCP slope (bits) Dctcp R1 • DCTCP threshold (Q size) QSize DCTCP ECN marker 1 ECN Strict priority Classifier scheduler Drop TCP Reno p r R1 2   p (Q r << S r ) >   8  Reno QTime dc p R1 && R2 R2 reno   Q r   S S 3 && = r d 29

ADAPTIVE INTERACTIVE APPLICATIONS  Panoramic interactive video Adaptive Low latency encoder/decoder User interaction  Video/Voice conferencing  Remote control, .... 30