Adaptive congestion control framework and a simple implementation on high bandwidth-delay product networks

Computer Networks 64 (2014) 308–321

Contents lists available at ScienceDirect

Computer Networks journal homepage: www.elsevier.com/locate/comnet

Adaptive congestion control framework and a simple implementation on high bandwidth-delay product networks Min Wang a,b, Junfeng Wang a,⇑, Sunyoung Han c a

College of Computer Science, Sichuan University, Chengdu 610064, PR China College of Computer Science and Information Technology, Yunnan Normal University, Kunming 650092, PR China c Department of Computer Science and Engineering, Konkuk University, Seoul 143-701, Republic of Korea b

a r t i c l e

i n f o

Article history: Received 3 August 2013 Received in revised form 20 February 2014 Accepted 23 February 2014 Available online 1 March 2014 Keywords: Adaptive congestion control Bandwidth-delay product Delay-based approach Loss-based approach TCP performance

a b s t r a c t As new link technologies and sub-networks proliferate and evolve, a large number of TCP variants have been developed for different types of the network environments. They can lead to major performance gains by taking advantage of local characteristics of the specific network. However, these TCP variants could not be automatically chosen according to the lower network environments. In this paper, we propose the ACCF, an adaptive congestion control framework, which can automatically transition among existing congestion control mechanisms according to the change of the network status. Then we perform a simple implementation of ACCF over the networks with high bandwidth-delay product (BDP). It can switch the congestion control approaches between the delay-based ones and the loss-based ones according to the network status. Extensive experiments are conducted based on network simulators as well as over real wired networks on different time periods of the day. For the simulation measures, the experimental results show that the performance of ACCF is significantly improved as compared to other state-of-the-art algorithms in term of throughput, fairness and TCP-friendliness. For the real network tests, the experimental results show that ACCF achieves speedup ratios up to 225.83% compared with average throughput of other TCP congestion control algorithms.  2014 Elsevier B.V. All rights reserved.

1. Introduction Almost all Internet applications rely on the Transmission Control Protocol (TCP) [1] to deliver data reliably across the network. Although it was not part of TCP’s primary design, the most vital element of TCP is congestion control, which determines TCP’s performance characteristics. This area has been continuing to draw research and engineering effort because new link technologies and sub-networks have proliferated and evolved. For example, the past few years have seen an increase in wireless

⇑ Corresponding author. Tel./fax: +86 028 85412159. E-mail addresses: [email protected] (M. Wang), [email protected] (J. Wang), [email protected] (S. Han). http://dx.doi.org/10.1016/j.comnet.2014.02.021 1389-1286/ 2014 Elsevier B.V. All rights reserved.

networks with variable bottleneck rates; datacenter networks with high rates, short delays, and correlations in offered load; paths with excessive buffering (now called ‘‘bufferbloat’’); cellular wireless networks with highly variable, self-inflicted packet delays; links with noncongestive stochastic loss; and networks with large bandwidth-delay product (BDP). In these conditions, standard TCP’s behavior could be sub-optimal and even erroneous [2–5] mainly because it is expected to operate in a diverse set of networks with different characteristics, making standard TCP a ‘‘Jack of all trades, master of none’’ protocol. And standard TCP could not adapt its congestion control algorithms to new scenarios, which constrains architectural evolution, as noted in an earlier position paper [6]. In this work, we aim to perform the adaptive congestion control for different network status.

M. Wang et al. / Computer Networks 64 (2014) 308–321

Limiting TCP to a specific network and taking advantage of local characteristics of that network can lead to major performance gains. So far, a large number of TCP variants have been developed for different types of network environments. For example, TCP New Reno [7], TCP SACK [8] and TCP Vegas [9] are for low speed networks; BIC TCP [10], Cubic TCP [11], H-TCP [12], Illinois TCP [13] and Compound TCP [14] are for the networks with high BDP; TCP Westwood [15] is for wireless networks; TCP Peach [16] is for the satellite networks; DCTCP [17] is for data center networks. These variants can outperform TCP in the specific networks, while they might not be applicable in other networks. There are different congestion-control-mechanisms used in the TCP variants which are suitable for the similar networks. For instance, there are loss-based approaches, delay-based approaches and the synergy of loss-based and delay-based approach for the networks with large BDP [13]. Different congestion control approaches could achieve different performance gains. Some of TCP variants have been implemented in the Linux kernel or Windows System, e.g. BIC TCP, Cubic TCP, TCP Vegas, TCP Illinois and TCP Westwood are implemented in Linux kernel, and Compound TCP is implemented in Windows Vista. However, these TCP variants could not be automatically chosen according to the lower network state. Some default congestion control modules, such as TCP Reno, BIC and Cubic, are used in different Linux kernel versions. Other congestion control approaches could not be used unless users deploy them manually. It is impractical to choose an appropriate congestion control module for every endpoint. Additionally, the lower network state, such as the available bandwidth and buffer size of the routers, is time varying. All this would make the automatic choice a challenge. In [18,19], novel AQM (active queue management) algorithms have been proposed to adapt to changing link rates and traffic conditions. However, these algorithms can only be adopted in AQM networks that have not been widely deployed because of implementation difficulties. Therefore, the algorithms could not be widely used in current networks. It is noted that TCP stacks have adapted in some respects to the changing Internet; for example, increasing bandwidth-delay product have produced efforts to increase the initial congestion window [2,20], including recent proposals [21,22] for this quantity to automatically increase on the timescale of months or years. Nevertheless, the performance improvement only by changing the protocol parameters is still limited. In Remy [23], TCP’s entire congestion control algorithm has adapted in response to empirical variations in underlying networks. Unfortunately, this approach seems impractical in that it requires prior knowledge or assumptions about the network and an objective specified by the protocol designer. Monia Ghobadi et al. [24] propose OpenTCP as a TCP adaptation framework that works in SDNs (Software Defined Networks). It requires the assistance of the controllers, and thus could not be adopted in Internet in the short term. In this paper, we propose an adaptive congestion control framework, named ACCF, which can automatically transition among existing congestion control mechanisms according to the network status. ACCF is orthogonal to

309

