Agile-SD: A Linux-based TCP congestion control algorithmfor supporting high-speed and short-distance networks

Mohamed A. Alrshah a,n, Mohamed Othman a,1, Borhanuddin Ali b, Zurina Mohd Hanapi a

a Department of Communication Technology and Network, Universiti Putra Malaysia, 43400 UPM, Serdang, Selangor D.E., Malaysiab Department of Computer and Communication Systems Engineering, Universiti Putra Malaysia, 43400 UPM, Serdang, Selangor D.E., Malaysia

a r t i c l e i n f o

Article history:Received 21 October 2014Received in revised form21 April 2015Accepted 8 May 2015Available online 3 June 2015

Keywords:CCALinux TCPHigh-speedShort-distanceBandwidth UtilizationSmall buffer

a b s t r a c t

Recently, high-speed and short-distance networks are widely deployed and their necessity is rapidlyincreasing everyday. This type of networks is used in several network applications; such as Local AreaNetworks (LAN) and Data Center Networks (DCN). In LANs and DCNs, high-speed and short-distancenetworks are commonly deployed to connect between computing and storage elements in order toprovide rapid services. Indeed, the overall performance of such networks is significantly influenced bythe Congestion Control Algorithm (CCA) which suffers from the problem of bandwidth under-utilization,especially if the applied buffer regime is very small. In this paper, a novel loss-based CCA tailored forhigh-speed and Short-Distance (SD) networks, namely Agile-SD, has been proposed. The maincontribution of the proposed CCA is to implement the mechanism of agility factor. Further, intensivesimulation experiments have been carried out to evaluate the performance of Agile-SD compared toCompound and Cubic which are the default CCAs of the most commonly used operating systems. Theresults of the simulation experiments show that the proposed CCA outperforms the compared CCAs interms of average throughput, loss ratio and fairness, especially when a small buffer is applied. Moreover,Agile-SD shows lower sensitivity to the buffer size change and packet error rate variation whichincreases its efficiency.

& 2015 Elsevier Ltd. All rights reserved.

1. Introduction

In the last few decades, the necessity of high-speed and short-distance networks is rapidly increasing everyday due to their widedeployment. Several network applications, such as Local Area Net-works (LAN) and Data Center Networks (DCN), are implementing thistype of networks (Buyya et al., 2008; Armbrust et al., 2010). TheseLANs and DCNs serve a very wide range of network-based applica-tions; such as web hosting, searching engines, social media, multi-media broadcasting and storage drives. In the environment of LANs, asshown in Fig. 1, and DCNs, as shown in Fig. 2 (Al-Fares et al., 2010; Wuand Yang, 2012; Yoo et al., 2012; Prakash et al., 2012), high-speed andshort-distance networks are commonly deployed to connect comput-ing and storage elements to each other in order to provide rapidservices.These networks have certain characteristics which are widelydifferent from other types of networks; for instance, link delay isvery small which can be a few milliseconds or even hundreds of

microseconds and the Bandwidth-Delay-Product (BDP) of the link isvery small compared to its equivalent in high-speed and long-distancenetworks (Tahiliani et al., 2012; Vasudevan et al., 2009).

These attributes could negatively affect the performance of theTransmission Control Protocol (TCP) by making it either moreaggressive or more conservative based on the applied approach. Infact, the Congestion Control Algorithm (CCA) is one of the mainparts of TCP. It significantly affects the overall performance of suchnetworks, because it is still suffering from the problem of band-width under-utilization, especially if the applied buffer regime isvery small. This under-utilization of bandwidth is caused by thevariation of the aforementioned characteristics of the networkswhich results in either a slow growth of cwnd or an over-injectionof data into the network (Afanasyev et al., 2010; Scharf, 2011;Callegari et al., 2012, 2014; Lar and Liao, 2013; Acharya, 2012;Alrshah et al., 2014).

In order to solve the problem of bandwidth under-utilization overhigh-speed and Short-Distance (SD) networks, a new loss-based CCA,namely Agile-SD, has been proposed. The main contribution of theproposed CCA is to implement themechanism of agility factor. Further,intensive simulation experiments have been carried out to evaluatethe performance of Agile-SD compared to Compound (the default CCAof MS Windows since Windows Vista) and Cubic (the default CCA ofLinux since Kernel 2.6.16) which are the default CCAs of the most

Contents lists available at ScienceDirect

journal homepage: www.elsevier.com/locate/jnca

Journal of Network and Computer Applications

http://dx.doi.org/10.1016/j.jnca.2015.05.0111084-8045/& 2015 Elsevier Ltd. All rights reserved.

n Corresponding authors.E-mail addresses: mohamed.asnd@gmail.com (M.A. Alrshah),

mothman@upm.edu.my (M. Othman).1 The author is also an associate researcher at the Computational Science and

Mathematical Physics Lab, Institute of Mathematical Science, Universiti PutraMalaysia.

Journal of Network and Computer Applications 55 (2015) 181–190

commonly used operating systems (Afanasyev et al., 2010; Alrshahet al., 2014).

The rest of this paper is organized as follows: the related workis presented in Section 2 while Section 3 presents the proposedalgorithm “Agile-SD”. Section 4 explains the used approach ofperformance evaluation which contains the experiments' setup,network topology, performance metrics, results and discussion.Finally, Section 5 presents the conclusion and the future work.

2. Related work

