More load, more differentiation — Let more flows finish before deadline in data center networks

Abstract

Data center network has become an important facility for hosting various online services and applications, and thus its performance and underlying technologies are attracting more and more interests. In order to achieve better network performance, recent studies have proposed to tailor data center network traffic management in different aspects, devising various routing and transport schemes. In particular, for applications that must serve users in a timely manner, strict deadlines for their internal traffic flows should be met, and are explicitly taken into consideration in some latest flow rate control or scheduling algorithms in data center networks. In this paper, we advocate that when designing such deadline-aware rate control schemes, a simple principle should be followed: flows with different deadlines should be differentiated in their bandwidth allocation/occupation, and the more traffic load, the more differentiation should be made. We derive sufficient and necessary conditions for a flow rate control scheme to follow this principle, and present a simple congestion control algorithm called Load Proportional Differentiation (LPD) as its application. We have evaluated LPD under different topologies and load scenarios, both by simulation and in real testbed. Compared with D2TCP, the state-of-art window-based deadline-aware congestion control schema, LPD often reduces the number of flows missing their deadlines by more than 25%. Compared with Karuna, the state-of-art deadline-aware rate control method, LPD only performs about 5% worse on average, but under heavy congestion, LPD performs about 5%–10% better than it. Indeed, the more load more differentiation is a general principle and it can also be used for the optimization of other object. Specifically, we consider minimizing the average flow completion time. Compared with the window-based protocol L2DCT, LPD can reduce flow completion time by 30% and compared with the state-of-art scheduling method pFabric, it only underperforms by 20% on average.