previous works improving TCP’s performance. It is not meant to be a partial improvement of TCP. Instead, it complements previous efforts by making it easy to switch between different congestion control mechanisms automatically based on network conditions. For instance, with ACCF, one can utilize the congestion control approaches of either DCTCP or Cubic TCP in a data center environment. The decision on which approach to use is made according to current network status. As a preliminary attempt, we apply ACCF to the high BDP networks and adaptively choose the appropriate congestion control approaches from existing ones. In the example case, we focus on the efficient and fair data transfer over high BDP networks with various network devices and links, and we believe ACCF can satisfy the following requirements. (1) It can efficiently use the network bandwidth in a wide spectrum of network status, including different network bandwidth and diverse router buffer size. (2) It can have good intra-protocol fairness, especially when the competing flows have different RTTs. (3) It also can have good TCP friendliness. Our main contributions are as follows. Firstly, the flexible and scalable architecture of ACCF is presented, including three components: network parameter update, network status estimation and congestion control mechanism adaptation. Secondly, the preliminary application of ACCF is investigated over the high BDP networks to verify its feasibility. The rest of this paper is organized as follows. In Section 2, a brief overview of related work is presented. Section 3 details the main mechanisms of the proposed framework. In Section 4, simulation-based experiment results and performance measured over real networks are presented. Then further work is discussed in Section 5. Finally, Section 6 concludes the paper.

2. Related work In this section, we present a brief overview of adaptive approaches and existing TCP variants for the high BDP networks.

2.1. Protocols with adaptive approaches S. Floyd et al. [18] propose an adaptive RED (Random Early Detection) algorithm that tunes RED’s parameters to adjust to current traffic conditions. CoDel [19] is proposed as an innovative approach to AQM, which adapts to changing link rates and is suitable for deployment. These algorithms can only be applied in AQM networks, and thus could not be widely used in current networks. RFC6928 [21] proposes an experiment to increase the permitted TCP initial window (IW) from between 2 and 4 segments, as specified in RFC 3390 [25], to 10 segments, with a fallback to the existing recommendation when performance issues are detected. Several large scale experiments show that the higher initial window improves the

310

M. Wang et al. / Computer Networks 64 (2014) 308–321

overall performance of many web services without resulting in a congestion collapse. Keith Winstein et al. [23] propose a new approach to end-to-end congestion control on a multi-user network. In this approach, the protocol designer specifies their prior knowledge or assumptions about the network and an objective that the algorithm will try to achieve, e.g., high throughput and low queuing delay. Remy then produces a distributed algorithm—the control rules for the independent endpoints—that tries to achieve this objective. In Remy, TCP’s entire congestion control algorithm have adapted in response to empirical variations in underlying networks. Unfortunately, this approach seems impractical in that: (1) it requires prior knowledge or assumptions about the network and an objective specified by the protocol designer; (2) running on a 48-core server, Remy generally takes a few hours of wall-clock time (one or two CPU-weeks) to generate congestion-control algorithms offline. Moreover, the approach has been evaluated only through the simulation experiments by now, and its friendliness with existing TCP variants is uncertain. It might not be applicable over the Internet in the short term. Monia Ghobadi et al. [24] propose OpenTCP as a TCP adaptation framework that works in SDNs. The operator can easily customize end-hosts’ TCP stack according to the statistic information collected by the SDN controllers. However, OpenTCP requires the assistance of the controllers and thus could not be deployed in Internet in the short term. 2.2. Congestion control approaches on the high BDP networks There are many protocols are presented for the networks with high BDP, including the loss-based, the delaybased and the synergy of loss-based and delay-based approaches. In Section 4, we will compare ACCF with Cubic TCP, Fast TCP [26] and TCP Illinois, which are the lossbased, the delay-based and the mixed approaches respectively. Loss-based approaches modify the AIMD mechanism of TCP congestion avoidance phases to quickly increase and slowly decrease the congestion window than TCP Reno so as to achieve high throughput in high BDP networks. HTCP sets a function of the elapsed time since last packet loss as increase parameter and uses an adaptive backoff strategy once congestion events occur so as to achieve a perfect performance on responsiveness and efficiency in high BDP networks. In HTCP, the window size curve between two consecutive loss events is convex. However, an ideal window curve should be concave, which is more efficient and avoids heavy congestion [27]. BIC TCP and Cubic TCP are proposed to yield a non-convex window curve. BIC TCP adjusts the window size using a binary search method to reach a reference value. The increment of the window size is linear at the initial stage and then becomes logarithmic when approaching to the reference point. BIC TCP performs better than the earlier approaches. However, it suffers the RTT unfairness problem. Cubic TCP is developed to improve the RTT-fairness performance of BIC TCP. The protocol modifies the linear window growth function of existing TCP standards to be a cubic function

in order to improve the scalability of TCP over fast and long delay networks. The window growth function of Cubic is defined as [11]:

WðtÞ ¼ Cðt  KÞ3 þ W max rffiffiffiffiffiffiffiffiffiffiffiffiffiffi 3 W max b K¼ C

ð1Þ ð2Þ

where C is a Cubic parameter, t is the elapsed time from the last window reduction, Wmax is the window size where the loss event occurs, and K is the time period that the above function takes to increase W to Wmax when there is no further loss event. During steady state, Cubic increases the window size aggressively when the window is far from the saturation point, and slowly when it is close to the saturation point. Cubic need to choose a max probing method to detect the new maximum after the saturation point is reached, and this yields a convex window curve. Although above-mentioned approaches can achieve higher throughput than the standard TCP, oscillation is unavoidable because they uses packet loss as the only congestion signal. Moreover, the more aggressive increase rate and drop behavior can increase burden on intermediate router buffers, thereby resulting in serious congestion. Hence, loss-based protocols could not achieve full bandwidth utilization when the network status changes. Delay-based protocols make use of the queue delay as the network congestion estimator and can achieve excellent steady state performance. FAST TCP is a typical delay-based high-speed TCP variant derived from TCP Vegas. The protocol maintains queue occupancy at routers for a small but not zero value so as to make the network around full bandwidth utilization and achieve a higher average throughput. It periodically updates the congestion window based on the estimated average RTT and average queuing delay, and the function is defined as [26]:

   baseRTT W ¼ min 2wold ; ð1  cÞw þ c wold þ a av e RTT

ð3Þ

where wold is the congestion window size of last RTT and w is the current congestion window. a is the number of packets which can be queued in routers at the equilibrium state. c 2 (0,1], baseRTT is the minimum RTT observed so far. Unfortunately, these delay-based protocols may suffer from some inherent weakness. Firstly, delay-based flows could suffer from significant performance degradation when competing with loss-based flows [13]. Secondly, they require the buffer size at the router to be larger than a specified value a and this value increases with the number of users N. Since N is difficult to be estimated, a is usually fixed, e.g. it is set to 200 packets in FAST TCP. As a result, the change of the buffer size at the router may result in the performance degradation of delay-based protocols. Lastly, the performance of these delay-based protocols deteriorates if the delay measurements are noisy. They may suffer from performance degradation on congested links because a large number of packet losses could result in wrong delay estimation. Mixed protocols combine loss-based protocols and delay-based protocols. They use both packet loss information

