1. Riptide: Jump-Starting Back-Office Connections in Cloud Systems
Flores, Khakpour, Bedi, et al Presentation by cameron cunning

2. This communication is often in the form of short messages
What is the problem?
In large-scale cloud networks, communication between datacenters results in a significant performance cost
This communication is often in the form of short messages
The cost of opening new connections is significant

3. Potential solution-persistent connections
PROS
CONS
By maintaining persistent connections between datacenters, the cost of frequently opening new connections is reduced

4. Potential solution-persistent connections
PROS
CONS
By maintaining persistent connections between datacenters, the cost of frequently opening new connections is reduced
Open connections consume resources. A node connected to all other nodes, when such connections are lightly used, is inefficient.

5. Potential solution-persistent connections
PROS
CONS
By maintaining persistent connections between datacenters, the cost of frequently opening new connections is reduced
Open connections consume resources. A node connected to all other nodes, when such connections are lightly used, is inefficient.
Application behavior can make maintaining connections difficult. (errors, etc.)
App may require parallel communication, etc.

6. Potential solution-persistent connections
PROS
CONS
Open connections consume resources. A node connected to all other nodes, when such connections are lightly used, is inefficient.
Application behavior can make maintaining connections difficult. (errors, etc.)
Load balancing algorithms may nullify gains by this approach.
Existing configuration of cloud systems may be delicate and unable to support this implementation
By maintaining persistent connections between datacenters, the cost of frequently opening new connections is reduced
Deployment is an issue, as these these systems may already be operating near their capacities, and such an approach may push these systems over capacity.

7. Why is opening new connections expensive? (TCP REVIEW)
TCP uses an automatic congestion control mechanism
Basic idea: The sender limits the amount of data it sends based on a variable known as the congestion window (cwnd)
Ignoring packet loss and transmission delays, the send rate is roughly cwnd/RTT bytes/second.
TCP dynamically adjusts this variable based on network performance.
Lost packets congestion = cwnd = slower transmission
No lost packets no congestion = cwnd = faster transmission

8. SLOW START
Source: James F. Kurose and Keith W. Ross Computer Networking: A Top-Down Approach (6th Edition) (6th ed.). Pearson.
Let’s look at some details of TCP and “slow start” again.

9. The cost of slow start
Default TCP Cubic cwnd is 10 segments byte packets → 15KB for the first RTT
The figure on the right shows the file size distribution of a production CDN platform. More than half of the files will not fit in the first RTT
In probability theory and statistics, the cumulative distribution function (CDF) of a real-valued random variable X, or just distribution function of X, evaluated at x, is the probability that X will take a value less than or equal to x.

10. EXPERIMENTING WITH INITIAL CWND VALUES
Given the same distribution of file sizes on the previous slide, this is the affect on the number of RTT’s resulting from adjusting the cwnd from 10 to 25, 50, 100
The effect on the average number of RTT’s by adjusting cwnd

11. EXPERIMENTING WITH INITIAL CWND VALUES
The “step” nature of this graph can be attributed to the fact that RTT’s wrt to file size will change by discrete intervals
The gain achieved by adjusting cwnd for different file sizes

12. EXPERIMENTING WITH INITIAL CWND VALUES
Distribution of RTT’s in a production CDN network. 50% of links have RTT > 125 ms

13. EXPERIMENTING WITH INITIAL CWND VALUES
Effect on transfer time for a 100KB file by changing cwnd initial value

14. RIPTIDE – DESIGN PRINCIPLES
Simplicity: Riptide must be a small agent which is easy to deploy, control, and modify in the context of a larger system.
Distributability: System must not require a central controller; must be able to make decisions promptly and independently.
Adaptability: The system must adjust to changing network conditions and avoid adding additional strain to the network during busy periods.
In accordance with these principles, Riptide runs in user space and utilizes standard Linux kernel interfacing utilities. Easy to operate and maintain, does not require kernel maintenance or devoted development resources.
Now we can explore how Riptide implements these observations

15. RipTide – the simple idea behind the algorithm
Rather than allow TCP to go through slow start upon every connection, instead, base every new connection’s initial cwnd value to be an average of the cwnd values from the previous connection (to that destination)

16. The algorithm
Explain all input parameters except alpha here. Time to live(default is 90 seconds) – time we store the value in the table. (Once removed,default cwnd of 10 is restored).
Note: initrwnd (the # of packets a host can initially receive) must be set to cmax on all receiving hosts.

17. What is ⍺ ? Alpha is the weight to apply to the historical value.
An exponentially weighted moving average is computed, whereby the the previous value gets ⍺ , and the new value is weighted by (1- ⍺ )
This serves to prevent large, destabilizing adjustments. For example, a drastic reduction in window size on a closed or reset connection, or a dangerous increase from an unusually high cwnd

18. Uses the “ss” utility on linux to gather the historical cwnd’s
The implementation
Simple python script
Uses the “ss” utility on linux to gather the historical cwnd’s
Sets future cwnd by setting up routes using the “ip” tool.
Ex:
Demonstrate an ”ss –i” on cse, show the infor

19. Possible modifications
Could use an alternative approach wrt to alpha. In other words, instead of using alpha, could use a different approach, such as using the maximum cwnd observed, or a more conservative approach, or something else!
Also, Riptide has flexible granularity when it comes to routes and destinations. That is to say, we can apply this algorithm either to specific ip addresses, or entire subnets of ip addresses.

20. evaluation
Riptide was deployed on a production CDN consisting of 24 PoP’s

21. Evaluation (cont.)
Every hour, each machine requested a probe object from every other machine. If there was an idle connection, it was re-used; otherwise a new connection was made.
3 probe sizes of 10, 50, 100KB. (50 and 100KB probes too large for default cwnd of 10)
Sampling interval of 1 second.

22. Evaluation results
Effect of various cmax settings on cwnd size, as compared to the default (not using riptide)
This shows that Riptide does, in fact, alter the cwnd size as intended.

23. Evaluation results
Comparison between a datacenter running only probe traffic, and another among the busiest in the network
This demonstrates that Riptide’s cwnd averaging based on traffic does actually work

24. 10k probe completion times compared

25. 50k probe completion times compared

26. 100k probe completion times compared

27. Observed gains 50kb probes
Lower percentiles = better performing flows

28. Observed gains 100kb probes
Lower percentiles = better performing flows

29. Discussion
Effectiveness: Gains tightly correlated to traffic pattern, size of transfer, congestion level. More effective with large transfers and lower congestion levels.
Overhead: All overhead restricted to single-node computation. Calculations occur at regular intervals.
Additional Algorithms: Lots of possibility for different algorithm implementations. E.g. could try to predict network congestion, could try to incorporate w/ load balancing
Kernel Implementation: Implementing at kernel-level would see performance improvement at the cost of flexibility

30. Conclusion/thoughts
Simple observation led to a simple “hack” resulting in performance gains
Well written paper, clearly organized
Figures sometimes confusing