TCP-FIT: An Improved TCP Congestion Control Algorithm and its Performance

Transcription

1 TCP-FIT: An Improved TCP Conestion Control Alorithm and its Performance Jinyuan Wan, Jiantao Wen, Jun Zhan and Yuxin Han Key Laboratory of Pervasive Computin, Ministry of Education Tsinhua National Laboratory for Information Science and Technoloy Department of Computer Science and Technoloy, Tsinhua University, Beijin 84, China Abstract The Transport Control Protocol (TCP) has been widely used by wired and wireless Internet applications such as FTP, and HTTP. Numerous conestion alorithms have been proposed to improve the performance of TCP in various scenarios, especially for hih bandwidth-delay product (BDP) and wireless networks. Althouh different alorithms may achieve different performance improvements under different network conditions, desinin a conestion alorithm that performs well across a wide spectrum of network conditions remains a reat challene. In this paper, we propose a novel conestion control alorithm, named TCP-FIT, which could perform racefully in both wireless and hih BDP networks. The alorithm was inspired by parallel TCP, but with the important distinctions that only one TCP connection with one conestion window is established for each TCP session, and that no modifications to other layers (e.. the application layer) of the end-to-end system need to be made. Extensive experimental results obtained usin both network simulators as well as over live wired line, WiFi and G networks at different eoraphical locations and at different times of the day are presented. The performance of the alorithm shown in the experiment results is sinificantly improved as compared to other state-of-the-art alorithms, while maintainin ood fairness. I. INTRODUCTION The Transmission Control Protocol (TCP) [] is a reliable transport layer protocol that is widely used on the Internet. Conestion control alorithm [] is an interal module of TCP that directly determines the performance of the protocol. Standard conestion control alorithms such as TCP Reno [] and TCP NewReno [4], achieved reat success for several decades but are found to perform poorly over wireless and/or hih Bandwidth Delay Product (BDP) links. To improve TCP performance over wireless and hih BDP networks, many TCP variants have been proposed, includin TCP Westwood [5], [6], TCP Veno [7] for wireless applications and Compound TCP [8], TCP CUBIC [9], FAST TCP [] and [] for hih BDP networks. Althouh these alorithms have achieved success in their respective taret applications, desinin a TCP conestion control alorithm that perform racefully in both wireless and hih BDP networks is still a reat challene. On the other hand however, with the deployment of hihspeed wireless networks, such as LTE, WiMAX, as well as hih bandwidth, real time applications such as multimedia over TCP/HTTP, it is required for the TCP conestion alorithm to handle both wireless connections with random radio related losses as well as conestion-introduced issues which is typical for wired hih BDP networks. In this paper, a novel TCP conestion control alorithm for the heteroeneous networks which contain hih BDP links and wireless links, named TCP-FIT, is described. The alorithm was inspired by parallel TCP, but with the important distinctions that only one TCP connection with one conestion window is established for each TCP session, and that no modifications to other layers (e.. the application layer) of the end-to-end system need to be made. Extensive experimental results obtained usin both network simulators as well as over live wired line, WiFi and G networks at different eoraphical locations and at different times of the day are presented. It is shown that the performance of the alorithm is sinificantly improved as compared to other state-of-the-art alorithms, while maintainin ood fairness. The paper is oranized as the followin. Section II ives an overview of existin TCP conestion control alorithms and the motivation for the TCP-FIT alorithm. Section III describes the TCP-FIT alorithm in detail and the throuhput model of TCP-FIT is introduced in Section IV. Section V provides theoretical analysis of the network capacity utilization and fairness performance of TCP-FIT. Emulation-based experiment results and performance measured over live networks are iven in Section VI. Section VII concludes the paper. II. BACKGROUND AND MOTIVATIONS The function of TCP conestion control alorithm is to adjust the rate with which the protocol sends packets into the network usin a conestion control window. A ood conestion alorithm can fully utilize the bandwidth while avoidin over-drivin the network and thereby creatin packet losses. Since the conestion control mechanism has been introduced in TCP by BSD UNIX, many TCP conestion control alorithms are proposed. On a hih level, existin TCP conestion alorithms can be classified into three main cateories based on the input of the control mechanism - namely Loss-based TCP, Delay-based TCP and Hybrid TCP. Loss-based TCP includes the oriinal TCP Reno, TCP BIC[], TCP CUBIC, Hih Speed TCP[], Scalable TCP[4], etc. Amon these Loss-based TCP variants, TCP Reno and TCP CUBIC are widely deployed as standard TCP alorithms and default TCP of Linux respectively. Usin