M. Wang et al. / Computer Networks 64 (2014) 308–321

and delay information for congestion control. TCP Fusion [28] exploits three useful characteristics of TCP-Reno, TCP-Vegas and TCP-Westwood in its congestion avoidance strategy. It uses delay information to determine congestion level even if packet loss occurs. Compound TCP utilizes loss and delay information as the primary congestion indicators in different stages to determine direction of window size change, and keeps the traditional Slow-Start at the startup period while uses a delay-based component derived from TCP Vegas in congestion avoidance phase. TCP-Illinois uses loss information as the primary congestion indicator and uses delay information to be the second congestion indicator. During the operation, it utilizes the loss information to determine the direction of window change and the delay information is used for adjusting the pace of window size change. HCC TCP [29] uses queue delay as the primary congestion indicator and the packet loss as the second congestion indicator. The delay-based strategy of HCC TCP relies on the one-way delay measurements to estimate the congestion along the forward path to minimize the influence of the reverse traffic on the throughput performance. However, as new TCP variants, these protocols still could not achieve satisfactory performance improvement when the lower networks change, as is shown in Section 4.

3. Adaptive Congestion Control Framework (ACCF) 3.1. ACCF architecture Unlike OpenTCP, ACCF is end-to-end without the assistance of other network devices. ACCF calculates and updates the network parameters (e.g., queuing delay, packet loss events, and even the inter-arrival time between new packets received). Then, ACCF estimates the current network status according to the variations of these parameters. Subsequently, different congestion control approaches are utilized for different network status. Fig. 1 presents the schematic view of how ACCF works. As shown in the figure, ACCF architecture has three main components. After the features of various networks are meticulously considered, the network parameters that can characterize the network status are abstracted and measured in Network Parameter Update. Network Status Estimation is the heart of ACCF and it can be conducted according to the variations of one or more network parameters. After the network status estimation, an appropriate congestion control (CC) mechanism would be chosen in the Congestion Control Mechanism Adaptation. To choose suitable approaches, the characteristics of various

311

congestion control mechanisms need to be carefully analyzed and classified. Two-timescale control: ACCF goes through a cycle of three steps: (i) network parameter update, (ii) network status estimation, and (iii) congestion control mechanism adaptation. These steps are repeated with a pre-determined period of T seconds. In order to keep the network stable, T needs to be orders of magnitude slower than the network RTT. Intuitively, by slowly modifying TCP parameters, ACCF gives each TCP session enough time to become stable before updating its state. Hence, we set the value of T is two RTT. Transitions between congestion control mechanisms: ACCF can be used to choose between two or more congestion control mechanisms based on network conditions. Let us consider K congestion control mechanisms, say P1, P2, . . ., PK. According to previous works by Tang et al. [30,31], ACCF can keep the system stable as long as it satisfies the following three conditions: 1. "i,j:1 6 i,j 6 K, Pi and Pj have compatible congestion measures; 2. "i:1 6 i 6 K, the network is stable under Pi; the utility functions are concave and monotonic; and 3. Changes are applied at a slow timescale (T) compared to the timescale of TCP window dynamics (RTT), which we call fast timescale. Intuitively, having compatible congestion measures means that even though different congestion control mechanisms react to different congestion signals (e.g., Reno to packet loss probability and FAST to queuing delay) the measures can be related through a price mapping function as shown in [31]. Having a two timescale scheme ensures that each flow can reach steady state before another round of changes is applied. We leave a more formal description of congestion measure compatibility and the proof of stability to future work. Feasibility, scalability, and improvements: As a proof of concept, we have applied ACCF to the networks with high BDP, as shown in Section 3.2. We present a simple case study of ACCF that adaptively adjusts congestion control mechanisms. Through this study, we demonstrate how ACCF achieves the process of adapting congestion control mechanisms to varying network conditions. Fortunately, such an adaptation results in speedup ratios up to 225.83% compared with average throughput of other TCP congestion control algorithms in real network tests. Taking advantage of today’s extendible TCP implementations, we can easily transition among existing congestion control mechanisms and even introduce completely new congestion control schemes when needed.

3.2. A simple case of ACCF on the high BDP networks

Fig. 1. Architecture of ACCF.

As mentioned in Section 2.2, there are many protocols are presented for the networks with high BDP, including the loss-based, the delay-based and the synergy of lossbased and delay-based approaches. In this section, ACCF is applied to the networks with large BDP and transitions

312

M. Wang et al. / Computer Networks 64 (2014) 308–321

between the loss-based approaches and the delay-based approaches. 3.2.1. Adaptability of the congestion control mechanisms to the network status Loss-based approaches modify the AIMD mechanism of TCP congestion avoidance phases to make it more aggressive and use packet loss as the only congestion signal. Therefore, the throughput could oscillate between full utilization and under-utilization, and the oscillation would become more severe over the high speed links. Moreover, the more aggressive increase rate and drop behavior can increase burden on intermediate router buffers, thereby resulting in serious congestion. As a result, the loss-based approaches could not achieve full bandwidth utilization in high-speed networks [13]. On the other hand, delay-based approaches make use of the queue delay as the network congestion estimator and can achieve excellent steady state performance. However, they may suffer from significant performance degradation over the links with limited bandwidth due to the estimation errors of the queue delay [32], and it suffers unfairness and instability in small buffer or long delay networks [29], as described in Section 2.2. From the foregoing analysis, it can be seen that lossbased approaches are applicable in low-speed networks while delay-based approaches have decisive advantages in high-speed networks [26]. Hence, the loss-based approaches can be used when the network bandwidth is full utilized while the delay-based approaches can be used when the network bandwidth is under-utilized. 3.2.2. Transitions between congestion control mechanisms Based on the analysis in Section 3.2.1, two network parameters, i.e. the packet loss event and the congestion window variation, are used to estimate the network status, as shown in Fig. 2. The network is thought to be fully utilized when packet loss occurs and under-utilized when the congestion window size exceeds the window size where the loss event occurred (i.e.Wlast_max). One of the delay-based and the loss-based approaches is selected according to the estimated network status. The delaybased approach is applied when network status is estimated to be under-utilized, while the loss-based approach is used when network status is estimated to be fully utilized. In this case, Fast TCP, the delay-based protocol, and Cubic TCP, the loss-based protocol, are used. For simplicity, we integrate the two congestion control approaches into ACCF. Since delay measurements are noisy when the

Fig. 2. Architecture of the simple case.