In order to solve the problem of bandwidth under-utilization,Cubic (Ha and Rhee, 2008), Scalable TCP (Kelly, 2003), HS-TCP(Floyd, 2003), BIC (Xu et al., 2004), HCC (Xu et al., 2011), H-TCP(Leith, 2004), TCP Africa (King et al., 2005), TCP Compound (Tanand Song, 2006), Fusion (Kaneko et al., 2007), TCP illinois (Liuet al., 2008) and YeAH (Baiocchi et al., 2007) have been developedand implemented in the real operating systems. All of these TCPvariants are still unable to fully utilize the available bandwidths ofhigh-speed networks, especially if the used buffer size is less thanthe BDP of the link (Afanasyev et al., 2010; Scharf, 2011; Callegariet al., 2012, 2014; Lar and Liao, 2013; Acharya, 2012; Alrshah et al.,2014).

Further, some researchers tried to solve the aforementionedproblem by proposing a set of CCAs or TCP variants; such as DCTCP(Alizadeh et al., 2010), ICTCP (Wu et al., 2013), IA-TCP (Hwang etal., 2012) and D2TCP (Vamanan et al., 2012) which designed fordata center networks. All of these TCP variants are still suffering

from some critical problems, such as the problem of TCP outcastwhich has not been solved yet (Tahiliani et al., 2012).

Furthermore, some researchers tried to improve the performanceof TCP by using parallel approaches; such as AppTCP (Wang et al.,2014), GridFTP (Allcock et al., 2005), pTCP (Hsieh and Sivakumar,2002), BBCP (Hanushevsky et al., 2001), PSockets (Sivakumar et al.,2000), MulTCP (Crowcroft and Oechslin , 1998), DPSS (Tierney et al.,1994) and Parallel-TCP (Alrshah and Othman, 2009, 2013). Most ofparallel schemes have achieved high bandwidth utilization, butunfortunately they have another issues which limited their deploy-ments. One of these issues is that all of the parallel schemes have avery high aggressiveness level compared to the existing single-basedTCP variants. This aggressive behavior negatively affects the fairness(Fu and Indulska, 2005; Fu et al., 2007).

However, the widely deployed CCAs; such as Compound andCubic which have been set as the default CCAs in MS Windows andLinux operating systems, respectively; are playing the importantrole in the real networks. Thus, Compound and Cubic should beused as a benchmark, to confirm the performance of any newlyproposed CCA or TCP variant. For this reason, these two CCAs aregoing to be briefly explained in the next subsections.

2.1. Compound TCP (C-TCP)

The widely deployed TCP variant namely C-TCP (Tan and Song,2006) is the default CCA of MS Windows since Windows Vista. C-TCPcombines HS-TCP (Floyd, 2003) and NewReno (Floyd and Henderson,1999) to be used as fast and slow modes, respectively. C-TCP is a loss-delay-based approach relies on multi-modes switching to increasethe bandwidth utilization over high-speed networks. Generally, itimproves the performance of TCP to some extent but it introducesanother problem which is the RTT mis-estimation. This problem hasbeen inherited from Vegas (Brakmo and Peterson, 1995) and it cannegatively affect the overall performance of the protocol (Afanasyevet al., 2010; Alrshah et al., 2014).

2.2. CUBIC TCP (Cubic)

Cubic (Ha and Rhee, 2008) is the default CCA of Linux operatingsystems since its implementation in Kernel 2.6.16. Cubic enhancesthe bandwidth utilization over high-speed networks by increasingthe cwnd in the congestion avoidance phase by a cubic function ofthe elapsed time since last loss. In addition, Cubic forces its cwndnot to be less than the pre-calculated cwnd of NewReno. Despiteall, Cubic is still suffering from the under-utilization of high-speedFig. 1. A network topology for LAN.

Fig. 2. Multi-rooted hierarchical topology of data centers.

M.A. Alrshah et al. / Journal of Network and Computer Applications 55 (2015) 181–190182

bandwidth specifically when the used buffer size is small(Afanasyev et al., 2010; Alrshah et al., 2014; Ha and Rhee, 2008).

2.3. The latest issues

Recent studies have revealed that all of the current TCP variantshave different levels of inability on fully utilizing the bandwidthsover the new generation of high-speed networks, especially if anear-zero buffer is applied. Thus, it becomes very necessary todesign a new CCA to increase the bandwidth utilization over suchnetworks (Afanasyev et al., 2010; Alrshah et al., 2014).

3. Agile-SD: the proposed algorithm

Algorithm 1 explains the Agile-SD mechanism which is gearedto work on high-speed and short-distance networks to enhancethe overall performance and bandwidth utilization while preser-ving the fairness. Moreover, Fig. 3 shows the control flow diagramof Agile-SD and the following subsections explain the proposedalgorithm in more details.

Algorithm 1. Agile-SD congestion avoidance.

3.1. The agility factor mechanism

As known, Chu et al. (2013) increases the initial value of TCPcwnd to 10 packets, but Agile-SD initializes its cwnd by 2 packets inorder to focus on the impact of CA on bandwidth utilization.However, in the future implementations the initial cwnd should beset to 10 to gain better bandwidth utilization.

Clearly, Agile-SD increases its cwnd in the stage of congestionavoidance by fraction similarly as the existing CCAs. But, Agile-SDincreases its cwnd by λ=cwnd to show a convex curve unlike thestandard TCP which increases its cwnd linearly by 1=cwnd. Themain contribution of Agile-SD is the unique cwnd growth functionwhich relies on the agility factor mechanism which symbolized byλ, as shown in the following equation:

λ¼maxλmax � gapcurrent

gaptotal; λmin

� �ð1Þ

where gaptotal exemplifies the amount of decrease in the cwndwhich caused by the loss event. In other words, gaptotal representsthe released amount from the bandwidth after loss. gaptotal iscalculated as the distance between the maximum recorded limit ofthe bandwidth (cwndloss) and the cwnddegraded as in the followingequation:

gaptotal ¼maxððcwndloss�cwnddegradedÞ;1Þ ð2Þ

While, gapcurrent is calculated as the difference between themaximum recorded limit of the bandwidth (cwndloss) and thecurrent cwnd, as in the following equation:

gapcurrent ¼maxððcwndloss�cwndÞ;1Þ ð3Þ

Simply, λ is used to mitigate the impact of loss degradation on theoverall performance of TCP. Specifically, λ shortens the time of epochwhich is needed by CCA to move its cwnd from cwnddegraded to cwndlossor to the maximum allowed cwnd, as shown in Fig. 4. In order toincrease the bandwidth utilization, λ speeds up the growth of cwndwhen the current cwnd is far away from the last cwndloss. While, it

Fig. 3. The control flow diagram of Agile-SD.

M.A. Alrshah et al. / Journal of Network and Computer Applications 55 (2015) 181–190 183

conservatively slows down the growth of cwnd when the currentcwnd nearing to the last cwndloss.

More specifically, to ensure that the performance of Agile-SD isnot less than the standard TCP, λmin must be always set to 1 whileλmax must be always set to a value Z1. However, if λmax is set to 1,Agile-SD will behave exactly similar to NewReno. But, if it was setto a value 41, such as 2, 3 or 4, it would clearly improve theoverall performance.

After loss detection by receiving three duplicate ACKs, Agile-SDinitiates its agility factor by λmax, then reduces it every cycletowards λmin. Nevertheless, it restarts by λmax again if anotherthree duplicate ACKs are received as shown in Fig. 5. Consequently,it is very clear that αis directly proportional to λ, and λ is reverselyproportional to the current size of cwnd, as shown in Fig. 6. Inother words, the aggressiveness of the proposed algorithmincreases whenever the difference between cwnd and cwndlossincreases, as in the following equation:

αmax ¼ limgapcurrent-gaptotal

maxλmax � gapcurrent

gaptotal; λmin

� �

cwnd

¼ λmax

cwndð4Þ

Contrarily, it decreases its aggressiveness whenever the utiliza-tion is around to touch the maximum available bandwidth, as inthe following equation:

αmin ¼ limgapcurrent-zero

maxλmax � gapcurrent

gaptotal; λmin

� �

cwnd

¼ λmin

cwndð5Þ

In general, Agile-SD reduces the cycle time which by its rolereduces the epoch time to overcome the problem of slow evolution ofcwnd provided by the standard TCP, as shown early in Fig. 4. On onehand, this behavior guarantees the performance of Agile-SD not to belower than the standard TCP. Thus, it increases the bandwidthutilization by improving the ability of Agile-SD to expose the conditionof the underlying network as shown in Fig. 6. On the other hand, itreduces the sensitivity of Agile-SD to the loss rate.

3.2. The decrement of cwnd

The standard TCP applies the Multiplicative Decrease mechan-ism which halves the cwnd after any loss detection, by receivingthree duplicate ACKs, regardless of which stage the loss is detectedin. Unlikely, Agile-SD decreases its cwnd after any loss detection bytwo ways based on the stage which the loss is coming from. First, ifthe loss is detected in the slow start stage, Agile-SD reduces itscwnd to β1% of the latest cwnd as shown at Line 15 in Algorithm 1.Second, if the loss is detected in the congestion avoidance stage,Agile-SD reduces its cwnd to β2% of the latest cwnd as shown atLine 17 in Algorithm 1. Moreover, Agile-SD sets the ssthresh tocwnd�1, after any degradation, in order to avoid slipping into anundesirable slow start.

Since, the loss which happens in the slow start stage is moresevere than which happens in the congestion avoidance stage.Therefore, the value of β1 should be always less than β2. In otherwords, the reduction which follows a slow start loss should begreater than the reduction which follows a congestion avoidanceloss. Also, β1 and β2 must be reversely proportional to theirrelative λmax but the relation among them is still under

Fig. 4. The cwnd evolution of Agile-SD and the standard TCP.

Fig. 5. The concept of agility factor mechanism λ.

Fig. 6. Relation between α, λ and the bandwidth utilization.

M.A. Alrshah et al. / Journal of Network and Computer Applications 55 (2015) 181–190184

investigation to be revealed in the future work. Thus, wheneverthe values of β1 and β2 is increased, the value of λmax should beadaptively decreased and vice versa. For instance, if β1 and β2 areset to 0.9 and 0.95, respectively, where these values are compa-tible with λmax ¼ 3. Then, if β1 and β2 are reduced to 0.85 and 0.9,respectively, the value of λmax should be increased to a value, suchas 4 or 5, and so on.

3.3. Agile-SD overall behavior

Similar to standard TCP, Agile-SD starts by slow start to showan exponential increase until the detection of first loss; byreceiving three duplicate ACKs. This reduces its cwnd to β1% andtriggers the congestion avoidance function. In this stage, Agile-SDincreases its cwnd by αto show a convex curve. But, if the cwndbecomes closer to the bandwidth limit which is set as cwndloss, itstarts a linear increase until detecting another packet loss. If theevent of packet loss is detected, Agile-SD reduces its cwnd to β2%then repeats the same stages which follows the slow start stage.However, if timeout is detected at any stage, Agile-SD resets itscwnd to the initial value, as shown in Fig. 3.

For more understanding, assume that there is a TCP link withcwndloss ¼ 12; cwnddegraded ¼ 9 and a constant RTT equal to 20 ms,and the congestion avoidance stage is just started after the lossdirectly. Thus, the number of cycles needed by any CCA to reachcwndloss is 4 cycles which is equal to ðcwndloss�cwnddegradedþ1Þ.Consequently, the epoch time needed by the standard TCP, whichis “RTT-dependent”, is the number of needed cycles times RTT, so itwill be equal to 80 ms.