2 packet loss as the symptom for network conestion, Lossbased TCP reduces the conestion control window when packet losses occur and increases the window otherwise. A basic assumption in the desin of Loss-based TCP conestion control is that packet losses are caused by over-drivin the network only, which is no loner valid when the alorithm is applied to wireless networks. Packet losses introduced via random physical layer artifacts (e.. multi-path, interferences) which is typical for wireless networks will cause the conestion control alorithm to aressively lower the conestion control window. On the other hand, in a hih BDP network, Loss-based TCPs require a very low (in the order 7 or lower []) random packet loss rate to fully utilize network capacity. This requirement is far from the reality of the network condition nowadays. Delay-based TCP includin TCP Veas [5] and FAST TCP [] uses the queuin delay as the symptom of conestion. The queuin delay is defined as the difference between the RTT and the propaation delay, i.e. time actually required for a packet to be transmitted from the sender to the receiver. Delay-based TCPs are more resilient to transient chanes of network conditions such as random packet losses and are also suitable for hih BDP networks [6]. The down side of the approach on the other hand is that, because increasin in queuin delay doesn t necessarily immediately lead to packet loss (due to buffers), when Delay-based TCP stations share the same bottleneck with Loss-based TCP stations, between the time when delay starts to increase and packet loss occurs, the window for the Delay-based TCP will decrease while that for the Loss-based TCP will not, leadin to bandwidth starvation for the Delay-based stations. Hybrid TCP uses both packet loss and delay as inputs control and includes TCP variants for wireless environments such as Veno and TCP Westwood, as well as TCP variants for hih speed links such as Compound TCP [8], TCP- Illinois [7], H-TCP [8] and Fusion TCP [9]. Amon these alorithms, Compound TCP has been widely deployed in the Microsoft Windows Vista operatin system. Althouh the performance of these TCP variants are ood for the application scenarios they were oriinally desined for, for the emerin new eneration of hih bandwidth wireless networks such as LTE and WiMAX, as well as for applications over heteroeneous networks combinin sements of hih BDP and wireless links, it becomes difficult for existin TCP conestion control alorithms to perform well. The TCP-FIT was motivated by various alorithms such as GridFTP [] and E-MulTCP []. These alorithms can utilize available bandwidth more by establishin multiple actual parallel TCP connections for the same application []. Various studies have shown that if an appropriate number of parallel TCP sessions is chosen, the performance for such alorithms can be very ood in wireless and lare BDP networks [] [] []. Such parallel TCP alorithms typically operate outside of the scope of TCP conestion control, and may often require support from the application layer. MulTCP is proposed in [4] to implement parallel TCP in Fi et Loss Rate (%) (a) Throuhput Deradation of Reno Packet Loss Rate (%) (b) Queui Dely (ms) N = N = N = 4 N = 8 N = Packet Loss Rate (%) (c) Performance and fairness of MulTCP over wireless link the transport layer. In MulTCP, N virtual TCP Reno sessions are simulated in a sinle TCP session. Fi. shows the simulation results when a MulTCP application with different values of N shared a network with a TCP Reno session. The bandwidth of the network was Mbps with % random packet loss and ms propaation delay. Fi. (a) shows the areated throuhput of the MulTCP application and the Reno session. It is clear that when N is sufficiently lare, network bandwidth can be fully utilized. However, the performance of a conestion control alorithm needs to be evaluated by more parameters than throuhput. If we define Throuhput Deradation as the ratio of the throuhput of a TCP Reno session when it shares the same network with MulTCP and the throuhput for a TCP Reno session when it is the only connection over a network, we will have the results in Fi. (b). As can be seen from the fiure, when N becomes larer, throuhput deradation becomes more and more severe, leadin to over 5% performance loss of the Reno session in many cases which is unacceptable in many real world applications. It is clear therefore, an intellient and adaptive alorithm that chooses an appropriate value of N is critical to MulTCP in real applications. Some N adaption alorithms for parallel TCPs such as [5] have been proposed, but are mostly application layer alorithms. Desinin a ood alorithm suitable for interation with MulTCP on the transport layer remains an open issue. Yet another observation of the behavior of MulTCP is iven in Fi. (c), which shows its queuin delay. Comparin Fi. (b) and Fi. (c), we can see that there seems to be a stron correlation between the queuin delay of a MulTCP session and the throuhput deradation of the competin Reno session on the same network. Usin this correlation as a cue, we can adapt the values of N such that network bandwidth can be more utilized, while at the same time, the queuin delay is kept at an acceptable level, so that the session remains fair. Based on these insihts, we proposed a novel TCP conestion control alorithm called TCP-FIT. In contrast to other parallel TCP techniques, TCP-FIT is a fully compliant TCP conestion control alorithm requestin no modifications to other layers in the protocol stack and/or any application software. III. THE TCP-FIT ALGORITHM In TCP-FIT, the Additive-Increase/Multiplicative-Decrease (AIMD) mechanism is employed to directly adjust the cones-