network tends to be congested, ACCF uses loss information as the primary congestion indicator and delay information can be used only when the networks is estimated under-utilized. Specifically, different congestion control approaches are used to determine target window size according to the estimated network status. When the target window size is determined, ACCF applies the cubic function defined in Cubic TCP to update window size. It is the function of the real time between two consecutive network status changes. We call the real time an epoch, and an epoch starts when packet loss occurs or current window size exceeds Wlast_max. Thus the window growth becomes independent of RTTs. Using the function, ACCF could attain a concave window curve and further achieve efficiency and RTT-fairness. Fig. 3 depicts the congestion window evolution behavior. At startup phase, we assume that the link is underutilized. In order to detect available bandwidth as soon as possible, like Fast, the multiplicative increase (MI) mode is used to increase the window size towards the target window, which is calculated according to the delay information. When packet loss happens, which is thought that the link is fully utilized, ACCF records the loss window size and switches to the loss-based CC. After fast recovery, it uses the loss window as the target window size and starts to increase the window size toward the target window. When packet loss happens again and congestion window is no more than the last loss window, the target window size is updated to new loss window size and ACCF is still in the loss-based CC. When congestion window is larger than the loss window and no loss happens, it is thought that there is some available bandwidth in the networks. Hence ACCF switches back to the delay-based CC, and the target window is recomputed by the delay-based CC. As the target window is determined, ACCF adjusts the window size using the cubic function to enable the current window size approach the target window. Fig. 4 shows the chart flow of window control algorithm of ACCF. The detailed implementation is described as follows. Startup: At startup phase, we assume that the link is under-utilized. In order to detect available bandwidth as soon as possible, ACCF relies on the delay-based CC to increase the window size. A state variable, called baseRTT, is maintained as an estimation of the transmission delay of a packet over the network path. When the connection is established, baseRTT is updated by the minimum RTT

Fig. 3. Congestion window behavior.

M. Wang et al. / Computer Networks 64 (2014) 308–321

313

Fig. 4. Flow chart of ACCF.

that has been observed so far. An exponentially smoothed RTT, ave_RTT, is also maintained with the method used in TCP Reno. Then queuing delay d of the connection is

d ¼ av e RTT  baseRTT

ð4Þ

A threshold value, mi_threshold, is set to estimate the congestion on the path. If d < mi_threshold, it indicates that the queuing is light, and the MI scheme can be used to rapidly increase the window size as Eq. (5). Otherwise, the protocol periodically updates the congestion window towards the target window because the queuing along the path maybe becomes heavy.

W ¼ 2  W old

ð5Þ

where Wold is the congestion window size of last RTT and W is the current congestion window.

Determination of target window: When queuing delay d exceeds the value of mi_threshold, ACCF would periodically update the congestion window towards the target window. In order to keep the network stable, the target window size is determined based on the network status every other RTT. If the network is under-utilized, there are rare packet losses and thus RTT can be correctly estimated. Also the network congestion can be well detected by the queuing delay under the circumstances. Therefore, the delay-based CC is used to determine the target window size so as to reach the steady state as soon as possible. We can calculate Wfast according to Eq. (3). If packet loss events occur, indicating the network is fully utilized, the estimation of RTT would be interfered, and the delay information cannot correctly reflect the network status. Consequently, once a packet is detected to be

314

M. Wang et al. / Computer Networks 64 (2014) 308–321

lost, ACCF would switch to the loss-based CC. The window size where the loss event occurs is recorded as the last max window Wlast_max and set as new target window size. When packet loss happens again and congestion window is no more than Wlast_max, Wlast_max and the target window is updated to the new loss window size. If the congestion window exceeds Wlast_max after fast recovery and there is no further loss event, ACCF would calculate the value of Wfast again and update the target window size. Window update: ACCF takes the target window size as an anticipated window size, and adopts the cubic function in Cubic to update the congestion window size, i.e., replacing Wmax in Eq. (1) with Wtarget. Once the target window is determined, ACCF adjusts the window according to the difference between the target window size and current window size so as to enable the current window size approach the target window. With this cubic function, ACCF can achieve a concave window curve. When the distance between the current window and the target window is large, ACCF increases the window faster. When the current window size gets close to the target window size, the window increase slows down, and is stable around the target window till the network status changes. Packet loss: When packet loss events are detected, Wlast_max is set as the current window size and then the congestion window is reduced as follows:

W ¼ W  ð1  bÞ

ð6Þ

where b is a window decrease constant. 4. Experimental results We conduct extensive experiments based on network simulators as well as over real wired networks, and the experimental results are presented in this section. 4.1. Performance evaluation based on simulation experiments In our experiments, we first conduct simulation experiments to evaluate ACCF and compare its performance with TCP Reno, Cubic TCP, Fast TCP and TCP Illinois using OPNET. As shown in Fig. 5, a dumb-bell network topology with single bottleneck link shared by one or multiple users is considered in the simulation. The bottle link bandwidth is 400 Mbps represented for high-speed link and 5 Mbps for low-speed link respectively. The routers are equipped with the first-in-first-out (FIFO) service discipline for the queuing. The size of data packets is 1500 bytes and RTT is 120 ms (unless specified otherwise) in our experiments.

Fig. 5. The network topology with simple bottle link.

The simulation time is 300 s for each simulation scenario. We evaluate the performance of these protocols in term of efficiency, fairness and TCP-friendliness. For TCP Reno, Cubic TCP and TCP Illinois, their default parameter settings are used in the simulations. For FAST TCP and ACCF, we set a = 400. The value of C and b in ACCF is the same as that in Cubic TCP, i.e., 0.4 and 0.2 respectively. 4.1.1. Efficiency of single traffic flow We first evaluate the efficiency of a single traffic flow with different values of buffer size. Fig. 6 shows the average throughput under different buffer sizes when the bottleneck link bandwidth is 400 Mbps and 5 Mbps, respectively. It can be seen from Fig. 6(a) that the average throughput of all the protocols increases as the buffer size grows, and ACCF and Cubic TCP achieve higher throughput than other TCP variants when the bottleneck link bandwidth is 400 Mbps. However, the average throughput of Fast TCP falls rapidly when the buffer size is less than 500 pkts, even is smaller than that of TCP Reno. The main reason is Fast TCP uses the delay information as the only congestion indicator. There are a large number of packet losses in Fast TCP when buffer size is small, resulting in the error of the delay estimation. The throughput of ACCF and Cubic TCP do not change significantly for the varied buffer size. For the lower buffer sizes, ACCF achieves better performance than the other TCP protocols. For the higher buffer sizes, its throughput slightly increases, and then approximately achieves the full utilization when the buffer size becomes higher than 500 pkts. Although TCP Illinois also do not change significantly for the varied buffer size, its average throughput is lower than that of ACCF. There are two reasons for this: (1) TCP Illinois uses the delay information to calculate the congestion window even after packet loss occurs, which would result in small increase factor of the congestion window and thereby degrading the performance; (2) TCP Illinois sets the maximum and minimum for the increase factor of the congestion window, which would limit its bandwidth utilization in high-speed networks. As mentioned before, ACCF uses the loss-based CC after packet loss, and thus avoids performance degradation resulted from the delay estimation error. Cubic TCP and ACCF use the concave function to update the window size. The function enables the protocols and network stable while maintaining high network utilization. Hence, the average throughput of Cubic TCP and ACCF is higher than others. In addition, ACCF uses MI to update the window size at startup so as to detect available bandwidth as soon as possible. Therefore, the average throughput of ACCF is slightly higher than that of Cubic TCP, which uses slow start mechanism like TCP Reno. Fig. 6(b) shows that ACCF still achieves good performance when the link bandwidth is 5 Mbps. Since the window growth of Fast TCP and Cubic TCP are aggressive and there is packet loss or queuing delay used as the only congestion indicator, a large number of packets are dropped, and the average throughput of Fast TCP and Cubic TCP falls rapidly when the buffer size is less than 15 pkts. Also, TCP Illinois achieves the worse performance than ACCF when the buffer size is less than 15 pkts because the delay information

