Elastic-TCP: Flexible Congestion Control Algorithm to Adapt for High-BDP Networks
aa r X i v : . [ c s . N I] A p r IEEE SYSTEMS JOURNAL, 2019 1
Elastic-TCP: Flexible Congestion ControlAlgorithm to Adapt for High-BDP Networks.
Mohamed A. Alrshah , ∗ (Senior Member, IEEE), Mohamed A. Al-Moqri ,Mohamed Othman , (Senior Member, IEEE) Abstract —In the last decade, the demand for Internetapplications has been increased, which increases the numberof data centers across the world. These data centers areusually connected to each other using long-distance andhigh-speed networks. As known, the Transmission ControlProtocol (TCP) is the predominant protocol used to provide suchconnectivity among these data centers. Unfortunately, the hugeBandwidth-Delay Product (BDP) of these networks hinders TCPfrom achieving full bandwidth utilization. In order to increaseTCP flexibility to adapt for high-BDP networks, we proposea new delay-based and RTT-independent Congestion ControlAlgorithm (CCA), namely Elastic-TCP. It mainly contributes thenovel Window-correlated Weighting Function (WWF) to increaseTCP bandwidth utilization over high-BDP networks. Extensivesimulation and testbed experiments have been carried out toevaluate the proposed Elastic-TCP by comparing its performanceto the commonly used TCPs developed by Microsoft, Linux,and Google. The results show that the proposed Elastic-TCPachieves higher average throughput than the other TCPs, whileit maintains the sharing fairness and the loss ratio. Moreover, it isworth noting that the new Elastic-TCP presents lower sensitivityto the variation of buffer size and packet error rate than theother TCPs, which grants high efficiency and stability.
Index Terms —Elastic TCP, Delay-based, Congestion Control,High-speed TCP, High-BDP Networks, Long-distance Networks.
I. I
NTRODUCTION
Recently, the demand for Internet applications has beenincreased, which increases the number of data centers acrossthe world. In order to improve the connectivity betweenthese data centers, high-speed and long-distance networks arewidely used across many countries and continents. As known,Transmission Control Protocol (TCP) is the main protocol usedto provide an efficient connectivity among these data centers.Unfortunately, the huge Bandwidth-Delay Product (BDP) ofthese high-speed and long-distance networks hampers TCPfrom fully utilizing bandwidth, which is considered as a wasteof very expensive and important network resources [1]–[8].Indeed, high-BDP networks are not a typical environmentfor which most TCP Congestion Control Algorithms (CCAs)are designed. Specifically, this environment causes two majorunavoidable problems that negatively affect the generalperformance of TCP. The first problem is the long Round Trip Department of Communication Technologies & Networks, UniversitiPutra Malaysia (UPM), 43400, Serdang, Malaysia. Al Asmarya Islamic University, Zliten, Libya Azal University for Human Development, 60th Street, Sana’a, Yemen. Researcher at INSPEM Computational and Mathematical Lab, UPM. ∗ Corresponding authors: Mohamed Alrshah, [email protected]
Time (RTT) caused by long-distances of network links and byapplying big buffer regimes. The second problem is the needfor expanding the congestion window ( cwnd ) to a big numberof packets in order to utilize the available bandwidth due tothe high-BDP of these networks. In the congestion avoidancestage, TCP requires around an RTT to increase its cwnd byone and because the RTT in such networks is long, thus, theincrease of cwnd becomes severely slow [3], [9]–[11].As a result of the aforementioned two problems, TCP spendsa long period of time to grasp the maximum capacity ofhigh-BDP links, which under-utilizes the network bandwidth.Moreover, after reaching the maximum bandwidth limit,congestion losses (periodically happen) cause an acute cwnd degradation. In turn, TCP requires additional time to reachthe maximum cwnd again, which increases its sensitivity topacket loss. In the recent years, many TCP CCAs have beensuggested to solve the aforementioned problems. Althoughthese TCP CCAs have made many improvements, they arestill incapable to efficiently utilize the available bandwidthsof such high-BDP links and even they present a very highsensitivity to packet loss [1]–[9], [12], [13].This paper proposes a new delay-based andRTT-independent TCP CCA, namely Elastic-TCP, whichmainly contributes the novel Window-correlated WeightingFunction (WWF) in order to augment the bandwidthutilization over high-BDP networks. The WWF improvesthe ability of Elastic-TCP to deal with big buffers, longdelays and high-BDP networks. Extensive simulation andtestbed experiments have been carried out to evaluate theproposed Elastic-TCP compared to C-TCP, Cubic, Agile-SD,and TCP-BBR.The remainder of this article is coordinated as follows: therelated works are presented in Section II while the proposedElastic-TCP is exhibited in Section III. Sections IV and Vshow the performance evaluation based on simulation andtestbed, respectively. Finally, Section VI presents the summaryand discussion of results, and Section VII concludes the workand points out the future directions.II. R
ELATED W ORKS
In the recent years, many CCAs have been developed tosolve network congestion problems and also to enhance theoverall performance of TCP, especially in high-BDP networks.Table I shows the historical development of TCP CCAsdesigned for high-speed networks.In high-BDP networks, loss-based CCAs are very sensitiveto packet loss, and delay-based CCAs are highly sensitive
EEE SYSTEMS JOURNAL, 2019 2
TABLE ITCP
VARIANTS DESIGNED FOR
H-BDP
NETWORKS AND THEIRIMPLEMENTATIONS IN POPULAR OPERATING SYSTEMS [1], [9].
Date TCP CCA Based on Windows Linux Solaris1999 NewReno [14] Reno *NI > > > > > > > > > > > ≥ ≥ to RTT changes, while RTT-dependent CCAs are sufferingfrom severe throughput degradation and low fairness [1], [9],[29]. RTT-dependent CCAs increase their cwnd , at congestionavoidance stage, by one every RTT. Thus, if the RTT is smallthe increase will be fairly fast otherwise it will be unacceptablyslow. In fact, RTT-dependency causes unfair share amongcompeting flows that have different RTT lengths, in whichthe shorter the RTT the higher the aggressiveness and viceversa. RTT-dependency also increases the sensitivity to packetloss and negatively influences the overall performance ofTCP [1], [4], [9], [29]. For these reasons, RTT-independentCCAs are highly recommended for high-BDP networks.RTT-independency allows TCP to increase its cwnd based onthe changes of underlaying network instead of RTT magnitude,which significantly improves throughput.In 2006, C-TCP [24] proposed a new hybrid CCA, whichimproved the performance of TCP to some extent. However,it inherits the RTT estimation problem from TCP Vegas[30], which increases its sensitivity to RTT changes andnegatively affects the fairness. Moreover, C-TCP is also anRTT-dependent CCA, which makes the growth of its cwnd very slow, notably over high-BDP networks. Despite all,C-TCP has been set as the default TCP for MS Windowssince its first implementation in Windows Vista, which makesit one of the most widely used TCP in the world [1], [9].In 2008, Cubic [28] became the default TCP of the afterwardversions of Linux kernel. It improved the scalability overhigh-BDP networks by increasing its cwnd in the congestionavoidance stage using cubic root of the elapsed time since lastloss. However, it becomes a time-consuming protocol since itis an RTT-dependent TCP, which results in an underutilizationof bandwidth over high-BDP networks [1], [9], [29].In 2017, Agile-SD [10] was proposed to reduce thesensitivity to packet loss and to grant the ability to dealwith small buffers over high-speed networks. Agile-SD wasdesigned for short-distance networks, where the delay-basedapproach is not functioning due to the triviality of RTTvariation in such networks. Despite that Agile-SD significantlyimproved the performance over short-distance networks, it stillhas a limited performance over high-BDP networks.In 2018, TCP-BBR [7] was proposed by a research group at Google as a model-based CCA. It estimates thebottleneck, bandwidth, and RTT in order to improve the linkutilization while keeping the bottleneck queue un-congested.Despite the implementation of TCP-BBR in Google andYouTube Infrastructure, it is still suffering from maintainingun-congested queue at the expense of bandwidth utilization.Specifically, if a TCP-BBR flow concurrently shares abottleneck with another Cubic flow, the latter will aggressivelyfill up the queue while the former will trigger its drainingfunction to empty that queue. Consequently, TCP-BBR flowswill get smaller share compared to Cubic flows. On the otherhand, TCP-BBR will not properly function for short-termflows, such as request/response flows, since TCP-BBR needsmany cycles to estimate its parameters. Moreover, TCP-BBRpresents a very high level of code complexity compared toother algorithms, as shown in Table II. TABLE IIN
UMBER OF CODE LINES FOR THE STUDIED ALGORITHMS IN TERMS .CCA TCP-BBR Cubic C-TCP Elastic-TCP Agile-SDCode lines 553 342 219 149 115
At the congestion avoidance stage, most TCP CCAsincrease their cwnd by Inc , which varies from CCA to another.This
Inc is calculated based on different parameters, such aspredefined constants and time, depends on the applied CCA.If the cwnd is small (short-distance), the increase will bereasonably fast and even aggressive sometimes. However, ifthe cwnd is large (long-distance), the increase will be severelyslow. The main cause of this problem is that TCP does notcorrelate the value of
Inc to the magnitude of the cwnd itself.For example, Reno and NewReno calculate their
Inc as αcwnd , where α is a predefined constant usually equal to 1.In C-TCP, Inc is calculated as the sum of cwnd reno and cwnd fast , where cwnd reno is the Reno increase as calculatedabove and cwnd fast is the HS-TCP increase, which iscalculated as cwnd fast − ( ζ. ∆) , where ∆ is the Vegas-estimateand ζ is a predefined constant. As for Agile-SD, Inc iscalculated as λcwnd , where λ is dynamically calculated basedon the change in cwnd and always λ ≥ . As for Cubic, Inc iscalculated as C (∆ − q β ∗ cwndC ) , where C is a preset constantand β is the multiplicative decrease factor while ∆ indicatesthe elapsed time since last loss.Based on the aforementioned Inc calculations, it canbe clearly observed that
Inc (in Reno, NewReno, C-TCPand Agile-SD) is reversely proportional to cwnd with nocorrelation to the magnitude of that cwnd . As for Cubic, the
Inc is directly proportional to the cwnd , but the greater themagnitude of cwnd the smaller the value of
Inc . Thus, inhigh-BDP networks, where the magnitude of cwnd is verylarge, the growth of cwnd in all studied CCAs is severelyslow. In all studied TCPs, the
Inc calculations are directlycorrelated to the predefined constants, which hampers theability of these TCPs to adapt to both small and large cwnd scenarios simultaneously. Consequently, TCP setting whichcan be appropriate for short-distance networks, is usuallyimproper for high-BDP networks and vice versa.For better understanding, let us consider an exampleof NewReno over a low-BDP network link with Gbps
EEE SYSTEMS JOURNAL, 2019 3 bandwidth, ms RTT, and Kbyte packet size. The BDPof this link is approximately 125 packets based on Equation(1) [28] below:
BDP(packets) = Bandwidth(bps) × RTT(seconds)Packet Size(bits) (1)Mostly, TCP degrades its cwnd to the half of link BDP( ≈
62 packets) after congestion occurrence. Then, it startsanother epoch using the additive increase (one packet per RTT)to attain the maximum cwnd again. Consequently, it consumes62 RTTs per epoch, which is about 62 milliseconds in thisexample, to reach the maximum link BDP. Thus, this behaviorgives an acceptable throughput and, in turn, achieves a fairlevel of bandwidth utilization.However, if the RTT in the aforementioned example isprolonged to be ms in order to emulate high-BDP linkscenarios, the link BDP will become about 12,500 packetsbased on Equation (1). As above-mentioned, TCP decreasesits cwnd to the half of link BDP ( ≈ ≈
625 seconds) per epoch to attain the maximum cwnd .Thus, this very sluggish behavior degrades the performanceand harshly under-utilizes the link bandwidth. Furthermore,when the network bandwidth is increased to , Gbps ormore, such problem will become significantly more severe.In this work, we propose the Elastic-TCP to enhancethe bandwidth utilization over high-BDP networks, in whichRTTs are very long, buffers are very large and packet lossare very common. Elastic-TCP is a new delay-based andRTT-independent CCA contributing a novel WWF functionthat correlates the value of cwnd increase to the cwnd magnitude. Besides, the gained increase is balanced using theweighting function according to the variation of RTT in orderto maintain the fairness. Consequently, this behavior improvesthe ability of TCP to adapt to different networks with variable cwnd magnitudes, which especially improves the bandwidthutilization over high-BDP networks.III. E
LASTIC -TCP: T HE P ROPOSED A LGORITHM
Elastic-TCP is a delay-based and RTT-independent CCAdesigned for high-BDP networks to improve the bandwidthutilization without jeopardizing the fairness. For moredetails, Figure 1 shows the control flow diagram of theproposed Elastic-TCP and Algorithm 1 describes the internalfunctionality of it while the following subsections provide adeep explanation of its unique mechanism.
Fig. 1. The control flow diagram of Elastic-TCP
Algorithm 1:
The pseudocode of Elastic-TCP. Initialization: RT T max ← , RT T current ← , RT T base ← , cwnd ← Event
On ACK Receiption do if Not duplicated ACK then if Slow Start then cwnd ← cwnd + 1 else RT T current ← ( now − sendtime ) if RT T current < RT T base then RT T base ← RT T current end if RT T current > RT T max then RT T max ← RT T current end W W F ← q RTT max
RTT current × cwnd cwnd ← cwnd + WWFcwnd end else Apply the multiplicative decrease. end end A. Window-correlated Weighting Function (WWF)
WWF is the primary contribution of this work. Substantially,WWF aims at improving TCP bandwidth utilization overhigh-BDP networks without jeopardizing the fairness.Elastic-TCP relies on the variation of RTT to measure theutilization ratio (
U R ), which is calculated and used in adifferent way other than those ways presented by TCP-Dual,Vegas, and Fast-TCP.As known, the variation of RTT can be used to quantify thelevel of congestion and/or the level of link utilization at thebottleneck [1], [17], [30], [31]. In this work, we defined theutilization ratio (
U R ) as a percentage of the utilized buffer andBDP, as shown in Figure 2. Thus, the proposed Elastic-TCPquantifies the
U R at the bottleneck link as in Equation (2)below:
U R = RT T current
RT T max , (2)where RT T current is the current RTT obtained from thelast ACK,
RT T base and
RT T max are the minimum andmaximum RTT seen over this connection, respectively, where(
RT T base ≤ RT T current ≤ RT T max ), (
RT T base > ),( RT T max > RT T base ) and (
U R ∈ [0 , ). Fig. 2. The impact of RTT on UR.
Hence, the underutilization ratio (
U R ), which reflects theunder-utilized portion of BDP plus the empty buffer size, can
EEE SYSTEMS JOURNAL, 2019 4 be quantified using Equation (3):
U R = RT T max − RT T current
RT T max = 1 − U R, (3)where
U R = 1 only when the bandwidth and buffer at thebottleneck link are fully utilized because the
RT T current approaches the maximum delay (
RT T max ) only when thebottleneck link capacity and buffer are about to be full,which results in (
U R = 0 ), as shown in Figure 2. Then,the
U R is used to calculate the weighting function ( ∆ ), as ∆ = UR , where ∆ = 1 only when U R = 1 , and ∆ > otherwise. Hence, the under-utilized portion of bandwidth atthe bottleneck ( ¯∆) , as shown in Figure 3, can be calculatedas ¯∆ = ∆ − . Fig. 3. The impact of RTT on ∆ . It is very clear that ∆ is inversely proportional to RT T current , which exhibits a semi-hyperbolic curve, as shownin Figure 3. In other words, ∆ is enlarged, up to the maximumpossible value ( ∆ max ), when the RT T current moves towardsthe
RT T base , which indicates to light traffic loaded network,as shown in Equation (4) below: ∆ max = lim RT T current → RT T base
RT T max
RT T current = RT T max
RT T base (4)Contrarily, ∆ is shrunk, up to the minimum possible value( ∆ min ), if the RT T current moves towards the
RT T max ,which indicates to heavy traffic loaded network, as shown inEquation (5) below: ∆ min = lim RT T current → RT T max
RT T max
RT T current = 1 (5)The main purpose of ∆ is to estimate the maximumpossible cwnd ( cwnd est ) for the underlying network, whichis calculated as cwnd est = ∆ × cwnd. Since ∆ = 1 + ¯∆ , thus cwnd est = cwnd + ( ¯∆ × cwnd ) , which always guaranteesthat ( cwnd est ≥ cwnd ). In order to increase the adaptabilityof Elastic-TCP to deal with different scenarios of diverse cwnd magnitudes, the value of the increase in cwnd shouldbe correlated to the magnitude of cwnd est .The correlation function should create a convex-up curveto reduce the under-utilized area above the curve, wherethe more the convexity the best the utilization. However,increasing the convexity more than necessary will lead tosevere data loss. Further, the function should grow aggressivelywhen the current cwnd is close to the multiplicative decreasepoint ( β ∗ cwnd max ) and should grow conservatively whenthe current cwnd is approaching the maximum bottleneckcapacity or the maximum cwnd ( cwnd max ) , as shown inFigure 4. Furthermore, the needed function must be a low-complexity function since it will be implemented in thecore space of the Linux kernel, which does not provide anyhigh-level user-defined function. For these reasons, we havebeen searching for a new window growth function that isable to satisfy the above-mentioned constraints. We testedsome functions, where we found that the square-root functionis able to fulfill the requirements. Thus, we implementedNewton-Raphson iteration method to calculate the square rootof cwnd est as W W F = √ cwnd est . Fig. 4. The window growth function of Elastic-TCP using the square root.
Finally, the resulted value of WWF is used, in the stageof congestion avoidance, to increase the cwnd , as shown inEquation (6) below: cwnd = cwnd + W W Fcwnd (6)By this behavior, the novel Elastic-TCP increases its abilityto probe the status of the underlying network, as shown infigures 2 and 3. Also, this behavior results in a convex-upcurve of increase, in the congestion avoidance stage, whichcuts down the epoch time in order to diminish the area ofunder-utilized bandwidth, as shown in Figure 5. Specifically,this behavior makes the fast-recovery stage of the Elastic-TCPmuch faster compared to (1) NewReno, as in Figure 5(a),(2) Cubic, as in Figure 5(b), and (3) C-TCP, as in Figure5(c). Besides, this behavior grants low sensitivity to packetlosses. Hence, it is very clear that the Elastic-TCP guaranteeshigher bandwidth utilization and lower sensitivity to packetloss degradation than the existing CCAs while it maintainsthe fairness.
B. The Elastic-TCP Overall Behavior
Elastic-TCP starts exponentially as it uses the standardslow start. Then, after detecting the first loss, either byreceiving 3-duplicate acknowledgments or by an expiration ofthe timeout counter, it reduces its cwnd by the multiplicativedecrease factor ( β ) , then it enters the stage of congestionavoidance. In this stage, the Elastic-TCP increases its cwnd by W W Fcwnd , as shown in Equation (6), to produce short epochswith convex-up curves of increase. If a packet loss occursin this stage, the Elastic-TCP reduces its cwnd using themultiplicative decrease factor ( β ) to start another epoch ofthe same stage.As shown in figures 5(a), 5(b) and 5(c), this behaviorhelps the Elastic-TCP to increase its cwnd faster thanthe examined TCP CCAs, which obviously improves thebandwidth utilization. That is to say, the faster the cwnd growth the higher the bandwidth utilization and vice versa. EEE SYSTEMS JOURNAL, 2019 5 (a) Elastic-TCP vs. NewReno (b) Elastic-TCP vs. Cubic (c) Elastic-TCP vs. C-TCPFig. 5. The epoch time of Elastic-TCP compared to NewReno, Cubic and C-TCP.
However, the most important issue is to which limit cwnd has to be increased in order to prevent the problemof over injecting data into the network. Fortunately, thenew Elastic-TCP has the ability to improve the bandwidthutilization while keeping data loss as low as in NewReno.IV. P
ERFORMANCE E VALUATION OF E LASTIC -TCP
USING S IMULATION
This work aims at developing a new TCP CCA, namelyElastic-TCP, that improves the bandwidth utilization ofhigh-BDP networks, without jeopardizing the fairness amongcompeting TCP flows. For the purpose of performanceevaluation, NS-2 network simulator is used. As well-known,NS-2 provides two ways of TCP implementation, either asa simulation-based module or as a Linux-based module. Inthis work, we implement the Elastic-TCP into NS-2 as aLinux-based module, which is ready for implementation intoLinux kernel.
A. Simulation Setup
In this paper, NS-2.35 has been used to carry out extensivesimulation experiments in order to compare the performanceof Elastic-TCP, C-TCP, Cubic, and Agile-SD. The studiedalgorithms have been examined in three main scenarios:1) Single-flow scenario: this scenario mimics the ideal caseof network, which is used to evaluate the performanceof TCP over an ideal case of non-congested network,in order to show the maximum achievable bandwidthutilization in the best conditions. This scenario has onlyone sender and one receiver, the sender starts sendingFTP data to the destination from the beginning until theend of simulation.2) Sequentially established/terminated multiple-flowsscenario: it is used to evaluate the performance of TCPover congested bottleneck in order to simulate a realnetwork scenario. This scenario shows the impact ofdifferent establishment and termination time of multipleflows on the throughput and on the quality of bandwidthsharing. In this scenario, the flows are established oneby one after every 5 seconds starting from time 0 in amanner of point-to-point flows, for example, S1 to D1at time 0, S2 to D2 at time 5, S3 to D3 at time 10, andso on.3) Synchronously established/terminated multiple-flowsscenario: this scenario shows the impact of synchronized packet loss that occur over all flows on the throughputand on the sharing fairness. In this scenario, all sendersstart sending FTP data to destinations at the same time(when simulation time = 0 sec) and they finish by theend of simulation (when simulation time = 100 sec) ina manner of point-to-point flows, for example, S1 sendsto D1, S2 sends to D2, and so on.In the single flow scenario, the used network topology is asshown in Figure 6(a), while the topology shown in Figure 6(b)is used in multiple-flows scenarios. In the single-bottlenecktopology shown in Figure 6(b), n senders compete to send datato n receivers via a shared bottleneck link, where speed andpropagation delay are set to Gbps and ms , respectively.All end-system nodes are linked to bottleneck routers usingwired links, where speed and propagation delay are set to Gbps and ms , respectively [32].In all scenarios, the performance of the examined TCPCCAs is evaluated with various buffer sizes varying from to packets and Packet Error Rates (PERs) of − , − and zero . The buffer size and PER changes only applied toR1 and R2 in order to mimic real bottleneck behavior. As anendeavor to ensure the accuracy of the results, the simulationexperiments have been repeated for 30 times for each setof parameters, as shown in Table III, then the averages arecalculated for each set of parameters. TABLE IIIS
IMULATION PARAMETERS SETTING .Parameter Value (s)TCP CCAs Cubic, C-TCP, Agile-SD,Elastic-TCPLink Speed of All Links 1GbpsPC-to-Router 2-way Delay 1 millisecondsBottleneck 2-way Delay 100 millisecondsPacket Error Rate (PER) − , − , Buffer Size at Bottleneck Routers 50 to 6400 pcktsData Packet Size 1 KBManagement Droptail algorithmFlow Type FTPSimulation Time 100 secondsSimulation Runs for Each Scenario 30 times
As well-known, the types of TCP traffic such as HTTP andTelnet are considered as short-lived traffic types, which are notsignificantly influenced by TCP improvements. In short-livedtraffic, tasks are usually accomplished before entering thesystem steady state. That is why, only FTP traffic is used in this
EEE SYSTEMS JOURNAL, 2019 6 work because it is a long-lived TCP traffic type that representsa great portion of Internet traffic. (a) Congestion-free network topology.(b) Dumbbell Network topology with congestedbottleneck.Fig. 6. Network topologies used for performance evaluation in this work.
Substantially, the aim of these experiments is two-fold: First,to demonstrate the impact of network congestion, variablebuffer size, and inconstant PER on the overall performanceof examined TCP CCAs. Second, to compare the overallperformance of the proposed Elastic-TCP to Cubic, C-TCPand Agile-SD. In all experiments of this work, the simulationtime has been set to 100 seconds, which is more than enoughfor all CCAs to show their behavior in the steady state.The main goal of this work is to improve the performanceof TCP by reducing its sensitivity to packet loss and byincreasing its scalability to be able to deal with differentnetworks characteristics. In order to evaluate the performanceof TCP at the transport layer, throughput, loss rasio, andsharing fairness index are measured.Throughput is the rate of successful data delivery over anetwork link from sender to receiver. It is usually measured inbits per second (bps) or any unit of its multiples such as Mbpsor Gbps. Throughput can be computed as per flow throughputor as system throughput. Say that one TCP flow transmits anamount of data to the receiver side, which received data ( data ) in bits over a period of time ( time ) in seconds, thus, thethroughput ( T hr ) of this flow is calculated as T hr = datatime . Asfor the system throughput, suppose that we have a number offlows ( n ) that send data simultaneously, the system throughput ( SysT hr ) is calculated as below: SysT hr = P ni =1 data i time , (7)where data i is the data received form the i th flow, and time is the time consumed to receive the data of all flows.As well-known, data packets can be lost during the datatransmission over any type of networks due to many reasonssuch as congestion, fading, interference. In this work, we countall types of data loss together as one type ( loss ), where thisloss is equal to the difference between total data sent ( Sdata )by a TCP sender and total data received (
Rdata ) by therelative TCP receiver. The loss ratio ( LR ) is calculated asa ratio of data loss to the total data sent ( Sdata ) for all flows( n ) as calculated below: LR = P ni =1 SData i − RData i P ni =1 SData i = P ni =1 loss i P ni =1 SData i , (8) where ( Sdata i ) and ( Rdata i ) are the total data sent and thetotal data received for flow ( i ), respectively.The sharing fairness index is calculated to show whetherthe competing TCP flows are getting a fair share of thebottleneck link bandwidth. In this work, three types of sharingfairness, namely intra-fairness, RTT-fairness and inter-fairness,are measured using the well-known Jains fairness index (JFI)[33], as shown in Equation (9) below: JF I ( x , x , ..., x n ) = ( P ni =1 x i ) n · P ni =1 x i , (9)where ( n ) is the number of flows, and ( x i ) denotes the averagethroughput of the i th flow. Intra-fairness is to measure how fairis the distribution of bottleneck bandwidth among the flows ofthe same TCP variant, and RTT-fairness is to measure how fairis the distribution of queuing delay among the competing flowsoriginated from the same TCP variant. As for Inter-fairness,it is to measure how fair is the distribution of bottleneckbandwidth among the flows of different TCP variants. B. Simulation Results and Discussion
This subsection analytically discusses the behavior shownby Elastic-TCP compared to the other CCAs. Moreover, itpresents the performance results in terms of throughput, lossratio, and fairness in order to exhibit the effect of error rateand buffer size on the overall performance.
1) The cwnd evolution:
The evolution of cwnd is thespirit of all CCAs, as it directly influences other performancemetrics such as throughput, bandwidth utilization, loss ratio,and sharing fairness. Due to its unique behavior, Elastic-TCPexpectedly presents faster cwnd growth compared to Cubic,C-TCP, and Agile-SD, as shown in Figure 7. This fast cwnd growth allows Elastic-TCP to be an RTT-independent, whichin turn shrinks its epoch time, where the faster the growth of cwnd the shorter the epoch and vice versa. Indeed, shorteningthe epoch itself is not an aim, but it is only a way to increasethe bandwidth utilization. By this approach, Elastic-TCP doesnot only increase the average throughput but also minimizesthe loss ratio while maintaining the sharing fairness. c w nd ( pa ck e t s ) Simulation Time flow-1 (a) Elastic-TCP c w nd ( pa ck e t s ) Simulation Time flow-1 (b) Cubic c w nd ( pa ck e t s ) Simulation Time flow-1 (c) C-TCP c w nd ( pa ck e t s ) Simulation Time flow-1 (d) Agile-SDFig. 7. TCP congestion window evolution over single-flow scenario (bufferSize = 6400 packets, packet size = 1kbyte, loss rate = zero).
EEE SYSTEMS JOURNAL, 2019 7
On one hand, Figure 7 shows the cwnd evolution ofthe studied CCAs in the scenario of single-flow, where thefaster increase is presented by the Elastic-TCP followed byCubic, C-TCP, and Agile-SD. Clearly, the Elastic-TCP reachesroughly 31,000 packets in about 10 seconds, then it beginsfluctuating to draw convex-up curves in very short epochs, asshown in Figure 7(a). With regard to Cubic, it reaches about30,000 packets in 40 seconds, thereafter, it starts fluctuatingto exhibit very long epochs due to its cubic function of theincrease, as shown in Figure 7(b). While C-TCP does notexceed 25,000 packets, Agile-SD fixes its cwnd to around26,000 packets. Hence, it can be concluded that only theElastic-TCP and Cubic have the ability to fully utilize thebandwidth in the ideal network, where the former is still betterthan the later by a difference of 1,000 packets (about 1Mbyteper RTT).On the other hand, Figure 8 presents the cwnd evolution of the studied CCAs in the scenario ofmulti-flows, with sequential flows establishments, to showthe intra-fairness among these competing flows. Since thehigher the convergence among concurrent flows the higherthe intra-fairness, thus, the Elastic-TCP shows the highestintra-fairness level followed by C-TCP, Cubic and Agile-SD,and also Elastic-TCP shows higher utilization. c w nd ( pa ck e t s ) Simulation Timeflow-1flow-2 flow-3flow-4 (a) Elastic-TCP c w nd ( pa ck e t s ) Simulation Timeflow-1flow-2 flow-3flow-4 (b) Cubic c w nd ( pa ck e t s ) Simulation Timeflow-1flow-2 flow-3flow-4 (c) C-TCP c w nd ( pa ck e t s ) Simulation Timeflow-1flow-2 flow-3flow-4 (d) Agile-SDFig. 8. TCP congestion window convergence in multi-flows scenario (bufferSize = 3200 packets, packet size = 1kbyte).
More specifically, Elastic-TCP flows start converging witheach other in around 35 seconds and they finish with avery high level of intra-fairness, while C-TCP flows starttheir convergence in about 40 seconds, but they finish withslightly lower intra-fairness than the former. As for Cubic,the flows start converging very slowly in 50 seconds and theygive a moderate level of intra-fairness. Regarding Agile-SD,it exhibits a low level of fairness and very low bandwidthutilization with cwnd not more than 900 packets, while the cwnd of the other CCAs varies from 4,000 to 9,000 packets.Figure 9 shows a comparison between the studied CCAsin terms of cwnd evolution. It shows the average cwnd offour concurrent flows for each CCA in the case of zero PERand − PER. From Figure 9(a), it is clear that Elastic-TCPreaches the maximum cwnd earlier than C-TCP and Cubic,while Agile-SD is not able to reach reasonable cwnd value since it is not designed for high-BDP networks. Moreover,C-TCP and Cubic show lower cwnd than Elastic-TCP evenafter they reach their steady states. In Figure 9(b), Cubic andC-TCP show high sensitivity to packet loss and both degradetheir cwnd to less than 50%, while Elastic-TCP shows verylow sensitivity to packet loss which allows it to maintain ahigh level of performance. A gg r ega t ed c w nd ( pa ck e t s ) Simulation TimeElastic-TCPCubicC-TCPAgile-SD (a) Loss rate = 0 A gg r ega t ed c w nd ( pa ck e t s ) Simulation TimeElastic-TCPCubicC-TCPAgile-SD (b) loss rate = − Fig. 9. TCP aggregated cwnd in multi-flows scenario (buffer Size = 3200packets, packet size = 1kbyte).
2) The average throughput:
The single-flow scenario showsan ideal congestion-free network to study the capabilityof TCP CCAs on fully utilizing the available bandwidth.The proposed CCA shows slight enhancement on averagethroughput compared to other CCAs due to the fast increaseof its cwnd resulted by its unique mechanism of WWF, asshown in Figure 10(a). Moreover, the Elastic-TCP shows moresustainability in presence of PER compared to other CCAs, asshown in figures 10(b) and 10(c), where Cubic, C-TCP, andAgile-SD are highly influenced by the PER. In general, theElastic-TCP outperforms other CCAs in terms of throughputin most cases even in harsh network environments where PERis high. This clearly enhances the bandwidth utilization by upto 22% in some scenarios.
100 200 300 400 500 600 700 800 900 1000 50 100 200 400 800 1600 3200 6400 A v e r age T h r oughpu t ( M bp s ) Buffer Size (Packets)Cubic C-TCPAgile-SD Elastic-TCP (a) zero
PER.
100 200 300 400 500 600 700 800 900 1000 50 100 200 400 800 1600 3200 6400 A v e r age T h r oughpu t ( M bp s ) Buffer Size (Packets)Cubic C-TCPAgile-SD Elastic-TCP (b) − PER.
100 200 300 400 500 600 700 800 900 1000 50 100 200 400 800 1600 3200 6400 A v e r age T h r oughpu t ( M bp s ) Buffer Size (Packets)Cubic C-TCPAgile-SD Elastic-TCP (c) − PER.Fig. 10. The single flow scenario: the average throughput against buffer size.
In the second scenario, figures 11(a), 11(b) and 11(c) showthat the Elastic-TCP achieves better throughput compared toother CCAs, even with small buffer size and high PER, whichenhances the bandwidth utilization up to 40%.In the synchronous multiple-flows scenario, the Elastic-TCPalso outperforms the other CCAs in most cases, especially
EEE SYSTEMS JOURNAL, 2019 8
100 200 300 400 500 600 700 800 900 1000 50 100 200 400 800 1600 3200 6400 A v e r age T h r oughpu t ( M bp s ) Buffer Size (Packets)Cubic C-TCPAgile-SD Elastic-TCP (a) zero
PER.
100 200 300 400 500 600 700 800 900 1000 50 100 200 400 800 1600 3200 6400 A v e r age T h r oughpu t ( M bp s ) Buffer Size (Packets)Cubic C-TCPAgile-SD Elastic-TCP (b) − PER.
100 200 300 400 500 600 700 800 900 1000 50 100 200 400 800 1600 3200 6400 A v e r age T h r oughpu t ( M bp s ) Buffer Size (Packets)Cubic C-TCPAgile-SD Elastic-TCP (c) − PER.Fig. 11. Sequential multiple-flows scenario: average throughput vs. buffersize. with high PER and it significantly achieves up to 50% ofimprovement in some cases, as shown in figures 12(a), 12(b)and 12(c).
100 200 300 400 500 600 700 800 900 1000 50 100 200 400 800 1600 3200 6400 A v e r age T h r oughpu t ( M bp s ) Buffer Size (Packets)Cubic C-TCPAgile-SD Elastic-TCP (a) zero
PER.
100 200 300 400 500 600 700 800 900 1000 50 100 200 400 800 1600 3200 6400 A v e r age T h r oughpu t ( M bp s ) Buffer Size (Packets)Cubic C-TCPAgile-SD Elastic-TCP (b) − PER.
100 200 300 400 500 600 700 800 900 1000 50 100 200 400 800 1600 3200 6400 A v e r age T h r oughpu t ( M bp s ) Buffer Size (Packets)Cubic C-TCPAgile-SD Elastic-TCP (c) − PER.Fig. 12. Synchronous multiple-flows scenario: average throughput vs. buffersize.
3) The loss ratio:
Fundamentally, TCP aims at maximizingthe throughput while minimizing the loss ratio. Thus, in allscenarios, the new Elastic-TCP along with the studied CCAsproduce very trivial loss ratios, which is not more than 0.5%,as shown in Table IV, where the rest of results have no muchdifference.
4) The fairness:
Simulation results show that all examinedCCAs attain similar intra-fairness and RTT-fairness. However,thanks to the weighting function that enabled the Elastic-TCPto achieve slightly higher fairness index than other CCAs,especially in high PER and small buffer cases. Due to thetrivial difference in fairness results among examined CCAs,figures 13(a) and 13(b) were chosen to show samples ofintra-fairness and RTT-fairness, respectively.
TABLE IVL
OSS RATIO VS . BUFFER SIZE : SYNCHRONOUS MULTI - FLOWS SCENARIO , zero PER.Buffer Loss ratioCubic C-TCP Agile-SD Elastic-TCP50 0.006840 0.036343 0.058301 0.009872100 0.004418 0.031290 0.060696 0.003612200 0.006269 0.017994 0.062253 0.024834400 0.010915 0.024560 0.063563 0.028342800 0.018782 0.012103 0.065065 0.0351661600 0.030127 0.022083 0.065139 0.0455173200 0.044965 0.040465 0.065239 0.0637636400 0.071371 0.075520 0.070707 0.094607 I n t r a - f a i r ne ss ( I nde x ) Buffer Size (Packets)Cubic C-TCPAgile-SD Elastic-TCP (a) Intra-fairness index againstbuffer size: synchronous multi-flowsscenario, − PER. R TT - f a i r ne ss ( I nde x ) Buffer Size (Packets)Cubic C-TCPAgile-SD Elastic-TCP (b) RTT-fairness index againstbuffer size: synchronous multi-flowsscenario, − PER. I n t e r- f a i r ne ss ( I nde x ) JFI (c) Inter-fairness among the studiedCCAs.Fig. 13. The fairness measurements.
Moreover, the inter-fairness of the examined CCAs againststandard NewReno is measured in an individual experimentusing the topology shown in Figure 6(b), where the resultof this metric is shown in Figure 13(c). For inter-fairness toNewReno, the Elastic-TCP achieves the highest score, which isaround 91%, while Cubic-TCP and C-TCP achieve about 85%inter-fairness measurement. With regard to inter-fairness toCubic-TCP, the Elastic-TCP and NewReno achieve the highestindex which is about 84% while C-TCP achieves only 78%.For inter-fairness to C-TCP, both Elastic-TCP and NewRenoattain about 85% while Cubic-TCP attains only 78%. In fact,the Elastic-TCP achieves a high level of inter-fairness to otherstandard CCAs due to its unique functionality of WWF.V. P
ERFORMANCE E VALUATION OF E LASTIC -TCP
USING T ESTBED
The proposed Elastic-TCP is compiled into the Linuxkernel, version 4.9 using openSUSE Leap 42.2, to carry outthe testbed experiment, in order to show the performance ofElastic-TCP in the real environment. Since Elastic-TCP isdesigned for long-distance networks, we used the Linux-basedNetEm to emulate the delay and to control the buffer size.
A. Testbed Setup
A testbed of single dumbbell topology is built in ourlaboratory using real PCs connected to each other through1Gbps wired links, as shown in Figure 14. In order to build thisnetwork topology, we installed Linux openSUSE 42.2 Leapover all servers and clients. Thereafter, we implemented our
EEE SYSTEMS JOURNAL, 2019 9
Elastic-TCP module into the Linux kernel over all servers andclients. In order to evaluate the tested CCAs, we transfer largefiles from the clients to the servers simultaneously, while thenetwork traffic is monitored using TCPdump. As for NetEm, itis configured at all end-systems to provide 100ms round-triptime for all links. The experiment is repeated 30 times forevery buffer size scenario, where the buffer size is varied from50 to 12,500 packets. For the average throughput, the StandardDeviation (SD) with 95% Confident Interval (CI) and StandardError have been calculated for every 30 runs for every set ofparameter setup.
Fig. 14. NetEm-based Testbed Topology.
Moreover, the studied CCAs are evaluated over twoscenarios, single-flow and multiple-flows scenario. In order tomake our performance evaluation up to date, we included theTCP-BBR to our comparison. TCP-BBR is recently developedby Google and currently becomes the most promisingcandidate to replace current congestion control protocols inthe upcoming 4.9 Linux kernel. Table V shows the testbedparameters’ setup and configuration.
TABLE VT
ESTBED PARAMETERS SETUP AND CONFIGURATION .Parameter Value (s)TCP CCAs Cubic, C-TCP, TCP-BBR, Elastic-TCPLink capacity 1Gbps for all linksTwo-way delay 100ms for all linksBuffer size from 50 to 12500 packetsPacket size 1500 bytesQueuing Algo Drop TailTraffic type FTPTransfered file size 5.1GBRuns for EachScenario 30 times
B. Testbed Results and Discussion
This subsection analytically discusses the testbed resultsand shows the average throughput, loss ratio, and fairnessmeasurements in order to show the impact of long-delay andbuffer size on the overall performance.
1) The average throughput:
As shown in Figure 15(a),Elastic-TCP achieves higher average throughput compared toother TCP CCAs as a result of its fast cwnd growth resultedby its unique WWF mechanism. The Elastic-TCP performsbetter than the compared CCAs in most cases, particularlywhen the applied buffer size is small. In single-flow scenario,the Elastic-TCP improves the average throughput by up to 14%over TCP-BBR, up to 13% over Cubic and up to 154% overC-TCP. In multiple-flows scenario, Figure 16(a) shows thatthe Elastic-TCP outperforms the compared CCAs, in terms of average throughput, in many cases, especially when theapplied buffer size is small. Briefly, it enhances the averagethroughput by up to 23% over TCP-BBR, up to 14% overCubic and up to 81% over C-TCP.
2) The loss ratio:
In the single-flow scenario, Elastic-TCPand TCP-BBR lose about 1 packet from every 10,000 packets(0.01%), Cubic loses about 10 packet from every 10,000packets (0.1%), and C-TCP loses about 30 packets fromevery 10,000 packets (0.3%), as shown in Figure 15(b). Inthe multiple-flows scenario, in the cases of small buffers,Elastic-TCP and Cubic show the lowest loss ratio, whereElastic-TCP loses about 7 packets from every 1000 packets(0.7%) and the Cubic loses about 10 from every 1000 packets(1%) while TCP-BBR and C-TCP losses up to 1.4% and 2.1%,respectively. As for the large buffer scenarios, the loss ratio ofall algorithms is between 0.8% to 1.5%, where the lowest lossratio is provided by Elastic-TCP, as shown in Figure 16(b). (a) Average throughput & SD withCI 95%. (b) Loss ratio.Fig. 15. Single-flow scenario with different buffer sizes.(a) Average throughput & SD withCI 95%.(b) Loss ratio. (c) Intra-fairness.Fig. 16. Multiple-flows scenario: four simultaneous FTP flows.
3) The fairness:
The examined TCP CCAs have achievedsimilar intra-fairness in most cases. In the case of 50 packetsbuffer, C-TCP seems fairer than the compared CCAs followedby TCP-BBR, Elastic-TCP, and Cubic. However, the differencebetween the higher fairness and the lower fairness measurmentranges from 2% to 10%, which is slightly acceptable.VI. S
UMMARY AND DISCUSSION OF RESULTS
The results reveal that Elastic-TCP is able to achieve higherbandwidth utilization compared to other TCP CCAs, while
EEE SYSTEMS JOURNAL, 2019 10 it minimizes the loss ratio and maintains the fairness. Dueto its unique function, the proposed Elastic-TCP shows lesssensitivity to the changes of PER and buffer size. In general,it shows better performance compared to other TCP CCAs,which is considered a significant improvement in terms ofbandwidth utilization.Based on simulation, Elastic-TCP improves: (1) up to 22%in the case of single flow, (2) up to 40% in the case ofsequential multiple flows and (3) up to 50% in the case ofsynchronous multiple flows. In the second scenario, whichrepresents a real network case where the coexisting TCP flowsare not synchronously established or terminated, Elastic-TCPutilizes up to 80% of the available bandwidth while theothers could not exceed 66% in case of large buffer size.Moreover, Elastic-TCP achieves from 47% to 66% bandwidthutilization, in the case of small buffer size, while the bandwidthutilization of the compared TCP CCAs varies from 5% to29%. With regards to the impact of synchronized losses amongthe competing flows, the third scenario is used to show theimpact of these losses on the average throughput. Fortunately,Elastic-TCP improves the throughput up to 50%, especiallywhen the PER is high.Furthermore, a testbed experiment is conducted to comparethe performance of Elastic-TCP to the recent TCP CCAsavailable in the upcoming Linux kernel version 4.9, includingCubic, C-TCP, Agile-SD, and TCP-BBR. Indeed, TCP-BBR,which is recently developed by Google, is the most promisingcandidate to replace the current congestion control algorithmsin the upcoming Linux kernel. However, the results showthat the proposed Elastic-TCP can outperform Cubic, C-TCP,Agile-SD, and even TCP-BBR. Elastic-TCP improves theaverage throughput by up to 23% over TCP-BBR, up to 14%over Cubic and up to 81% over C-TCP.VII. C
ONCLUSION
In this work, a novel RTT-independent and delay-basedTCP CCA, namely Elastic-TCP, is proposed and evaluated.Elastic-TCP mainly contributes a new Window-correlatedWeighting Function (WWF). Basically, the necessity ofElastic-TCP has been arisen by the inability of the existingCCAs in achieving full bandwidth utilization over high-BDPnetworks, especially when the used buffer is small and/orthe packet losses are common. Further, a new Elastic-TCPmodule is designed, developed and attached to the NS-2 as aLinux-TCP module, which is ready for implementation intoLinux kernel. Thereafter, simulation and testbed experimentsare carried out to examine the performance of Elastic-TCPcompared to TCP-BBR, Cubic, C-TCP, and Agile-SD.Elastic-TCP introduces significant improvement in terms ofbandwidth utilization especially over congested networks,where the available buffer at the bottleneck is small and theloss ratio is very high.The utility of Elastic-TCP is maximized if the sender-sideend systems are Linux-based, which is very likely since alarge number of Internet servers are Linux-based. However,since Elastic-TCP is an algorithm, it is not bound to a specificoperating system and it can be implemented in any operatingsystem such as Windows, Macintosh, and Sun Solaris. Finally, the Elastic-TCP should be evaluated over satellitenetworks in order to take into account any potential issues.Also, there is a strong intention to examine the Elastic-TCPover wireless and mobile networks to study the impact of routechanging and hand-off.A
CKNOWLEDGMENT
This work is supported by Universiti Putra Malaysia andAl Asmarya Islamic University - Libya.R
EFERENCES[1] A. Afanasyev, N. Tilley, P. Reiher, and L. Kleinrock, “Host-to-HostCongestion Control for TCP,”
IEEE Communications Surveys andTutorials , vol. 12, no. 3, pp. 304–342, 2010.[2] M. Scharf, “Comparison of end-to-end and network-supported faststartup congestion control schemes,”
Computer Networks , vol. 55, no. 8,pp. 1921–1940, 2011.[3] W. Xu, Z. Zhou, D. Pham, C. Ji, M. Yang, and Q. Liu, “Hybridcongestion control for high-speed networks,”
Journal of Network andComputer Applications , vol. 34, no. 4, pp. 1416–1428, 2011.[4] C. Callegari, S. Giordano, M. Pagano, and T. Pepe, “Behavior analysis ofTCP Linux variants,”
Computer Networks , vol. 56, no. 1, pp. 462–476,2012.[5] ——, “A survey of congestion control mechanisms in linuxtcp,” in
Distributed Computer and Communication Networks , ser.Communications in Computer and Information Science, V. Vishnevsky,D. Kozyrev, and A. Larionov, Eds. Springer International Publishing,2014, vol. 279, pp. 28–42.[6] J. Wang, J. Wen, J. Zhang, Z. Xiong, and Y. Han, “Tcp-fit: An improvedtcp algorithm for heterogeneous networks,”
Journal of Network andComputer Applications , vol. 71, pp. 167–180, 2016.[7] N. Cardwell, Y. Cheng, C. S. Gunn, S. H. Yeganeh et al. , “BBR:congestion-based congestion control,”
Communications of the ACM ,vol. 60, no. 2, pp. 58–66, 2017.[8] I. Rhee, L. Xu, S. Ha, A. Zimmermann, L. Eggert, and R. Scheffenegger,“Cubic for fast long-distance networks,” February 2018, RFC 8312,IETF Network Working Group.[9] M. A. Alrshah, M. Othman, B. Ali, and Z. M. Hanapi, “Comparativestudy of high-speed linux tcp variants over high-BDP networks,”
Journalof Network and Computer Applications , vol. 43, pp. 66–75, 2014.[10] ——, “Modeling the throughput of the linux-based Agile-SDtransmission control protocol,”
IEEE Access , vol. 4, pp. 9724–9732,2017.[11] M. R. Kanagarathinam, S. Singh, I. Sandeep, A. Roy, and N. Saxena,“D-tcp: Dynamic tcp congestion control algorithm for next generationmobile networks,” in
Consumer Communications & NetworkingConference (CCNC), 2018 15th IEEE Annual . IEEE, 2018, pp. 1–6.[12] S. Acharya, “Study and analysis of tcp/ip congestion control techniques:A review,”
Illinois Journalism Education Association , vol. 1, no. 2, pp.57–62, 2012.[13] M. A. Alrshah and M. Othman, “Test-bed based comparison of singleand parallel tcp and the impact of parallelism on throughput and fairnessin heterogenous networks,” in
ICCTD ’09. International Conference onComputer Technology and Development, 2009. , vol. 1, Nov 2009, pp.332–335.[14] S. Floyd and T. Henderson, “The newreno modification to tcps fastrecovery algorithm,” April 1999, RFC 2582, IETF Network WorkingGroup.[15] S. Floyd, “HighSpeed TCP for Large Congestion Windows,” April 2003,RFC 3649, IETF Network Working Group.[16] T. Kelly, “Scalable TCP : Improving Performance in Highspeed WideArea Networks,”
ACM SIGCOMM Computer Communications Review ,vol. 33, no. 2, pp. 83–91, 2003.[17] C. Jin, D. Wei, S. H. Low, J. Bunn, H. D. Choe, J. C. Doylle,H. Newman, S. Ravot, S. Singh, F. Paganini, G. Buhrmaster, L. Cottrell,O. Martin, and W. chun Feng, “Fast tcp: from theory to experiments,”
IEEE Network , vol. 19, no. 1, pp. 4–11, 2005.[18] R. S. D. Leith, “H-tcp: Tcp for high-speed and long distance networks,”in
Proceedings of PFLDnet , 2004, pp. 95–101.[19] C. Caini and R. Firrincieli, “TCP Hybla: a TCP enhancementfor heterogeneous networks,”
International Journal of SatelliteCommunications and Networking , vol. 22, no. 5, pp. 547–566, Sep 2004.
EEE SYSTEMS JOURNAL, 2019 11 [20] L. Xu, K. Harfoush, and I. Rhee, “Binary increase congestion control(bic) for fast long-distance networks,” in
INFOCOM 2004. Twenty-thirdAnnual Joint Conference of the IEEE Computer and CommunicationsSocieties , vol. 4, 2004, pp. 2514–2524.[21] R. King, R. Baraniuk, and R. Riedi, “TCP-Africa: An adaptive and fairrapid increase rule for scalable TCP,” in
INFOCOM 2005. 24th AnnualJoint Conference of the IEEE Computer and Communications Societies.Proceedings IEEE. , 2005, pp. 1–11.[22] Joel Sing and Ben Soh, “TCP New Vegas: Improving the Performanceof TCP Vegas Over High Latency Links,” in
Fourth IEEE InternationalSymposium on Network Computing and Applications . IEEE, 2005, pp.73–82.[23] H. Shimonishi, T. Hama, and T. Murase, “Tcp-adaptive reno forimproving efficiency-friendliness tradeoffs of tcp congestion controlalgorithm,” in
Proc. PFLDnet , 2006, pp. 87–91.[24] K. Tan and J. Song, “Compound tcp: A scalable and tcp-friendlycongestion control for high-speed networks,” in in 4th Internationalworkshop on Protocols for Fast Long-Distance Networks (PFLDNet) ,2006, pp. 80–83.[25] S. Liu, T. Bas¸ar, and R. Srikant, “Tcp-illinois: A loss-and delay-basedcongestion control algorithm for high-speed networks,”
PerformanceEvaluation , vol. 65, no. 6, pp. 417–440, 2008.[26] K. Kaneko, T. Fujikawa, Z. Su, and J. Katto, “TCP-Fusion : A HybridCongestion Control Algorithm for High-speed Networks,” in
Proc.PFLDnet, ISI, Marina Del Rey (Los Angeles), California. , 2007, pp.31–36.[27] A. Baiocchi, A. P. Castellani, and F. Vacirca, “YeAH-TCP : Yet AnotherHighspeed TCP,” in
Proc. PFLDnet. , Roma, Italy, 2007, pp. 37–42.[28] S. Ha and I. Rhee, “CUBIC: A New TCP-Friendly High-Speed TCPVariant,”
SIGOPS Operating Systems Review , vol. 42, no. 5, pp. 64–74,2008.[29] M. A. Alrshah, M. Othman, B. Ali, and Z. M. Hanapi, “Agile-SD:A Linux-based TCP congestion control algorithm for supportinghigh-speed and short-distance networks,”
Journal of Network andComputer Applications , vol. 55, pp. 181–190, 2015.[30] L. S. Brakmo and L. L. Peterson, “Tcp vegas: End to end congestionavoidance on a global internet,”
Selected Areas in Communications,IEEE Journal on , vol. 13, no. 8, pp. 1465–1480, 1995.[31] Z. Wang and J. Crowcroft, “Eliminating periodic packet losses in the4.3-Tahoe BSD TCP congestion control algorithm,”
ACM SIGCOMMComputer Communication Review , vol. 22, no. 2, pp. 9–16, 1992.[32] G. Wang, Y. Wu, K. Dou, Y. Ren, and J. Li, “Apptcp: The designand evaluation of application-based tcp for e-vlbi in fast long distancenetworks,”
Future Generation Computer Systems , vol. 39, pp. 67–74,2014.[33] R. Jain, D.-M. Chiu, and W. R. Hawe,
A quantitative measure of fairnessand discrimination for resource allocation in shared computer system .Eastern Research Laboratory, Digital Equipment Corporation, 1984.
Mohamed A. Alrshah (M’13–SM’17) receivedhis BSc degree in Computer Science fromNaser University - Libya, in June 2000. Then,he received his MSc and Ph.D degrees incommunication technology and networks fromUniversiti Putra Malaysia (UPM) in May 2009 andFeb 2017, respectively. Now, he is an AssistantProfessor (Senior Lecturer) in the Department ofCommunication Technology and Networks, Facultyof Computer Science and Information Technology,Universiti Putra Malaysia (UPM). He has publisheda number of articles in high-impact factor scientific journals. His researchinterests are in the field of high-speed TCP protocols, high-speed wired andwireless network, WSN, MANET, VANET, parallel and distributed algorithms,IoT and cloud computing.
Mohamed A. Al-Moqri received his BSc degree inComputer Science from Almustanseriah University- Iraq, in 2004. Then, he received his MSc and Ph.Ddegrees in communication technology and networksfrom Universiti Putra Malaysia in 2009 and 2016,respectively. Now, he is a Lecturer and Head ofdepartment of Information Technology in the Facultyof Computer Science and Information Technology,Azal University for Human Development, Sana’a,Yemen. He has published a number of articles inhigh-impact factor scientific journals. His researchinterests are in the field of high-speed TCP protocols, high-speed network,QoS, scheduling algorithms, admission control and wireless networks.