3 tion control window w. The AIMD combines linear rowth of the conestion control window w with an exponential reduction when a packet loss event takes place. In eneral, the w adjustment equation of the AIMD can be expressed as Each RT T : w w + A, Each Loss : w w B w, where A and B are increasin and decreasin factors of AIMD respectively. In the TCP Reno, A = and B = /. To achieve N times throuhput of the TCP Reno, the MulTCP sets A = N and B = /N. It will be shown in the analysis of Section IV, that iven the same network conditions, the standard MulTCP with the parament N can not uarantee that the conestion window is exactly N times that of a sinle Reno session. Therefore, in the TCP-FIT, w is decreased by a factor of B = /(N + ) instead of B = /N in the MultTCP when a packet loss occurs. This helps keep the throuhput of TCP-FIT flows exactly N times of the TCP Reno at the same network condition. For TCP-FIT, the conestion control window w adjustment equation can be expressed as, Each RT T : w w + N, Each Loss : w w N + w. () In TCP-FIT, the value N is a dynamic parameter that is updated after each packet loss event. For the i-th updatin period, N is updated by w N i +, if Q < α, N i w N i = N i, if Q = α, () N i max{, N i }, if Q > α w N i, where N i is the value of N in the i-th updatin period, w is the averae window size of the i-th updatin period and α is a parameter and < α <. Q is an estimate of the number of in-fliht packets of the TCP-FIT session that are currently queued in the network buffer, and is calculated in a way that is similar to existin delay-based TCP and hybrid TCP variants [5] Q = (rtt rtt min ) w rtt, () where rtt is the averae RTT window size of the current updatin period, rtt min is the minimal observed RTT value used as a reasonable estimate of the propaation delay of the network. (rtt rtt min ) represents the estimated value of the queuin delay. Since a TCP session sends w packets durin a RTT, w/rtt could be considered as an estimate of packet transmission rate of the current TCP session. Since w of a TCP-FIT session is N times of a Reno session, it is straihtforward to justify that the purpose of adjustin N of () is lettin the TCP-FIT session worked at a steady state where Q of the TCP-FIT session is proportional to a Reno session. We discuss how to set the proportionality factor α in Parameter LF P i W i N i a i X i b i β i packets sent i Wi Fi.. Definition 5 N i X i LFP i a i- W i a i b i ACKed packet lost packet No.ofRTT Rounds Last RTT Round RTT Rounds with loss Packets sent durin a Loss Free Period i-th Loss Free Period TABLE I NOTATION OF LFP The window size at the end of the LF P i The number of virtual sessions in LF P i The first packet lost in LF P i The RT T round where loss a i occurs The number of packets sent in the last RT T round The window decrease factor. Sections V. Combinin () with (), we et at the steady state, the averae value of N is rtt E[N] = α. (4) rtt rtt min IV. THROUGHPUT MODEL OF TCP-FIT In this section, we introduce an approximate stable state throuhput model for TCP-FIT. The model follows Padhye s well-known Reno throuhput model [6], and assumes that all loss events are detected by triple-duplicate ACKs and not consider the slow start and fast retransmission process. As illustrated in Fi., we define a Loss Free Period (LFP) as a period between two consecutive packet losses indicated by triple-duplicate ACKs. The notations used in this section are summarized in Table I. The evolution of TCP-FIT conestion control window after the slow-start phase can be viewed as a series of statistically i.i.d. LFPs. Each LFP is comprised of a number of RTT rounds. The conestion window W i of LF P i is increased by N i after each RTT and decreased by a factor of ( β i ) after each packet loss. Here β i = N i in MulTCP and β i = N i+ in TCP-FIT. For LF P i of duration A i, we define Y i as the number of packets sent. Then the expected steady-state TCP-FIT throuhput is T = E[Y ] E[A]. (5) As shown in Fi., a total of Y i = a i + W i packets are sent in X i + rounds. Followin the assumption in [6] that