M. Wang et al. / Computer Networks 64 (2014) 308–321

(a) Bottleneck link bandwidth is 400Mbps

315

(b) Bottleneck link bandwidth is 5Mbps

Fig. 6. Average throughput versus buffer size.

(a) Buffer size is 50pkts

(b) Buffer size is 5pkts

Fig. 7. Average throughput versus packet loss rate when link bandwidth is 5 Mbps.

is still used to calculate the congestion window when packet loss occurs. ACCF achieves comparable performance with TCP Reno. The throughput of ACCF and TCP Reno do not change significantly for the varied buffer size, and the throughput of ACCF is slightly higher than that of TCP Reno when the buffer size becomes less than 10 pkts. This is still because ACCF has the ability to adapt the congestion control approaches to the varying network status, and uses more efficient and stable window growth function. Then we evaluate the performance of ACCF in a network with different random packet loss rate. Fig. 7 shows the average throughput when the bottle link bandwidth is 5 Mbps and packet loss rate is varied from 103 to 104. Fig. 8 shows the average throughput when the bottle link bandwidth is 400 Mbps and packet loss rate is varied from 105 to 106. It can be seen from Figs. 7 and 8 that the average throughput of all the protocols decreases as the packet loss rate increases and ACCF is able to maintain a high average throughput amongst the protocols.

As shown in Fig. 7(a) and Fig. 8(a), ACCF has comparable throughput with Fast TCP when the buffer size is large (i.e. 50 pkts when bandwidth is 5 Mbps and 2000 pkts when bandwidth is 400 Mbps), and their throughput are higher than other protocols. When the buffer size is large, packet loss events resulting from the network congestion are rare. Therefore, the delay-based approach can correctly detect the network congestion and achieve better performance than loss-based approach. It is noted that the average throughput of Fast TCP is slightly higher than that of ACCF. Since some of packet loss events result from random losses instead of the network congestion, the queuing delay dose not significantly increase and the target window of Fast TCP could not decrease. However, ACCF would set Wlast_max as Wtarget when detecting packet loss and Wlast_max is usually smaller than Wfast. This is the main reason why the average throughput of Fast TCP is slightly higher than that of ACCF. Fig. 7(b) and Fig. 8(b) show that ACCF still achieves good performance when

316

M. Wang et al. / Computer Networks 64 (2014) 308–321

(a) Buffer size is 2000pkts

(b) Buffer size is 500pkts

Fig. 8. Average throughput versus packet loss rate when link bandwidth is 400 Mbps.

the buffer size is small (i.e. 5 pkts when bandwidth is 5 Mbps and 500 pkts when bandwidth is 400 Mbps). The average throughput of FAST TCP is much lower than that of others when the buffer size is 5 pkts. This is because packet losses due to both random losses and network congestion could occur on this occasion. A large number of packet losses would result in performance degradation of Fast TCP, while ACCF turns to the loss-based CC after packet losses and uses the cubic function to update the congestion window. Therefore, ACCF achieves higher performance than others. From the simulation results, it is demonstrated that ACCF outperforms Fast TCP, Cubic TCP, TCP Illinois and TCP Reno in term of average throughput. This is mainly because of the adaptive nature of ACCF. If the buffer size is large and there is no packet loss in the routers, ACCF uses the delay-based CC to conduct the congestion control. The delay-based CC can well detect the network congestion and quickly reach the equilibrium state. When the buffer size decreases and packet loss events are detected, ACCF turns to the loss-based CC for congestion control. The cubic window growth function can quickly approach the congestion point and keeps the window steady around the congestion point, thus it could achieve high bandwidth utilization in the high-speed networks as well as in the low-speed networks. 4.1.2. Fairness In order to evaluate the fairness performance of ACCF, we consider two different scenarios, including homogeneous RTT and heterogeneous RTT, and use the Jain’s fairness index (FI) [33] to quantitatively evaluate the fairness performance of the protocols when the bottleneck link bandwidth is 400 Mbps. For homogeneous RTT scenarios, three TCP flows pass through the same bottleneck path and the RTT is 120 ms for all users. The three sources start sending data at 10s and terminate at 300s simultaneously. Fig. 9 shows the average throughput of the three users using different TCP protocols. When the buffer size is 2000 pkts, as shown in Fig. 9(a), all the protocols enable the users fairly share

the link resources, and ACCF obtains approximately full utilization of bandwidth. As the buffer size decreases to 500 pkts, it can be observed from Fig. 9(b) that the total throughput of three flows in all protocols decreases, and the fairness performance of TCP Illinois and Fast TCP degrades significantly. However, ACCF not only achieves fair sharing of link resources among the three users, but also maintains high utilization of bandwidth. When the buffer size is large, the delay-based CC of ACCF can work well. Therefore, the fairness performance of ACCF is as good as that of Fast TCP. When the buffer size decreases to 500 pkts, loss events are detected. Fast TCP and TCP Illinois perform inefficiently under this network environment because the delay information is not correctly estimated. ACCF uses the loss-based CC and the cubic function to adjust the window size so that it still achieves an efficient fairness performance as well as the high bandwidth utilization. Also, Cubic TCP achieves good fairness performance and high utilization of bandwidth due to the cubic window growth function. For heterogeneous RTT scenarios, we conduct the experiments that two TCP flows with different RTT ratios share the bottleneck link, and the bandwidth is 400 Mbps. The RTT of each flow is one of 60 ms, 120 ms and 180 ms, thus the RTT ratios of the two flows are 1.5, 2 and 3 respectively. Table 1 presents the results when the buffer size is 500 pkts and 2000 pkts, respectively. The efficiency index, EI, is the amount of the concurrent flows’ throughput and FI is fairness index. It can be seen from Table 1(a) that when the buffer size is 500 pkts, the fairness performance of most protocols is significantly affected by the RTT ratio, and the flow with a short RTT obtains much higher throughput than the flow with a long RTT. Compared with other four protocols, ACCF overall achieves good fairness performance while maintaining higher throughput. From Table 1(b), ACCF performs most fairly among all protocols, and next does Cubic TCP. The window growth function in ACCF is independent of RTTs. This feature allows ACCF flows competing in the same bottleneck to have approximately the same window size independent of their RTTs, achieving good RTT-fairness.