Instead, Agile-SD increases its cwnd independently from theRTT. Thus, every cycle consumes a time of RTT=λ to send a numberof cwnd=λ packets during that cycle, then it increases its cwnd by 1.Consequently, the epoch time needed by Agile-SD will be equal towhat shown in the following equation:

EpochTime¼Xki ¼ 1

RTTλi

ð6Þ

where k is the number of needed cycles.Suppose λmin and λmax are set to 1 and 4, respectively. So, λi will

take the value of [4, 3, 2, 1] sequentially, which will result in an epochtime equal to 41.66 ms. Thus, the epoch time of Agile-SD will beshrunk by around 48% from the epoch time of the standard TCP on thesame network link. This behavior helps Agile-SD to increase its cwndmore quickly than the other compared CCAs and consequentlyimproves the bandwidth utilization. In other words, the faster cwndgrowth is the higher bandwidth utilization and vice versa.

4. Performance evaluation of Agile-SD

The goal of this work is, to develop a new CCA, namely Agile-SD, which has the ability of increasing the bandwidth utilizationover high-speed and short-distance networks while maintainingfairness. Agile-SD CCA has been implemented as a pluggable LinuxCCA module which can be plugged into any Linux Kernel. As wellas, this module has the ability to be plugged into NS-2 networksimulator, as a Linux TCP, in order to evaluate its performancecompared to some of the widely deployed CCAs.

4.1. The experiments setup

In this work, intensive simulation experiments have been con-ducted using the well-known network simulator NS-2 version 2.35, toevaluate the proposed CCA by comparing its performance with C-TCPand Cubic. The conducted experiments have been divided into threemain scenarios: single-flow, sequentially established/terminated

multiple-flows, and synchronously established/terminated multiple-flows. Table 1 shows the setting of the experiments' parameters asused in this work.

In the first scenario of single-flow, there is only one pair ofsender and receiver, as shown in Fig. 7, which presents an idealcase with no congestion to show the ability of the evaluated CCAson achieving full bandwidth utilization. As for the second andthird scenarios of multiple flows, there are n pairs of sender andreceiver, as shown in Fig. 8, which have been used to simulate thenetwork congestion and to show its impact on the performancemeasurements of the evaluated CCAs. In the second scenario, theflows are sequentially established and terminated as shown inFig. 9(a). While in the third scenario, the flows are synchronouslyestablished and terminated as shown in Fig. 9(b).

In all of these experiments, a standard single dumbbell topol-ogy has been used, as shown in Figs. 7 and 8, where n is thecompeting senders (S1, S2, S3, …, Sn) which send data simulta-neously to n receivers (D1, D2, D3, …, Dn) through the sharedsingle bottleneck. All source and destination nodes are connectedto the bottleneck routers over LAN with 1 Gbps speed and 1 mspropagation delay. While the bottleneck link is 1 Gbps speed witha propagation delay of 4 ms (Wang et al., 2014). These experimentshave been repeated for each CCA separately with variable buffersize and variable packet error rate (PER). The buffer size variesfrom 5 to 500 packets while the PERs which have been used are10�4, 10�5 and zero PER.

Moreover, the performance metrics evaluated in this paper arethe average throughput, loss ratio, inter-fairness, intra-fairnessand RTT-fairness. Average throughput and loss ratio are evaluatedto reflect the ability of the TCP variant on utilizing the bandwidth.While, measuring inter-fairness, intra-fairness and RTT-fairness isto show the quality of sharing the link between the competing TCPflows based on Jain's fairness index (JFI) (Jain et al., 1984), asshown in the following equation:

JFIðx1; x2;…; xnÞ ¼ðPn

i ¼ 1 xiÞ2n �Pn

i ¼ 1 x2i

ð7Þ

Substantially, these experiments show the impact of bottleneckcongestion, buffer size and PER on the performance of the examinedCCAs and also show the performance changes when a smaller buffersize is applied. Moreover, the simulation time used in all experimentshas been set to 100 s which is enough for TCP to show its steady state.

Table 1Experiment parameters.

No. Parameter Value

1. CCAs Agile-SD, Cubic, C-TCP2. Link capacity 1 Gbps for all3. Link delay 1 ms (node to router)

4 ms (router to router)4. BDP 750 kb (As in (Jacobson and Braden, 1988))5. PER zero;10�5;10�4

6. Buffer size from 5 to 500 packets7. Packet size 1000 bytes8. Queuing Algo Drop-tail9. Traffic type FTP

10. SACK, FACK Disabled11. Simulation time 100 s

Fig. 7. Non-congested network topology.

M.A. Alrshah et al. / Journal of Network and Computer Applications 55 (2015) 181–190 185

4.2. Results and discussion

This subsection presents an analytical discussion of the beha-vior exhibited by the proposed CCA and the compared CCAs. Aswell as, it presents the results of the performance evaluation andshows the measurements of the average throughput, loss ratio,inter-fairness, intra-fairness and RTT-fairness.

4.2.1. The cwnd evolutionFundamentally, the target of CCAs is: to maximize the through-

put while minimizing the loss ratio and maintaining the fairness.Figure 10 shows the cwnd evolution of the studied CCAs based onthe buffer size change. Due to the mechanism of agility factor,Agile-SD expectedly shows the faster cwnd growth followed byCubic and C-TCP. This fast or slow evolution of cwnd is the core ofany CCA which would directly affect the other performancemetrics, such as throughput, loss ratio and it may affect thefairness as well.