4 E[a] = /, where is end-to-end packet loss rate of the TCP-FIT session, the expectation of Y can be calculated as E[Y ] = E[a] + E[W ] = + E[W ]. (6) Because the value of the conestion window in LF P i is bookended by ( β i )W i and W i, with an increment of N i after each RTT in LF P i, we have and Y i = X i k= (( β i )W i + kn i ) + b i = ( β i )W i X i + X in i (X i ) + b i, From (6) and (7) we have + E[W ] = E[X] (7) W i = ( β i )W i + N i X i. (8) ( ( E[β])E[W ] + while from (8) we have ) E[N](E[X] ) + E[b], (9) E[X] = E[β]E[W ]. () E[N] Similar to [6], we assume that b i s are uniformly distributed between and W i and therefore E[b] = E[W ]/. Then from (9) and () we have and E[W ] = E[X] = E[β]+ + ( E[β]+ ) + 4 E[β] E[β] E[N] (E[β] E[β] )/E[N], () E[β]+ + ( E[β]+ ) + 4 E[β] E[β] E[N]. () E[β] Let r i,j be the randomly distributed value of the j-th RTT of LF P i, with the duration of LF P i A i = X i+ j= r i,j. Assumin as in [6] that r i,j are independent of the size of the conestion window, and therefore independent of j, we have E[A] = (E[X] + )E[r]. () From () and () we have E[A] = ( E[β]+ + ( E[β]+ ) + 4 E[β] E[β] E[N] E[β] Combinin (5), (6), () and (4) we have T = = + E[W ] E[A] + E[β]+ + ( E[β]+ + ( E[β]+ ) +4 E[β] E[β] E[N] (E[β] E[β] )/E[N] ( E[β]+ ) +4 E[β] E[β] E[β] E[N] + )E[r] + )E[r]. (4) (5) TCP Sources TCP Sources Buffer TCP ACKs TCP Packets Bottleneck Link {B,U,P,D} TCP ACKs TCP Receivers Fi.. BDP Topoloy of the network model TCP Receivers When is sufficiently small, T = ( E[β])E[N] + o(/ ). (6) E[r] E[β] Let E[r] = D + q, where D is the averae propaation delay and q is the averae of queuin delay. Then from (4) { } α(d + q) E[N] = max,. (7) q Let = P + p, where P corresponds to the inherent losses of the link and p for losses caused by conestion. Consider that β i = N, i+ T = E[N] D + q (P + p) + o(/ P + p). (8) Compared with Reno s throuhput in Table II [6], (8) is E[N] times of throuhput of Reno. Combinin (7) and (8), the throuhput model of TCP-FIT is approximately expressed as T = max { D + q (P + p), α q (P + p) V. EFFICIENCY OF TCP-FIT }. (9) In this section, we use a simple but widely adopted network scenario to analyze three aspects of the performance of TCP- FIT: network utilization, rtt-fairness and inter-fairness. As illustrated in Fi., we assume that the network K includes one bottleneck link which has a bandwidth limit of B, buffer size of U, and round-trip propaation delay D, an inherent random packet loss rate of P and several nonbottleneck links with unlimited bandwidth and different roundtrip propaation delays. In the network model, n TCP sessions share the bottleneck link at the same time but may have different non-bottleneck routin paths. These TCP sessions may use different TCP conestion control alorithms. When these TCP sessions send packets throuh the network, we assume there are on averae M packets traversin the bottleneck. The relationship between M, the conestion packet loss rate p, and the queuin delay q can be approximated usin: p =, q =, if M < B D (a) p =, q >, if B D M B D + U (b) () p >, q, if B D + U < M (c)

5 In the state (a) of (), M is smaller than the link bandwidth-delay product (BDP), no packets are queued in the bottleneck buffer and no conestion packet loss occurs. If M is hiher than BDP but smaller than the BDP plus bottleneck buffer size U, which is state (b), the bottleneck bandwidth is fully utilized and packets bein to queue in the buffer. As a result, queuin delay q beins to increase but no packets are dropped due to network conestion. In state (c), when M is hiher than B D + U, the bottleneck buffer will overflow and some packets will be lost due to conestion, and queuin delay is effectively infinite. Obviously, the best state of operation is (b) when the bandwidth resource of the bottleneck is fully utilized with no conestion related packet losses. The function of the TCP conestion control alorithm is to adjust the packet sendin rate so that the correspondin session operates in this state while usin only a fair share of the resources. We list the throuhput models of several typical TCP variants in Table II usin the results of [6] [8] [7] [8] [9] [] and the analysis in the previous section. All of these models follow the same assumptions of (9) based on. A. Network Utilization Theorem : The bottleneck link of a network K depicted as in Fi. with a TCP-FIT session works in state (b) of (). Proof. It is obvious that the throuhput of TCP-FIT T < B. Suppose the bottleneck is in state (a), where q =. From (9) the throuhput of TCP-FIT T. This contradicts with T < B. If the bottleneck is in state (c), then q. From (9) and throuhput models in Table II we et T and therefore M, which means that the bottleneck is in state (a). Theorem shows that TCP-FIT can fully utilize the network capacity. Similar conclusions can be proved for TCP Veas and FAST but not for other TCP variants. We use the throuhput model of TCP Reno in Table II [6] as an example. Since p and q, there is an upper bound for the throuhput of a Reno session for any iven P and D that is not a function of B: T = D + q (P + p) D P. Similar upper bounds for the throuhputs of different TCP alorithms except for TCP-FIT and Veas/FAST are iven in the third column of Table II. Because these upper bounds are independent of B, when the bottleneck link state of network K is sufficiently bad (i.e. havin a hih packet loss rate P and/or a very lon propaation delay), or if the bandwidth B of bottleneck is sufficiently hih, the areated throuhput of the TCP sessions in K will be lower than the total bottleneck bandwidth B. Theoretically, therefore, except for TCP-FIT and Veas/FAST TCP, other TCP alorithms desined for wireless/lare-bdp networks could only mitiate but not completely solve the bandwidth utility problem in wireless/lare- BDP environments. At least theoretically, compared with these TCP variants, TCP-FIT has an advantae in its capability of achievin hiher throuhputs. B. Fairness RTT-fairness: By definition in [], RTT-fairness means that flows with similar packet drop rates but different roundtrip times would receive rouhly the same throuhput. We aain use TCP Reno as an example. Since different TCP sessions sharin the same bottleneck in K may traverse different non-bottleneck routes, their end-to-end propaation RTTs could be different. Usin the throuhput model of TCP Reno as an example, we can find the ratio of the throuhputs for two sessions i and j η = T i T j = D j + q D i + q. () If D i D j, the session with a loner propaation delay will have a low throuhput and therefore at a disadvantae. That leads to RTT-unfairness. As shown in the last column of Table II, the TCP-FIT could achieve theoretical RTT-fairness when E[N] >. When E[N] =, the TCP-FIT has same RTT-fairness property with the Reno. A TCP conestion control alorithm can t be perfect with respect to both RTT-fairness and inter-fairness because the TCP Reno is not RTT-fair. Inter-fairness: Inter-fairness, or TCP friendliness, refers to fairness between new TCP variants and standard TCP conestion control alorithm, the TCP Reno. We used the Bandwidth Stolen Rate (BSR) [8] to quantify the inter-fairness of TCP conestion control alorithms. Let T be the areated throuhput of m TCP Reno flows when they compete with another k TCP Reno flows. Let T be the areated throuhput of m TCP Reno flows when they compete with another k new TCP variant flows in the same network topoloy, then the BSR is defined as BSR = T T T. () To et a low BSR, the number of in-fliht packets that are queued in bottleneck buffer for k TCP-FIT sessions must not be sinificantly hiher than that for k Reno sessions. Recall that for TCP-FIT, the number of in-fliht packets Q = α w N, this means that α should be set to the ratio between the number of in-fliht packets that are queued in network buffer and the value of the conestion window for a Reno session to achieve inter-fairness. In a practical implementation, one can approximate this theoretical α value with the mean of each TCP-FIT session s (rtt max rtt min )/rtt max, where rtt max and rtt min are the maximal and minimal end-to-end RTTs observed for the session. Experiment results show that both the throuhput and fairness of the implementation when usin this approximation are ood. VI. EXPERIMENTAL RESULTS In our experiments, we embedded TCP-FIT into the Linux kernel (v.6.) of the server. For comparisons, we used the