317

M. Wang et al. / Computer Networks 64 (2014) 308–321

(a) Buffer size is 2000pkts

(b) Buffer size is 500pkts

Fig. 9. Average throughput of 3 homogeneous RTT (120 ms) users.

Table 1 Simulation results of EI and FI when bandwidth is 400 Mbps. RTT ratio

1.5

Protocols

T1

2

3

T2

EI

FI

T1

T2

EI

FI

T1

T2

EI

FI

(a) Buffer size is 500 pkts TCP Reno 21.91 Cubic TCP 0.14 Fast TCP 10.47 TCP Illinois 94.38 ACCF 103.40

76.34 320.35 110.49 279.90 259.12

98.25 320.49 120.96 374.28 362.52

0.7652 0.5004 0.5939 0.8028 0.8442

58.60 140.78 4.74 105.72 53.54

172.18 256.90 181.82 291.92 319.91

230.78 397.68 186.56 397.64 373.45

0.8050 0.9214 0.5260 0.8202 0.6628

22.93 127.36 103.02 84.54 189.96

166.78 269.41 227.72 311.56 205.11

189.72 396.77 330.74 396.11 395.07

0.6349 0.8864 0.8756 0.7527 0.9985

(b) Buffer size is 2000 pkts TCP Reno 21.91 Cubic TCP 124.42 Fast TCP 4.18 TCP Illinois 105.23 ACCF 190.11

76.34 265.61 323.22 237.31 198.15

98.25 390.03 327.40 342.54 388.26

0.7652 0.8841 0.5129 0.8706 0.9996

58.60 124.14 154.24 63.89 193.87

172.18 271.66 214.07 333.90 201.27

230.78 395.80 368.31 397.79 395.14

0.8050 0.8780 0.9743 0.6846 0.9996

22.93 105.63 38.44 63.74 189.96

166.78 291.56 355.08 334.14 205.11

189.72 397.19 393.52 397.88 395.07

0.6349 0.8203 0.6070 0.6841 0.9985

FI: Fairness Index.

4.1.3. TCP-friendliness For the evaluation of TCP-friendliness performance, we conduct the simulations that two sources are specified to run TCP Reno while two sources implement the TCP variants in a homogeneous RTT scenario. Figs. 10 and 11 show the average throughput of the four flows with different bandwidth and different buffer sizes in which the number 1 and 2 denote the flows using TCP Reno and the number 3 and 4 denote the flows using other protocols. From these figures, it can be seen that even the bandwidth and buffer size change, Cubic TCP, the loss-based protocol, overall performs unfair and significantly ‘‘grab’’ the bandwidth of TCP Reno and thereby reducing the average throughput of TCP Reno flows. For the delay-based protocol Fast TCP, if the buffer size is less than the number of packets that need to be maintained at routers, Fast TCP performances worse than Cubic TCP, as shown in Fig. 10(b) and Fig. 11(b). TCP-Illinois performs better than Cubic TCP over high-speed links while it performs worse over low-speed links. When the bandwidth is 5 Mbps and the buffer size is 50 pkts, the TCP Reno flows achieve higher throughput than the TCP Illinois flows. We also note that when the router buffer size becomes large, ACCF and Fast TCP

achieve better friendliness to the TCP Reno flows, as shown in Fig. 10(a) and Fig. 11 (a). At this time, ACCF sources turn to the delay-based CC and always maintain the predefined number of packets at routers, and the redundant buffer is available for the TCP Reno flows. Therefore, the TCP Reno flows could share the bandwidth with the ACCF flows. While ACCF uses the loss-based CC for window size control when buffer size is less than the specified packet number, and thus lead to its TCP-friendliness performance is similar to Cubic TCP. The more available buffer is provided, the higher bandwidth utilization can be achieved by the TCP Reno flows. The simulation results demonstrate that ACCF does not always suppress the concomitant TCP Reno flows and achieves better TCP-friendliness performance than other three TCP variants under different bandwidth and buffer constrains. 4.2. Performance evaluation over real networks To test the performance of ACCF over deployed and real-world networks, we embed ACCF into the Linux kernel (v 2.6.18) as a module. For comparisons, Fast TCP is implemented based on the ns-2 code of FAST TCP [34]. Other TCP

318

M. Wang et al. / Computer Networks 64 (2014) 308–321

(a) Buffer size is 50pkts

(b) Buffer size is 5pkts

Fig. 10. TCP-friendliness when the bandwidth is 5 Mbps.

(a) Buffer size is 3000pkts

(b) Buffer size is 500pkts

Fig. 11. TCP-friendliness when the bandwidth is 400 Mbps.

variants are available on the Linux kernel v2.6.18, including TCP Reno, Cubic TCP and TCP Illinois. Tested ACCF and the other TCP variants use the clients located in Sichuan University, Chengdu, China and a server is put in Konkuk University, Seoul, Korea on the Internet. Konkuk University is connected to KOREN Seoul XP in 1 Gbps and Seoul XP is connected to China Education and Research Network (CERNET) Hong Kong XP in 10 Gbps [35]. RTT between Sichuan University and Konkuk University is about 126 ms. The server and clients use the Linux OS (kernel version 2.6.18). The files are transmitted from the two clients to the server at the same time. We conduct the experiments through different access networks, including China Telecom Broadband and CERNET. The total access link bandwidth of CERNET is 1.2Gbps at Sichuan University and that of China Telecom Broadband is 4 Mbps in our lab. Each algorithm lasts 5–10 min, so that (1) the algorithms tested are able to reach close to steady-state performances; (2) the period is consistent with the durations of a

Table 2 Average throughput over the real networks. Number

Protocol

Broadband (Kbps)

CERNET (Mbps)

1

ACCF TCP Reno Speed up (%) ACCF Cubic TCP Speed up (%) ACCF Fast TCP Speed up (%) ACCF TCP Illinois Speed up (%)

192.40 159.69 20.48 176.83 157.81 12.06 228.63 207.99 9.92 171.93 140.21 22.62