In Fig. 10(a), it is very clear that Agile-SD reaches the maximumcwnd, which is about 1500 packets, in around 17 second thenstarts oscillating to show very short epochs, while, Cubic reachesthe maximum cwnd in about 60 seconds then starts oscillating todraw very long epochs. As for C-TCP, it fails to reach the maximumcwnd and touches only the edge of 110 packets then exhibits veryshort epochs. Indeed, the larger the cwnd, the higher the through-put and vice versa.

Interestingly, when the buffer size increases, the behavior ofthe studied CCAs relatively improves. Figure 10(b)–(e) shows thatAgile-SD and Cubic reduce their time of reaching the maximumcwnd whenever the buffer size increases. Besides, Agile-SD keepsshowing short epochs while Cubic remains drawing long epochs.Unlikely, C-TCP heightens its cwnd towards the maximum limitwhenever the buffer size increases. In fact, the wider oscillatingand/or the longer epochs is the lower bandwidth utilization andvice versa. Thus, the higher bandwidth utilization among thestudied CCAs would be provided by Agile-SD followed by Cubicthen C-TCP.

4.2.2. The average throughputIn the first scenario, as shown in Fig. 11(a), Agile-SD has

overcome the other CCAs in terms of average throughput due toits fast growth of cwnd resulted by the mechanism of agility factor.Moreover, Agile-SD presents lower sensitivity to PER than theothers, whereas, Cubic and C-TCP are highly affected by PERand they present a poor performance when the PER is increa-sed. However, in the cases of 10�4 and 10�5 PER as shown inFig. 11(b) and (c), C-TCP presents better performance than Cubic inmost cases. In general, Agile-SD achieves better throughput thanthe others in most cases even in the lossy environments. Clearly, itimproves the bandwidth utilization up to 55% in some cases of thisscenario.

For the second scenario, Fig. 11(d)–(f) show that Agile-SD hasovercome the other CCAs, in term of average throughput, at mostcases even when the buffer size is small and the PER is high.Furthermore, it improves the bandwidth utilization from 10% to40% in the cases of 5 packets buffer size. While in the thirdscenario, Agile-SD has outperformed the other CCAs in all casesespecially when a near-zero buffer is applied as shown in Fig. 11(g)–(i). Moreover, Agile-SD significantly improves the bandwidthutilization even when the PER is high. Thus, it provides up to 40%of improvement in some cases.

4.2.3. The loss ratioAs regarding to all scenarios, the studied CCAs have presented a

loss ratio lower than 0.5% which is considered as a negligible lossratio. Thus, Fig. 12 has been selected here as a sample of the lossratio results of all scenarios to save the space of this paper andbecause the rest of the figures have no much difference.Fig. 8. Network topology with standard dumbbell bottleneck.

Fig. 9. The sequence of establishments and terminations of the multiple flows scenarios. (a) Synchronously established/terminated flows scenario and (b) Synchronouslyestablished/terminated flows scenario.

M.A. Alrshah et al. / Journal of Network and Computer Applications 55 (2015) 181–190186

0

200

400

600

800

1000

1200

1400

1600

0 20 40 60 80 100

cwnd

(pac

kets

)

Simulation Time

Agile-SD

0

20

40

60

80

100

120

0 10 20 30 40 50 60 70 80 90 100

cwnd

(pac

kets

)

Simulation Time

compound

0

200

400

600

800

1000

1200

1400

1600

0 20 40 60 80 100

cwnd

(pac

kets

)

Simulation Time

cubic

0

200

400

600

800

1000

1200

1400

1600

0 20 40 60 80 100

cwnd

(pac

kets

)

Simulation Time

Agile-SD

0

200

400

600

800

1000

1200

0 20 40 60 80 100

cwnd

(pac

kets

)

Simulation Time

compound

0

200

400

600

800

1000

1200

1400

1600

0 20 40 60 80 100

cwnd

(pac

kets

)

Simulation Time

cubic

0

200

400

600

800

1000

1200

1400

1600

0 20 40 60 80 100

cwnd

(pac

kets

)

Simulation Time

Agile-SD

0

200

400

600

800

1000

1200

1400

1600

0 20 40 60 80 100

cwnd

(pac

kets

)

Simulation Time

compound

0

200

400

600

800

1000

1200

1400

1600

0 20 40 60 80 100

cwnd

(pac

kets

)

Simulation Time

cubic

0 200 400 600 800

1000 1200 1400 1600 1800

0 20 40 60 80 100

cwnd

(pac

kets

)

Simulation Time

Agile-SD

0 200 400 600 800

1000 1200 1400 1600 1800

0 20 40 60 80 100

cwnd

(pac

kets

)

Simulation Time

compound

0 200 400 600 800

1000 1200 1400 1600 1800

0 20 40 60 80 100

cwnd

(pac

kets

)

Simulation Time

cubic

0

500

1000

1500

2000

2500

0 20 40 60 80 100

cwnd

(pac

kets

)

Simulation Time

Agile-SD

0

500

1000

1500

2000

2500

0 20 40 60 80 100

cwnd

(pac

kets

)

Simulation Time

compound

0

500

1000

1500

2000

2500

0 20 40 60 80 100

cwnd

(pac

kets

)

Simulation Time

cubic

Fig. 10. TCP congestion window evolution. (a) buffer Size¼5 packets, (b) buffer size¼25 packets, (c) buffer size¼100 packets, (d) buffer size¼250 packets, (e) buffersize¼500 packets.

M.A. Alrshah et al. / Journal of Network and Computer Applications 55 (2015) 181–190 187

4.2.4. The fairnessAs for intra-fairness and RTT-fairness, all the studied CCAs are