6 TABLE II TCP MODELS TCP Variants Throuhput Models Upper Bounds η = T i (D i )/T j (D j ) TCP-FIT { } T = max D+q (P +p), α q (P +p) Reno T = D+q CTCP T = D+q Λ, Λ = ( ( β (P +p) k η = (when E[N] > ) (P +p) [6] T η = D j +q D P D i +q ) k k ) k k α k ( ( β ) k ) where, α, β and k are preset parameters. [8] Veno T = +γ D+q ( γ )(P +p), where γ 4 5. [7] Westwood T = T Λ D P T D k +γ ( γ )P η = (D j +q) (D i +q) η [ D j +q D i +q ] [8] (+γ i )(( γ j )(P +p)) (+γ j )(( γ i )(P +p)) ( (P +p)) [8] T (D (D+q)((P +p)d+q) P +p DP P η = j +q)((p +p)d j )+q (D i +q)((p +p)d i )+q Veas/FAST T = α /q, where α is preset parameter. [9] [] η = Fi Packet Loss Rate (a) Propaation Delay (b) CUBIC CTCP Reno Illinois HSTCP FAST Performance of the different TCP variants over a hih speed link Compound TCP for Linux from CalTech [] and implemented the FAST TCP alorithm based on the ns- code of FAST TCP []. Other TCP variants are available on the Linux kernel v.6., includin: TCP Reno and TCP CUBIC; TCP Westwood (TCPW) and TCP Veno, as benchmark of optimized TCP conestion control alorithms for wireless links; Hihspeed TCP (HSTCP) and TCP Illinois as benchmark of optimized TCP conestion control alorithms for hih BDP links. A. Emulation-Based Experiments In our experiments, we first conducted comparisons between different TCP alorithms usin network emulators. In the experiments, a TCP server and a TCP client were connected throuh the emulator, which injected random packet losses and delays into the connection and capped the network bandwidth to a selected value. We first compared the performance of the different TCP alorithms for hih BDP networks. In the experiments, we compared TCP-FIT with Reno, CUBIC, CTCP as well as HSTCP, Illinois and FAST for hih BDP networks. Followin [], the value of α of FAST was set to for Gbps links and for Mbps links. 4 Fi. 5. RTT (ms) RTT (ms) (a) Packet Loss Rate = % (b) Packet Loss Rate = % 5 5 RTT (ms) RTT (ms) (c) Packet Loss Rate = 5% (c) Packet Loss Rate = 7% CUBIC CTCP Reno TCPW Veno FAST 5 Performance of different TCP variants over a wirless link. Fi. 4(a) shows the resulted throuhput comparison for a Gbps link. We set the propaation delay to ms, and varied the packet loss rate from to 6 by a dummynet [4] emulator. As can be seen from the fiure, TCP-FIT achieved similar throuhput as FAST TCP, which was much hiher than other TCP alorithms. In Fi. 4(b), we set the bandwidth to Mbps with a packet loss rate of % usin a Linktropy [5] hardware network emulator. We varied the propaation delay from 4 ms to ms. Aain, TCP-FIT achieved hiher throuhput than other TCP variants. To compare the performances of the alorithm in the presence of wireless losses, we compared TCP-FIT with Reno, CUBIC, CTCP and as well as TCP Westwood and Veno, which were oriinally desined with wireless networks in mind. Althouh FAST was not oriinally desined specifically for wireless links, we also included it in the tests usin finetuned α values found by extensive trial and error. The link