1.26 0.44 189.66 1.16 0.49 138.66 1.06 0.60 75.52 1.23 0.38 225.83

2

3

4

reasonably large percentage of the TCP based sessions on the Internet (e.g. YouTube streaming of a single piece of content, synchronizing emails, refreshing one web page, etc.). In the performance measures, ACCF is compared with

M. Wang et al. / Computer Networks 64 (2014) 308–321

(a) CERNET

319

(b) Broadband

Fig. 12. Throughput variation at different time periods.

TCP Reno, Cubic TCP, Fast TCP and TCP Illinois on four time periods, respectively. Our results are summarized in Table 2 and Fig. 12. Throughout the experiments, ACCF achieves speedup ratios up to 225.83% compared with average throughput of other TCP congestion control algorithms, as shown in Table 2. Fig. 12 presents the throughput variation on different time periods when data is delivered to Soul through CERNET and the broadband, respectively. The x label represents the four time periods when conducting the tests, and they are 7 a.m. to 8 a.m., 10 a.m. to 11 a.m., 4 p.m. to 5 p.m. and 9 p.m. to 10 p.m. respectively. It can be seen from the results that the adaptive nature of ACCF makes it achieve better throughput performance than other tested variants under different network status. When accessing the server through the CERNET, ACCF significantly outperforms other variants on all tested time periods as shown in Fig. 12(a). For the comparison with Fast TCP, the throughput of ACCF is slightly higher than that of Fast TCP on the first time period. This is probably because the network is light during the period and ACCF utilizes the delay-based CC for the window control. When accessing the server through the broadband, the available bandwidth is much lower than that through the CERNET as shown in Fig. 12 (b). The average throughput of all protocols becomes small because the window increase is limited. However, ACCF still achieves better throughput than TCP Reno, Fast TCP and TCP Illinois, and achieves comparable performance with Cubic TCP, especially on the second, third and fourth period. This is because ACCF utilizes the loss-based CC for the window control when the network is heavy and the delay-based approach performs inefficiently. 5. Discussion In the simple case, we integrate the congestion control approaches of Fast TCP and Cubic TCP into ACCF. This approach requires storing and updating the state variables of all integrated protocols, e.g., ave_RTT, baseRTT and Wlast_max. As the integrated protocols increase, the storage

and computation overhead at the endpoints would be increased. Nevertheless, we think this overhead would have little effect on the performance of endpoints because today’s endpoints have great storage and computing power (and with existing protocols, the congestion control algorithms are not very complicated). Our work is only an initial attempt at the adaptive congestion control approaches, and there is much to do before ACCF can be used in boarder types of networks:  A large number of existing TCP variants, especially the characteristics of congestion control approaches, should be carefully investigated and classified according to the network environments that they are applied to.  More network parameters which can characterize various network environments should be abstracted. In this work, we only use two parameters (i.e., packet loss event and congestion window variation) to estimate the variations of available network bandwidth.  The way how to switch the congestion control approaches need to further investigate. In current implementation, we integrate the two congestion control approaches into ACCF. Besides, the transition of different congestion control approaches can also be done by installing a lightweight agent in endpoints to explicitly change TCP sessions. 6. Conclusions In this paper, we propose ACCF, a flexible, scalable and adaptive congestion control framework. It can automatically switch the congestion control mechanisms according to the network status. Through a simple case study of ACCF on the networks with high BDP, we demonstrate how ACCF achieves the process of adapting congestion control mechanisms to varying network conditions. In the simple case, simulation results and performances measured in real networks show significant performance improvements in term of throughput and fairness over state-of-the-art TCP variants such as TCP Reno, Cubic

320

M. Wang et al. / Computer Networks 64 (2014) 308–321

TCP, Fast TCP and TCP Illinois. Specifically, it is observed from simulation results that ACCF can always achieve higher average throughput than other four protocols in different network status, including different router buffer sizes and different link bandwidth. For the fairness, ACCF performs well in homogeneous and heterogeneous RTT scenarios. Also, ACCF is able to achieve better performance on TCP-friendly than most of other TCP variants. For the real network tests, ACCF achieves speedup ratios up to 225.83% compared with average throughput of other TCP congestion control algorithms. In CERNET, ACCF achieves significantly higher performance than other variants. In the broadband network, the average throughput of ACCF is a little higher than that of TCP Reno and Cubic TCP and significantly higher than TCP Illinois in both networks on all tested time periods. Our current implementation for ACCF is limited to the high BDP networks, but can be extended to adapt to various network environments and support new congestion control algorithms. As future work, we intent to extend ACCF based on its architecture to a wide range of the network environments by integrating a greater variety of congestion control algorithms. Acknowledgment This work was supported by the National Natural Science Foundation of China (91338107, 11102124), the Ph.D. Program Foundation of Ministry of Education of China (20130181110095), the Program for New Century Excellent Talents in University of Ministry of Education of China (NCET-10-0604), the Provincial Key Science and Technology Research and Development Program of Sichuan, China (2013SZ0002, 2014SZ0109), and the Humanities and Social Sciences Project of Ministry of Education of China (13YJCZH233). References [1] V. Jacobson, Congestion avoidance and control, ACM SIGCOMM Comput. Commun. Rev. 18 (4) (1988) 314–329. [2] M. Allman, Initial Congestion Window Specification, 2010. . [3] Y. Chen, R. Griffth, J. Liu, R.H. Katz, A.D. Joseph, Understanding TCP incast throughput collapse in datacenter networks, in: Proc. of the 1st ACM workshop on Research on enterprise networking (WREN 2009), Barcelona, Spain, August 2009, pp. 73–82. [4] J. Chu, Tuning TCP parameters for the 21st century, 2009. . [5] V. Vasudevan, A. Phanishayee, H. Shah, E. Krevat, D.G. Andersen, G.R. Ganger, G.A. Gibson, B. Mueller, Safe and effective fine-grained TCP retransmissions for datacenter communication, ACM SIGCOMM Comput. Commun. Rev. 39 (4) (2009) 303–314. [6] K. Winstein, H. Balakrishnan, End-to-end transmission control by modeling uncertainty about the network state, in: Proc. of the 10th ACM Workshop on Hot Topics in Networks (HotNets-XI), Cambridge, MA, November 2011, pp. 1–19. [7] S. Floyd, T. Henderson, The New Reno modification to TCP’s Fast Recovery Algorithm, RFC 2582, April 1999. [8] S. Floyd, J. Mahdavi, M. Mathis M. Podolsky, An Extension to the Selective Acknowledgement (SACK), RFC 2883, July 2000. [9] L.S. Brakmo, L.L. Perterson, TCP Vegas: end-to-end congestion avoidance on a global Internet, IEEE J. Select. Areas Commun. 13 (8) (1995) 1465–1480.

