TCon: A transparent congestion control deployment platform for optimizing WAN transfers

Nowadays, many web services (e.g., cloud storage) are deployed inside datacenters and may trigger transfers to clients through WAN. TCP congestion control is a vital component for improving the performance (e.g., latency) of these services. Considering complex networking environment, the default congestion control algorithms on servers may not always be the most efficient, and new advanced algorithms will be proposed. However, adjusting congestion control algorithm usually requires modification of TCP stacks of servers, which is difficult if not impossible, especially considering different operating systems and configurations on servers. In this paper, we propose TCon, a light-weight, flexible and scalable platform that allows administrators (or operators) to deploy any appropriate congestion control algorithms transparently without making any changes to TCP stacks of servers. We have implemented TCon in Open vSwitch (OVS) and conducted extensive test-bed experiments by transparently deploying BBR congestion control algorithm over TCon. Test-bed results show that the BBR over TCon works effectively and the performance stays close to its native implementation on servers, reducing latency by 12.76% on average

A fine-grained and transparent congestion control enforcement scheme

In practice, a single TCP congestion control is often used to handle all TCP connections on a Web server, e.g., Cubic for Linux by default. Considering complex and ever-changing networking environment, the default congestion control algorithm may not always be the most suitable one. Adjusting congestion control usually to meet different networking scenarios requires modification of servers' TCP stacks. This is difficult, if not impossible, due to various operating systems and different configurations on the servers. In this paper, we propose Mystique, a light-weight and flexible scheme that allows administrators (or operators) to deploy any congestion control schemes transparently without changing existing TCP stacks on servers. We have implemented Mystique in Open vSwitch (OVS) and conducted extensive test-bed experiments in public cloud environments. We have extensively evaluated Mystique and the results have demonstrated that it is able to effectively adapt to varying network conditions, and can always employ the most suitable congestion control for each TCP connection. Mystique can significantly reduce latency by up to 37.8% in comparison with other congestion controls

Mystique: a fine-grained and transparent congestion control enforcement scheme

TCP congestion control is a vital component for the latency of Web services. In practice, a single congestion control mechanism is often used to handle all TCP connections on a Web server, e.g., Cubic for Linux by default. Considering complex and ever-changing networking environment, the default congestion control may not always be the most suitable one. Adjusting congestion control to meet different networking scenarios usually requires modification of TCP stacks on a server. This is difficult, if not impossible, due to various operating system and application configurations on production servers. In this paper, we propose Mystique, a light-weight, flexible, and dynamic congestion control switching scheme that allows network or server administrators to deploy any congestion control schemes transparently without modifying existing TCP stacks on servers. We have implemented Mystique in Open vSwitch (OVS) and conducted extensive testbed experiments in both public and private cloud environments. Experiment results have demonstrated that Mystique is able to effectively adapt to varying network conditions, and can always employ the most suitable congestion control for each TCP connection. More specifically, Mystique can significantly reduce latency by 18.13% on average when compared with individual congestion controls

Extensive evaluation on the performance and behaviour of TCP congestion control protocols under varied network scenarios

In recent decades, many TCP Congestion Control (CC) protocols have been proposed to improve the performance and reliability of TCP in various network scenarios. However, CC protocols are usually closely coupled with network conditions such as latency and packet loss. Considering that networks with different properties are common, e.g., wired/wireless LAN and Long Fat Networks (LFNs), investigating both performance and behaviors of CC protocols under varied network scenarios becomes crucial for both network management and development. In this paper, we conduct a comprehensive measurement study on the goodput, RTT, retransmission, friendliness, fairness, convergence time and stability of most widely-used CC protocols over wired LAN/WAN and wireless LAN (both 2.4GHz and 5GHz Wi-Fi). We also conduct comparative studies with respect to transmission cost, congested reverse path and bottleneck queue size in network simulator. Based on our analysis, we reveal several interesting and original observations. We found that the goodput of BBR is at least 22.5% lower than other CC protocols in wireless LAN due to insufficient pacing rate, even though it can always fully utilize the bottleneck bandwidth with low RTT in wired networks. We also observed that the total on-wire data volume of BBR is higher than CUBIC (e.g., 2.37% higher when RTT = 100ms and loss rate = 0.01%). In addition, BBR can fully utilize the bottleneck bandwidth in most queue sizes (≥ 20packets). Surprisingly, we noticed that as the default CC protocol in most modern operating systems, CUBIC is too aggressive and unfriendly in both LAN and wireless LAN, greatly suppressing the goodput of other competing CC protocols. More specifically for CUBIC in wireless LAN, it generates 129% more retransmissions than other CC protocols. Nevertheless, we have also seen that, in scenario with heavily-congested reverse path, CUBIC can provide full utilization on bottleneck bandwidth. Lastly, we also observed that BBR converges very quickly in all evaluated scenarios, while other CC protocols present varied results, e.g., Westwood+ and Veno converge faster in 5GHz Wi-Fi networks than 2.4GHz networks