7 TABLE III THROUGHPUT RATIO WITH DIFFERENT PROPAGATION DELAY (a) Packet Loss Rate = % (b) Packet Loss Rate = 5% RTT ratio / /4 /8 TCP-FIT FAST CUBIC CTCP Reno Fi. 6. Bandwidth Stolen Rate Fi Bandwidth occupation amon competin TCP sessions CUBIC CTCP Veno Illinois 5 4 Packet Loss Rate (a) BSR of different TCP variants Bandwidth Stolen Rate.5 α = 5 α = α = α = Packet Loss Rate (b) BSR of FAST with different α Bandwidth Stolen Rate comparison of different TCP variants TABLE IV EXPERIMENTAL ENVIRONMENTS Fiures Location Network Client OS Fi. 8(a) Zurich Ethernet Win Vista Fi. 8(b) LA Ethernet Win Vista Fi. 8(c) Beijin M ADSL Win XP Fi. 8(d) Zurich WIFI MAC OS Fi. 8(e) LA WIFI Win Vista Fi. 8(f) Beijin WIFI Linux Fi. 8() Beijin CDMA Win XP Fi. 8(h) Fujian CDMA Win Vista Fi. 8(i) Banalore 5k ADSL Win Vista bandwidth was set to 4 Mbps on a Linktropy emulator. In Fi. 5, the packet loss rate was set from % to 7%. In each experiment, we varied the propaation delay of the link from 5 ms to 5 ms. To simulate the random delay fluctuation of wireless link, Gaussian distributed delay noise were enerated by Linktropy emulator. The standard deviation of delay noise was 5% of the mean RTT. As can be seen from the fiures, TCP-FIT achieved much hiher throuhput than other TCP conestion control alorithms, includin FAST. Compared with FAST, which doesn t react to packet loss, TCP-FIT are more robust to random delay fluctuation of wireless link in the experiments. Fi. 6 and Fi. 7 are the results from inter-fairness experiments. In Fi. 6(a), one connection of a certain TCP alorithm is tested when competin with four TCP Reno sessions. The combined bandwidth was set to Mbps, with a propaation delay of ms and no random packet losses. As shown in Fi. 6(a), both TCP-FIT and Compound TCP occupied about % of the total bandwidth, i.e. same as when the alorithm is replaced with a 5th Reno session, or the theoretical fair share. FAST TCP and TCP CUBIC on the other hand, occupied up to 5% bandwidth, which means these alorithms miht be overly aressive and not inter-fair/tcpfriendly. Similar experiments were conducted for Fi. 6(b), with the total network bandwidth still set to Mbps but with 5% packet loss, and Gaussian distributed propaation delay with a mean of ms, and 8 ms standard deviation. In this case, as a result of the worsened network conditions, the TCP sessions combined were only able to use less than 4% of the the network bandwidth. TCP-FIT in this case was able to pick up some of the capacity that the other Reno sessions left unused, and it is important to also note that the percentaes (i.e. between 5% and %) of the bandwidth that the other Reno sessions used were still comparable to their respective numbers when 5 Reno sessions were used, indicatin that the additional throuhput that TCP-FIT was able to rab did not come at the expense of the Reno sessions. Fi. 7(a) shows the Bandwidth Stolen Rate. Accordin to the definition of BSR in (), in the experiments, we first ran Reno sessions over a 5 Mbps, ms delay link and then replaced Reno sessions with sessions of a different TCP variant. The ideal value of BSR is of course. It is shown in Fi. 7(a) that the BSR of TCP-FIT is a little hiher than Compound TCP, which is well-known to have extremely ood inter fairness characteristics, but much lower than TCP CUBIC. Compared with other wireless and hih speed network optimized alorithms, such as Veno and Illinois, the inter-fairness property of TCP-FIT is at a reasonable level. BSRs for FAST under the same link conditions are shown in Fi. 7(b). The inter-fairness of FAST depends on the selection of parameters α. Table III compares the RTT-fairness of TCP alorithms. In the experiment, TCP sessions were divided into two roups of to compete for a 5 Mbps link. One of the roups had a shorter delay of 5 ms. The other roup had loner delays that varied amon 5 ms, ms, ms, and 4 ms. The packet loss rate of the bottleneck link was.%. Table. III summarizes the throuhput ratios between sessions with different propaation delays. The ideal ratio should be. As shown in Table. III, the RTT-fairness property of TCP- FIT is similar to FAST TCP and CUBIC, and better than other alorithms.