[10] L. Xu, K. Harfoush, I. Rhee, Binary increase congestion control (BIC) for fast long-distance networks, in: Proc. of IEEE INFOCOM 2004, Hong Kong, China, March 2004, pp. 2514–2524. [11] S. Ha, I. Rhee, L. Xu, CUBIC: a new TCP-friendly high-speed TCP variant, Oper. Syst. Rev. (ACM) 42 (5) (2008) 64–74. [12] D.J. Leith, R.N. Shorten, H-TCP protocol for high-speed long-distance networks, in: Proc. of the 2nd workshop Protocols Fast Long Distance Networks, Argonne, Canada, February 2004. [13] S. Liu, T. Basar, R. Srikant, TCP-Illinois: a loss- and delay-based congestion control algorithm for high-speed networks, Perform. Eval. 65 (6–7) (2008) 417–440. [14] K. Tan, J. Song, Q. Zhang, M. Sridharan, A compound TCP approach for high-speed and long distance networks, in: Proc. of IEEE INFOCOM, Barcelona, Spain, April 2006, pp. 1–12. [15] S. Mascolo, C. Casetti, M. Gerla, M.Y. Sanadidi, R. Wang, TCP Westwood: bandwidth estimation for enhanced transport over wireless links, in: Proc. of the 7th Annual International Conference on Mobile Computing and Networking, Rome, Italy, July 2001, pp. 287–297. [16] I.F. Akyildiz, X. Zhang, J. Fang, TCP-Peach+: enhancement of TCPPeach for satellite IP networks, IEEE Commun. Lett. 6 (7) (2002) 303– 305. [17] M. Alizadeh, A. Greenberg, D. Maltz, J. Padhye, P. Patel, B. Prabhakar, S. Sengupta, M. Sridharan, Data center TCP (DCTCP), ACM SIGCOMM Comput. Commun. Rev. 40 (4) (2010) 63–74. [18] S. Floyd, R. Gummadi, S. Shenker, Adaptive RED: an algorithm for increasing the robustness of RED’s active queue management, Technical Report, ACIRI, 2001. [19] K. Nichols, V. Jacobson, Controlling queue delay, Commun. ACM 55 (7) (2012) 42–50. [20] N. Dukkipati, T. Refice, Y. Cheng, J. Chu, T. Herbert, A. Agarwal, A. Jain, N. Sutin, An argument for increasing TCP’s initial congestion window, ACM SIGCOMM Comput. Commun. Rev. 40 (3) (2010) 26–33. [21] J. Chu, N. Dukkipati, et al., Increasing TCP’s Initial Window, RFC6928, April 2013. [22] J. Touch, Automating the Initial Window in TCP, July 2012. . [23] Keith Winstein, Hari Balakrishnan, TCP ex machina: computergenerated congestion control, in: Proc. of ACM SIGCOMM 2013, Hong Kong, China, August 2013, pp. 1–12. [24] Monia Ghobadi, Soheil Hassas Yeganeh, Yashar Ganjali, Rethinking end-to-end congestion control in software-defined networks, in: Proc. of the 11th ACM Workshop on Hot Topics in Networks (HotNets-XI), Redmond, WA, October 2012, pp. 61–66. [25] M. Allman, S. Floyd, C. Partridge, Increasing TCP’s Initial Window, RFC 3390, October 2002. [26] D.X. Wei, C. Jin, S.H. Low, S. Hegde, FAST TCP: motivation, architecture, algorithms, performance, IEEE/ACM Trans. Netw. 14 (6) (2006) 1246–1259. [27] B. Miller, K. Avrachenkov, K. Stepanyan, G. Miller, Flow control as stochastic optimal control problem with incomplete information, 2004. . [28] K. Kaneko, F. Tomoki, S. Zhou, K. Jiro, TCP-fusion: a hybrid congestion control algorithm for high-speed networks, in: Proc. of PFLDnet, LA, USA, February 2007, pp. 31–36. [29] Wenjun Xu, Zude Zhou, D.T. Phamb, et al., Hybrid congestion control for high-speed networks, J. Netw. Comput. Appl. 34 (4) (2011) 1416– 1428. [30] A. Tang, J. Wang, S.H. Low, M. Chiang, Equilibrium of heterogeneous congestion control: existence and uniqueness, IEEE/ACM Trans. Netw. 15 (4) (2007) 824–837. [31] A. Tang, X. Wei, S.H. Low, M. Chiang, Equilibrium of heterogeneous congestion control: optimality and stability, IEEE/ACM Trans. Netw. 18 (3) (2010) 844–857. [32] J. Mo, R.J. La, V. Anantharam, J. Walrand, Analysis and comparison of TCP Reno and Vegas, in: Proc. of INFOCOM’99, New York, USA, March 1999, pp. 1556–1563. [33] R. Jain, D. Chiu, W. Hawe, A quantitative measure of fairness and discrimination for resource allocation in shared computer systems, DEC Research Report TR-301, 1984. [34] T. Cui, L. Andrew, FAST TCP simulator module for ns-2, version 1.1c, 2007. . [35] KOREN Future Network Test Bed, 2011. .

M. Wang et al. / Computer Networks 64 (2014) 308–321 Min Wang received the M.S. degree in Computational Mathematics from Yunnan University of China, Kunming in 2004. She is currently a Ph.D. student at the School of Computer Science of Sichuan University. Her research interests cover a wide variety of topics in wireless and satellite networks, with emphasis on design of transport layer protocols for wireless networks.

Junfeng Wang received the M.S. degree in Computer Application Technology from Chongqing University of Posts and Telecommunications, Chongqing in 2001 and Ph.D. degree in Computer Science from University of Electronic Science and Technology of China, Chengdu in 2004. From July 2004 to August 2006, he held a postdoctoral position in Institute of Software, Chinese Academy of Sciences. From August 2006, Dr. Wang is with the College of Computer Science, Sichuan University, Chengdu as a professor. His recent research interests include spatial information networks, network and information security, and intelligent transportation system.

321

Sunyoung Han received the B.S. degree in computer science from Seoul National University, and M.S. and Ph.D. degree in computer science from KAIST, Seoul, Korea, in 1977, 1979 and 1988, respectively. Since 1981, he is a professor of the Department of Computer Science and Engineering, Konkuk University, Seoul, Korea. He was a Dean of College of Information & Telecommunication, Konkuk University from September 2004 to February 2009. His research interests include overlay networks, future Internet, mobile Internet, IP Multicasting, vehicular networks and real-time distributed communication systems.