interchangeably close to each other. However, in some cases Agile-SD seems more fair, especially when the applied buffer size issmall. Since the difference among the graphs of the results is verytrivial, Figs. 13 and 14 have been chosen as samples of intra-fairness and RTT-fairness, respectively.

Moreover, a separated experiment has been carried out toevaluate the inter-fairness among the studied CCAs and thestandard NewReno, using the same topology as shown in Fig. 8,where the result is shown in Fig. 15. For inter-fairness to NewReno,Agile-SD and C-TCP achieve around 0.76 while Cubic achievesabout 0.79 inter-fairness index. As for the inter-fairness to Cubic,

100 200 300 400 500 600 700 800 900

1000

5 10 25 50 100 250 500

Ave

rage

Thr

ough

put (

Mbp

s)

Buffer Size (Packets)

Agile_SD cubic compound

100 200 300 400 500 600 700 800 900

1000

5 10 25 50 100 250 500

Ave

rage

Thr

ough

put (

Mbp

s)

Buffer Size (Packets)

Agile_SD cubic compound

100 200 300 400 500 600 700 800 900

1000

5 10 25 50 100 250 500

Ave

rage

Thr

ough

put (

Mbp

s)

Buffer Size (Packets)

Agile_SD cubic compound

100 200 300 400 500 600 700 800 900

1000

5 10 25 50 100 250 500

Ave

rage

Thr

ough

put (

Mbp

s)

Buffer Size (Packets)

Agile_SD cubic compound

100 200 300 400 500 600 700 800 900

1000

5 10 25 50 100 250 500

Ave

rage

Thr

ough

put (

Mbp

s)

Buffer Size (Packets)

Agile_SD cubic compound

100 200 300 400 500 600 700 800 900

1000

5 10 25 50 100 250 500

Ave

rage

Thr

ough

put (

Mbp

s)

Buffer Size (Packets)

Agile_SD cubic compound

100 200 300 400 500 600 700 800 900

1000

5 10 25 50 100 250 500

Ave

rage

Thr

ough

put (

Mbp

s)

Buffer Size (Packets)

Agile_SD cubic compound

100 200 300 400 500 600 700 800 900

1000

5 10 25 50 100 250 500

Ave

rage

Thr

ough

put (

Mbp

s)

Buffer Size (Packets)

Agile_SD cubic compound

100 200 300 400 500 600 700 800 900

1000

5 10 25 50 100 250 500

Ave

rage

Thr

ough

put (

Mbp

s)

Buffer Size (Packets)

Agile_SD cubic compound

Fig. 11. The average throughput vs. buffer size. (a) The first scenario: Zero PER, (b) the first scenario: 10�5 PER, (c) the first scenario: 10�4 PER, (d) the second scenario: ZeroPER, (e) the second scenario: 10�5 PER, (f) the second scenario: 10�4 PER, (g) the third scenario: Zero PER, (h) the third scenario: 10�5 PER, (i) the third scenario: 10�4 PER.

1

2

3

5 10 25 50 100 250 500

Loss

Rat

io (%

)

Buffer Size (Packets)

Agile_SD cubic compound

Fig. 12. 1st scenario (10�4 PER): loss ratio vs. buffer size.

0.7

0.8

0.9

1

5 10 25 50 100 250 500Intra

-fairn

ess

(Inde

x)

Buffer Size (Packets)

Agile_SD cubic compound

Fig. 13. 2nd scenario (Zero PER): intra-fairness vs. buffer size.

0.7

0.8

0.9

1

5 10 25 50 100 250 500RTT

-fairn

ess

(Inde

x)

Buffer Size (Packets)

Agile_SD cubic compound

Fig. 14. 3rd scenario (Zero PER): RTT-fairness vs. buffer size.

M.A. Alrshah et al. / Journal of Network and Computer Applications 55 (2015) 181–190188

Agile-SD scores the highest index which is almost 0.99 and C-TCPscores around 0.96 while NewReno achieves only 0.79 inter-fairness index. As for the inter-fairness to C-TCP, Cubic scores thehighest index which is around 0.96 while Agile-SD and NewRenoachieve about 0.76 inter-fairness index.

5. Conclusion

In this paper, a new CCA, namely Agile-SD, has been proposedand evaluated. The main contribution of the proposed CCA is toimplement the mechanism of agility factor. The need of theproposed CCA has been arisen by the inability of the existinghigh-speed CCAs in achieving a full bandwidth utilization overhigh-speed networks, especially when a small buffer regime isapplied. Further, a new CCA module has been implemented andplugged into the Linux kernel version 3.19.0. As well as, thismodule has been plugged into the Network Simulator NS-2version 2.35, as a Linux TCP, in order to evaluate it by comparingits performance to the other CCAs.

Subsequently, intensive simulation experiments have beenconducted to evaluate the proposed CCA by comparing its perfor-mance to C-TCP and Cubic, which are the current default TCPalgorithms of MS Windows and Linux, respectively. The resultsshow that the proposed algorithm achieves higher bandwidthutilization than the existing CCAs while maintaining fairness. Dueto the use of agility factor, Agile-SD shows lower sensitivity to thechanges of buffer size and PER.

Importantly, Agile-SD presents higher performance than thecompared CCAs and it provides a significant improvement whichis: up to 55% in the case of single flow, up to 40% in the case ofsequentially established/terminated multi-flows and up to 40% inthe case of synchronously established/terminated multi-flows.

More importantly, the second scenario presents the real case ofnetwork, in which all TCP flows are not established or terminatedsynchronously. In this scenario, Agile-SD has achieved up to 95%bandwidth utilization while the others did not exceed it in thecase of large buffer. As for the case of small buffer, Agile-SDachieves around 92% bandwidth utilization while the other TCPvariants achieve from 32% to 85% bandwidth utilization.