8 5 : : : 5: 8: : 4: 7: : CUBIC CTCP Reno Illinois HSTCP (a) Wired Network at Zurich 5 : : 6: 9: : 5: 8: : : CUBIC CTCP Reno Illinois HSTCP (b) Wired Network at Los Aneles.5 7: : : : 5: 8: : 4: 7: CUBIC CTCP Reno Illinois HSTCP (c) Wired Network at Beijin.5.5 : : : 5: 8: : 4: 7: : Local time CUBIC CTCP Reno TCPW Veno (d) Wireless Network at Zurich 5 : : 6: 9: : 5: 8: : : CUBIC CTCP Reno TCPW Veno (e) Wireless Network at Los Aneles 4 7: : : : 5: 8: : 4: 7: CUBIC CTCP Reno TCPW Veno (f) Wireless Network at Beijin.5.5 5: 8: : 4: 7: : : : 5: CUBIC CTCP Reno TCPW Veno () G Network at Beijin.5.5 5: 8: : 4: 7: : : : 5: CUBIC CTCP Reno TCPW Veno (h) G Network at a town of Fujian Province 4 6: 7: 8: 9: : CUBIC CTCP Reno TCPW Veno (i) 5k ADSL Network at Banalore Fi. 8. Throuhput Variation at Different Locations B. Performance Measured over Live Networks Finally, to test the performance of TCP-FIT over live, deployed, real-world networks, we put a server in Orane County, California, US, on the Internet and tested TCP-FIT usin clients located in 5 different cities/towns in 4 countries (China, Switzerland, USA and India) on continents. At each location, we tested a combination of wired line connections, Wi-Fi and whenever possible, G wireless networks. The location, network and OS of the test clients are listed in Table IV. In each experiment, a script was used to automatically and periodically cycle throuh different TCP alorithms on the server over lon durations of time (4-4 hours), while the client collected throuhput information and other useful data. The period for chanin the TCP alorithms was set to about 5- minutes, so that ) the alorithms tested were able to reach close to steady-state performances; ) the period is consistent with the durations of a reasonably lare percentae of the TCP based sessions on the Internet (e.. YouTube streamin of a sinle piece of content, synchronizin s, refreshin one web pae, etc.). In the performance measure, TCP-FIT are compared with CUBIC, CTCP, Reno in all cases. HSTCP and Illinois are compared for wired networks and TCPW, Veno for wireless. Our results are summarized in Table V and Fi (8). Throuhout the experiments, TCP-FIT achieved speedup ratios up to 5.8x compared with averae throuhput of other TCP TABLE V AVERAGE THROUGHPUT (MBIT/S) Network Wired Network WIFI CDMA Location ZRH LAX PEK ZRH LAX PEK City Town FIT CUBIC CTCP Reno TCPW x x x Veno x x x Illinois.. x x x x x HSTCP. 6. x x x x x Speedup BSR conestion control alorithms. The throuhput of TCP-FIT was not always hiher than other TCP alorithms. In Fi. 8(i), when clients accessed the server throuh a low speed ADSL network with lare bandwidth variations, TCP-FIT had no obvious advantae compared with other TCP variants durin a 4-hour period. This was probably due to the fact that, compared with other TCP alorithms such as FAST which use very advanced network condition estimation alorithms, the correspondin modules in FIT were still relatively simplistic. For networks

