riptide jump starting back office connections in cloud
play

Riptide: Jump Starting Back-Office Connections in Cloud Systems - PowerPoint PPT Presentation

Riptide: Jump Starting Back-Office Connections in Cloud Systems Marcel Flores - Northwestern University Amir R. Khakpour - Verizon Digital Media Services Harkeerat Bedi - Verizon Digital Media Services 1 Cloud systems Large scale global


  1. Riptide: Jump Starting Back-Office Connections in Cloud Systems Marcel Flores - Northwestern University Amir R. Khakpour - Verizon Digital Media Services Harkeerat Bedi - Verizon Digital Media Services 1

  2. Cloud systems • Large scale global services: • CDNs, web services. • Back-office traffic between Points of Presence (PoPs). • Control messages, small transfers. 2

  3. Cloud systems • Frequent opening of connections between PoPs. • In a perfect world, would have a mesh. • Application and resource constraints limit reuse. 3

  4. Cloud systems • Frequent opening of connections between PoPs. • In a perfect world, would have a mesh. • Application and resource constraints limit reuse. 3

  5. Cloud systems • Frequent opening of connections between PoPs. • In a perfect world, would have a mesh. • Application and resource constraints limit reuse. 3

  6. Cloud systems • Frequent opening of connections between PoPs. • In a perfect world, would have a mesh. • Application and resource constraints limit reuse. 3

  7. Cloud systems • Frequent opening of connections between PoPs. • In a perfect world, would have a mesh. • Application and resource constraints limit reuse. 3

  8. Cloud systems • Frequent opening of connections between PoPs. • In a perfect world, would have a mesh. • Application and resource constraints limit reuse. 3

  9. Slow-start penalty Sender Receiver 4

  10. Slow-start penalty Sender Receiver Syn 4

  11. Slow-start penalty Sender Receiver Syn Syn/Ack 4

  12. Slow-start penalty Sender Receiver Syn Syn/Ack { Initial Window 4

  13. Slow-start penalty Sender Receiver Syn Syn/Ack { Initial Data doesn’t fit Window 4

  14. Slow-start penalty Sender Receiver Syn Syn/Ack { Initial Data doesn’t fit Window { 2nd Window 4

  15. Slow-start penalty Sender Receiver Syn Syn/Ack { Initial Data doesn’t fit Window { Transfer pays 2nd second RTT Window 4

  16. Cloud workloads 1.0 0.8 0.6 CDF 0.4 0.2 0.0 0 200 400 600 800 1000 File Size (KB) 5

  17. Cloud workloads 1.0 0.8 0.6 CDF 54% are 0.4 too big for default 0.2 0.0 0 200 400 600 800 1000 File Size (KB) 5

  18. Cloud workloads 1.0 0.8 85% under 0.6 CDF 200KB 54% are 0.4 too big for default 0.2 0.0 0 200 400 600 800 1000 File Size (KB) 5

  19. Global deployments 1.0 0.8 0.6 CDF 0.4 0.2 0.0 0 50 100 150 200 250 300 350 400 RTT (MS) 6

  20. Global deployments 1.0 0.8 0.6 CDF 0.4 0.2 0.0 0 50 100 150 200 250 300 350 400 RTT (MS) Median RTT is over 125 ms 6

  21. Global deployments • Can’t just blindly increase the congestion window on a global deployment. • Would risk significant loss. 7

  22. Riptide • Observes current congestion windows. • New connections set initial window to a known-safe level. • Operates in a totally standalone manner. 8

  23. Riptide • Riptide observes CWND for all open connections to a destination. 85 • New connections will be 75 opened with INIT_CWND set to the average of existing windows. Riptide 9

  24. Riptide • Riptide observes CWND for all open connections to a destination. 85 • New connections will be 75 opened with INIT_CWND ? set to the average of existing windows. Riptide 9

  25. Riptide • Riptide observes CWND for all open connections to a destination. 85 • New connections will be 75 opened with INIT_CWND 80 set to the average of existing windows. Riptide 9

  26. Implementation • Implemented as a Python script in user space. • Use the ss tool to observe existing windows. • Polls current connections once per second. • Sets new windows via ip route interface. ip route add 10.0.0.127 dev eth0 proto \\ static initcwnd 80 via 10.0.0.1 10

  27. Riptide Deployment 11

  28. Probes • To test the current state of the network, send hourly probes between PoPs. • Currently employ 10K, 50K, 100K probes. 12

  29. Observed windows 13

  30. Observed windows CWND windows significantly higher. 13

  31. Observed windows CWND windows significantly higher. 13

  32. Observed windows Knee CWND windows significantly higher. 13

  33. Probe completion times •Clients are able to complete the probe transfers in fewer round trips. •Reduces total transfer time. Riptide Default 14

  34. Probe completion times •Clients are able to Better complete the probe transfers in fewer round trips. •Reduces total transfer time. Riptide Default 14

  35. Probe completion times •Clients are able to Better complete the probe transfers in fewer round trips. •Reduces total transfer time. Riptide Default 14

  36. Probe completion times •Clients are able to Better complete the probe transfers in fewer round trips. •Reduces total transfer time. Riptide Default 80% of transfers were faster 14

  37. Gain Percentile 15

  38. Gain Percentile } 15

  39. Gain Percentile } Gains were highest at upper percentiles. 15

  40. Conclusion • Demonstrated design and implementation of a simple tool to observe and adjust congestion windows. • Deployed the system in a production network. • Achieved significant increase in average congestion window. • Demonstrated improvements in completion time, reducing slow-start penalty 16

  41. Thank you! 17

  42. Extras 18

  43. Cloud systems • Complexity means node-level resource constraints • Frequent connections between Points-of-Presence (PoPs). • In many cases dominated by small file transactions. 19

  44. Cloud workloads 1.0 0.8 0.6 CDF 10 0.4 25 50 0.2 100 0.0 1 2 3 4 5 6 7 8 Number of RTT s 20

  45. Cloud workloads 1.0 0.8 0.6 CDF 10 0.4 25 50 0.2 100 0.0 1 2 3 4 5 6 7 8 Number of RTT s Larger windows reduce RTTs 20

  46. Traffic matters 21

  47. Traffic matters Traffic drives up window sizes. 21

Recommend


More recommend