Eventually, Agile-SD is a sender-side TCP module which doesnot change anything at receiver-side. It uses the standard slowstart and provides a new congestion avoidance algorithm featuredby the mechanism of agility factor. Currently, we have alreadyimplemented Agile-SD into the latest Linux kernel 3.19.0 and a real

dumbbell topology has been built using Dummynet over PC-BSDversion 10 to evaluate the proposed CCA based on real test-bed inthe nearest future. Also, there is a strong intention to evaluateAgile-SD with SACK and/or FACK features to show their impacts onthe throughput. As well as, Agile-SD should have the ability toconsider the delayed acknowledgments which needs some mod-ification at the receiver-side.

Acknowledgments

This work has been partially supported by the MalaysianMinistry of Education under the Fundamental Research GrantFRGS/02/01/12/1143/FR for financial support.

References

Acharya S. Study and analysis of TCP/IP congestion control techniques: a review. Ill JEduc Assoc.

Afanasyev A, Tilley N, Reiher P, Kleinrock L. Host-to-host congestion control for TCP.IEEE Commun Surv Tutor 2010;12(3):304–42.

Al-Fares M, Radhakrishnan S, Raghavan B, Huang N, Vahdat A. Hedera: dynamicflow scheduling for data center networks. In: NSDI, vol. 10; 2010. p. 19.

Alizadeh M, Greenberg A, Maltz DA, Padhye J, Patel P, Prabhakar B, et al. Data centerTCP (DCTCP). In: Proceedings of the ACM SIGCOMM 2010 conference, SIG-COMM '10. New York, NY, USA: ACM; 2010. p. 63–74.

Allcock W, Bresnahan J, Kettimuthu R, Link M, Dumitrescu C, Raicu I, et al. Theglobus striped gridftp framework and server. In: Proceedings of the 2005 ACM/IEEE conference on supercomputing, vol. 1. IEEE Computer Society; 2005. p. 1–11.

Alrshah Mohamed A, Othman Mohamed. Test-bed based comparison of single andparallel TCP and the impact of parallelism on throughput and fairness inheterogenous networks. In: 2009 International conference on computer tech-nology and development, ICCTD '09, vol. 1; November 2009. p. 332–5.

Alrshah Mohamed A, Othman Mohamed. Performance evaluation of parallel TCP,and its impact on bandwidth utilization and fairness in High-BDP networksbased on test-bed. In: 2013 IEEE Malaysia international conference on com-munications (MICC); November 2013. p. 23–8.

Alrshah Mohamed A, Othman Mohamed, Ali Borhanuddin, Hanapi Zurina Mohd.Comparative study of high-speed Linux TCP variants over high-BDP networks. JNetw Comput Appl 2014;43:66–75.

Armbrust M, Fox A, Griffith R, Joseph AD, Katz R, Konwinski A, et al. View of cloudcomputing. Commun. ACM 2010;53(April (4)):50–8.

Baiocchi A, Castellani AP, Vacirca F. YeAH-TCP:Yet another highspeed TCP. In:Proceedings of PFLDnet, Roma, Italy; 2007. p. 37–42.

Brakmo LS, Peterson LL. TCP vegas: end to end congestion avoidance on a globalinternet. IEEE J Sel Areas Commun 1995;13(8):1465–80.

Buyya R, Yeo CS, Venugopal S. Market-oriented cloud computing: vision, hype, andreality for delivering it services as computing utilities. In: 2008 10th IEEEinternational conference on high performance computing and communica-tions; September 2008. p. 5–13.

Callegari C, Giordano S, Pagano M, Pepe T. Behavior analysis of TCP Linux variants.Comput Netw 2012;56(1):462–76.

0

0.2

0.4

0.6

0.8

1

Reno-CTCP Reno-Agile Reno-Cubic Agile-Cubic Cubic-CTCP Agile-CTCP

JFI

Fig. 15. The inter-fairness among the studied CCAs.

M.A. Alrshah et al. / Journal of Network and Computer Applications 55 (2015) 181–190 189

Callegari, Christian and Giordano, Stefano and Pagano, Michele and Pepe, Teresa,2014. A Survey of Congestion Control Mechanisms in Linux TCP. In: Vishnevsky,Vladimir and Kozyrev, Dmitry and Larionov, Andrey (Eds), Distributed Compu-ter and Communication Networks, Communications in Computer and Informa-tion Science, Distributed Computer and Communication Networks, SpringerInternational Publishing Switzerland, vol 279, 28-42. ISBN 978-3-319-05208-3,http://dx.doi.org/10.1007/978-3-319-05209-0_3.

Chu J, Cheng Y, Dukkipati N, Mathis M. Increasing TCP's initial window. RFC 6928,IETF Network Working Group; April 2013.

Crowcroft J, Oechslin P. Differentiated end-to-end internet services using aweighted proportional fair sharing TCP. ACM SIGCOMM Comput CommunRev 1998;28(3):53–69.

Floyd S. HighSpeed TCP for large congestion windows. RFC 3649, IETF NetworkWorking Group; April 2003.

Floyd S, Henderson T. The newreno modification to TCPs fast recovery algorithm.RFC 2582, IETF Network Group; April 1999.

Fu Q, Indulska J. Features of parallel TCP with emphasis on congestion avoidance inheterogeneous networks. In: Wysocki T, Dadej A, Wysocki B. (Eds.), Advancedwired and wireless networks, multimedia systems and applications series, vol.26. Springer, US; 2005. p. 207–30.

Fu Q, Indulska J, Perreau S, Zhang L. Exploring TCP parallelisation for performanceimprovement in heterogeneous networks. Comput Commun 2007;30(17):3321–34.