9 5 5 : : : : : Time E MulTCP CUBIC Fi. 9. Throuhput comparison between TCP-FIT and E-MulTCP over live G network in Beijin. with lare variations, this miht lead to TCP-FIT performance deradations as the settins of key alorithm parameters such as Q depends on such estimates. To confirm that the performance ains of TCP-FIT did not come from rabbin bandwidth of other TCP sessions, we also measured the Bandwidth Stolen Rate of different TCP variants. The results are listed in the last row of Table V. As shown in the table, the BSR for TCP-FIT remained low. Finally, Fi. 9 shows a comparison between TCP-FIT and E-MulTCP as measured over China Telecom s G network in Beijin. Althouh strictly speakin E-MulTCP is not a TCP conestion alorithm per se, TCP-FIT was still able to achieve an averae of about 7% improvement. VII. CONCLUSIONS In this paper, we describe a novel TCP conestion control aloithm for application in both hih BDP and wireless networks. The alorithm was motivated by parallel TCP techniques, but is fully TCP compliant and requires no chanes to other layers of the protocol stack and/or application software. Theoretical and emulation results as well as performances measured usin live real world networks over continents show sinificant performance improvements in throuhput, fairness or robustness (e.. aainst network RTT variations) over state-of-the-art TCP variants such as TCP Reno, CUBIC, CTCP, Westwood, Illinois and FAST TCP. REFERENCES [] J. Postel, Transmission control protocol, RFC 79, September 98. [] V. Jacobson, Conestion avoidance and control, ACM SIGCOMM Computer Communication Review, vol. 5, no., pp , January 995. [] M. Allman, V. Paxson, and W. Stevens, TCP conestion control, RFC 58, April 999. [4] S. Floyd and T. Henderson, The new reno modification to TCPs fast recovery alorithm, RFC 58, April 999. [5] S. Mascolo, C. Casetti, M. Gerla, M. Sanadidi, and R. Wan, TCP Westwood: Bandwidth estimation for enhanced transport over wireless links, in Proceedins of ACM MobiCom, July, pp [6] R. Ferorelli, L. Grieco, S. Mascolo, G. Piscitelli, and P. Camarda, Live Internet measurements usin Westwood+ TCP conestion control, in Proceedins of IEEE GLOBECOM, vol., November, pp [7] C. Fu and S. Liew, TCP Veno: TCP enhancement for transmission over wireless access networks, IEEE Journal on Selected Areas in Communications, vol., no., pp. 6 8, February. [8] K. Tan, J. Son, Q. Zhan, and M. Sridharan, A compound TCP approach for hih-speed and lon distance networks, in Proceedins of IEEE INFOCOM 6, April 6, pp.. [9] S. Ha, I. Rhee, and L. Xu, CUBIC: a new TCP-friendly hih-speed TCP variant, ACM SIGOPS Operatin Systems Review, vol. 4, no. 5, pp , February 8. [] D. Wei, C. Jin, S. Low, and S. Hede, FAST TCP: motivation, architecture, alorithms, performance, IEEE/ACM Transactions on Networkin, vol. 4, no. 6, pp , 6. [] S. Gorinsky, M. Geor, M. Podlesny, and C. Jechlitschek, A theory of load adjustments and its implications for conestion control, Journal of Internet Enineerin, vol., no., October 7. [] L. Xu, K. Harfoush, and I. Rhee, Binary Increase Conestion Control (BIC) for fast, lon distance networks, in Proceedins of IEEE INFOCOM 4, March 4, pp [] S. Floyd, HihSpeed TCP for lare conestion windows, RFC 649, December. [4] T. Kelly, Scalable TCP: improvin performance in hihspeed wide area networks, ACM SIGCOMM Computer Communication Review, vol., no., pp. 8 9, April. [5] L. S. Brakmo, S. W. O Malley, and L. L. Peterson, TCP Veas: new techniques for conestion detection and avoidance, in Proceedins of ACM SIGCOMM. ACM, Auust -September 994, pp [6] S. H. Low, L. L. Peterson, and L. Wan, Understandin TCP Veas: a duality model, Journal of the ACM, vol. 49, no., pp. 7 5,. [7] S. Liu, T. Basar, and R. Srikant, TCP-Illinois: A loss-and delaybased conestion control alorithm for hih-speed networks, Elsevier Performance Evaluation, vol. 65, no. 6-7, pp , 8. [8] R. Shorten and D. Leith, H-TCP: TCP for hih-speed and lon-distance networks, in Proceedins of PFLDnet 4, February 4, pp. 95. [9] K. Kaneko, T. Fujikawa, Z. Su, and J. Katto, TCP-Fusion: A hybrid conestion control alorithm for hih-speed networkss, in Proceedins of PFLDnet 7, February 7, pp. 9. [] W. Allcock, J. Bresnahan, R. Kettimuthu, M. Link, C. Dumitrescu, I. Raicu, and I. Foster, The lobus striped GridFTP framework and server, in Proceedins of the 5 ACM/IEEE conference on Supercomputin, 5, p. 54. [] M. Chen and A. Zakhor, Flow control over wireless network and application layer implementation, in Proceedins of IEEE INFOCOM 6, March 6, pp.. [] E. Altman, D. Barman, B. Tuffin, and M. Vojnovic, Parallel TCP sockets: Simple model, throuhput and validation, in Proceedins of the IEEE INFOCOM 6, March 6, pp.. [] R. Chakravorty, S. Katti, J. Crowcroft, and I. Pratt, Flow areation for enhanced TCP over wide-area wireless, in Proceedins of the IEEE INFOCOM, vol., March, pp [4] J. Crowcroft and P. Oechslin, Differentiated end-to-end Internet services usin a weihted proportional fair sharin TCP, ACM SIGCOMM Computer Communication Review, vol. 8, no., pp. 5 69, July 998. [5] M. Chen and A. Zakhor, Rate control for streamin video over wireless, IEEE Wireless Communications, vol., no. 4, pp. 4, 5. [6] J. Padhye, V. Firoiu, D. Towsley, and J. Kurose, Modelin TCP throuhput: A simple model and its empirical validation, in Proceedins of the ACM SIGCOMM 98, 998, pp. 4. [7] B. Zhou, C. Fu, D. Chiu, C. Lau, and L. Noh, A simple throuhput model for TCP Veno, in Proceedins of IEEE ICC 6, vol., 6, pp [8] L. Grieco and S. Mascolo, Mathematical analysis of Westwood+ TCP conestion control, in Proceedins of IEE Control Theory and Applications, vol. 5, no., 5, pp [9] C. Samios and M. Vernon, Modelin the throuhput of TCP Veas, in Proceedins of ACM SIGMETRICS, June, pp [] S. Floyd and M. Allman, Comments on the usefulness of simple besteffort traffic, RFC 59, July 8. [] L. Andrew. Compound TCP in Linux. [Online]. Available: http: //netlab.caltech.edu/lachlan/ctcp [] T. Cui and L. Andrew. FAST TCP simulator module for ns-, version.. [Online]. Available: [] D. X. W. Chen Jin and S. H. Low. (, December) FAST TCP for hih-speed lon-distance networks. [Online]. Available: [4] L. Rizzo. Dummynet. [Online]. Available: luii/ ip dummynet/ [5] Linktropy Mini WAN Emulator. [Online]. Available: apposite-tech.com/products/mini.html