Ha S, Rhee I. CUBIC: a new tcp-friendly high-speed TCP variant. SIGOPS Oper SystRev 2008;42(5):64–74.

Hanushevsky A, Trunov A, Cottrell L. Peer-to-peer computing for secure highperformance data copying. In: Proceedings of the 2001 international confer-ence on computing in high energy and nuclear physics (CHEP 2001), Beijng, vol.2001; 2001.

Hsieh H-Y, Sivakumar R. pTCP: an end-to-end transport layer protocol for stripedconnections. In: 10th IEEE international conference on network protocolsproceedings, vol. 2002, IEEE; 2002. p. 24–33.

Hwang J, Yoo J, Choi N, IA-TCP: a rate based incast-avoidance algorithm for TCP indata center networks. In: IEEE international conference on communications(ICC); June 2012. p. 1292–6.

Jacobson V, Braden R. TCP extensions for long-delay paths. RFC 1072, IETF NetworkWorking Group; October 1988.

Jain R, Chiu D-M, Hawe WR. A quantitative measure of fairness and discriminationfor resource allocation in shared computer system. Eastern Research Labora-tory, Digital Equipment Corporation; 1984.

Kaneko K, Fujikawa T, Su Z, Katto J. TCP-Fusion : a hybrid congestion controlalgorithm for high-speed networks. In: Proceedings of PFLDnet, ISI, Marina DelRey, California; 2007. p. 31–6.

Kelly T. Scalable TCP: improving performance in highspeed wide area networks.ACM SIGCOMM Comput Commun Rev 2003;33(2):83–91.

King R, Baraniuk R, Riedi R. TCP-Africa: an adaptive and fair rapid increase rule forscalable TCP. In: 2005 Proceedings of 24th annual joint conference of the IEEEcomputer and communications societies, INFOCOM 2005, IEEE; 2005. p. 1–11.

Lar S-u, Liao X. An initiative for a classified bibliography on TCP/IP congestioncontrol. J Netw Comput Appl 2013;36(1):126–33.

Leith D, Shorten R. H-TCP: TCP for high-speed and long distance networks. In:Proceedings of PFLDnet; 2004. p. 95–101.

Liu S, Başar T, Srikant R. TCP-illinois: a loss-and delay-based congestion controlalgorithm for high-speed networks. Perform Eval 2008;65(6):417–40.

Prakash P, Dixit A, Hu YC, Kompella R. The TCP outcast problem: exposingunfairness in data center networks. In: Proceedings of the 9th USENIXconference on networked systems design and implementation, San Jose, CA;2012.

Scharf M. Comparison of end-to-end and network-supported fast startup conges-tion control schemes. Comput Netw 2011;55(8):1921–40.

Sivakumar H, Bailey S, Grossman RL. Psockets: the case for application-levelnetwork striping for data intensive applications using high speed wide areanetworks. In: Proceedings of the 2000 ACM/IEEE conference on supercomput-ing, vol. 2000. IEEE Computer Society; 2000. p. 1–7.

Tahiliani R, Tahiliani M, Sekaran K. TCP variants for data center networks: acomparative study. In: International symposium on cloud and services comput-ing (ISCOS); December 2012. p. 57–62.

Tan K, Song J. Compound TCP: a scalable and TCP-friendly congestion control forhigh-speed networks. In: 4th international workshop on protocols for fast long-distance networks (PFLDNet); 2006. p. 80–3.

Tierney B, Lee J, Chen LT, Herzog H, Hoo G, Jin G, et al. Distributed parallel datastorage systems: a scalable approach to high speed image servers. In:Proceedings of the second ACM international conference on Multimedia, vol.1994 of MULTIMEDIA '94. ACM; 1994. p. 399–405.

Vamanan B, Hasan J, Vijaykumar T. Deadline-aware datacenter TCP (D2TCP). In:Proceedings of the ACM SIGCOMM 2012 conference on applications, technol-ogies, architectures, and protocols for computer communication. SIGCOMM '12.ACM, New York, NY, USA, 2012. p. 115–26.

Vasudevan V, Phanishayee A, Shah H, Krevat E, Andersen DG, Ganger GR, et al. Safeand effective fine-grained TCP retransmissions for datacenter communication.SIGCOMM Comput Commun Rev 2009;39(August (4)):303–14.

Wang G, Wu Y, Dou K, Ren Y, Li J. AppTCP: the design and evaluation of application-based TCP for e-vlbi in fast long distance networks. Future Gen Comput Syst2014;39:67–74.

Wu X, Yang X. Dard: distributed adaptive routing for datacenter networks. In: 2012IEEE 32nd international conference on distributed computing systems (ICDCS);June 2012. p. 32–41.

Wu H, Feng Z, Guo C, Zhang Y. ICTCP: incast congestion control for TCP in data-center networks. IEEE/ACM Trans Netw 2013;21(April (2)):345–58.

Xu L, Harfoush K, Rhee I. Binary increase congestion control (bic) for fast long-distance networks. In: 2004 Twenty-third annual joint conference of the IEEEcomputer and communications societies, INFOCOM, vol. 4; 2004. p. 2514–24.

Xu W, Zhou Z, Pham D, Ji C, Yang M, Liu Q. Hybrid congestion control for high-speednetworks. J Netw Comput Appl 2011;34(4):1416–28.

Yoo SJB, Yin Y, Wen K. Intra and inter datacenter networking: the role of opticalpacket switching and flexible bandwidth optical networking. In: 2012 16thinternational conference on optical network design and modeling; April 2012.p. 1–6.

M.A. Alrshah et al. / Journal of Network and Computer Applications 55 (2015) 181–190190