Fairness and Compatibility of TCP protocol in High ...

International Journal of Applied Engineering Research, ISSN 0973-4562 Vol. 10 No.69 (2015) © Research India Publications; httpwww.ripublication.comijaer.htm

Fairness and Compatibility of TCP protocol in High Speed Network Akshaya Kumar Barik

Prasant kumar Dash

Department of Computer Science and Engineering, SOA University, Bhubaneswar, India. [email protected]

Department of Computer Science and Engineering, C.V.Raman College of Engineering, India. [email protected]

Sukant Kishoro Bisoy Department of Computer Science and Engineering, C.V.Raman College of Engineering, India. [email protected] approach the value of the parameters like previous congestion window, time since last packet drop etc. keeps changing from time to time. The rest of the section is organized as follows. Section II presents the related work. Overview of high speed TCP is presented in section III. Section IV explains the results and analysis. Finally, section V, gives the conclusion of the paper.

AbstractDue to high demand of increasing capacity of high speed network, several TCP protocols have been proposed. Each protocol has different congestion control mechanism in high bandwidth delay product (BDP) network. In this paper fairness of competing high speed loss based TCP flows are analyzed along with their transient characteristics (starting delay). We analyzed Intra-protocol fairness and Inter-protocol fairness between competing flow in case 1 and 2, respectively. In case 3 and 4, we analyzed compatibility of high speed TCP with legacy protocol Reno and Vegas, respectively. In order to analyze transient characteristics starting delay between two flows is presented. We have considered three loss-based high speed TCP protocols HIGHSPEED, SCALABLE and CUBIC for our work. We measure throughput and congestion window of each flow to analyze fair share of throughput and fair share of bandwidth utilization respectively. Through NS2 simulator we found that SCALABLE is able to achieve high bandwidth share and dominant protocol when it compete with CUBIC or HIGHSPEED. The Intra-protocol fairness of HIGHSPEED is better than others. It is also observed that starting delay greatly impact on intra and inter-protocol fairness when multiple flows share a common link. Keyword: NS2.

II.

The fairness properties of many high speed TCP protocols are studied [10] focusing on inter and intra-protocol fairness along with RTT-fairness and friendliness. A cross layer techniques Hybrid TCP is proposed in [11] to improve TCP protocol and to get proper connection on wireless link, while incorporating the advantage of legacy TCP. In [12] author beautifully presented most TCP variants in pictorial way based on their behavior and presented a technique to solve problem. Author in [13] proposed a novel DCCP protocol to replace the UDP protocol which overcomes the problems of Internet operability. Through this author analyzed fairness, scalability and compatibility of DCCP with Reno. As standard TCP under utilize the resources of network in high BDP, HIGHSPEED protocol has been proposed to utilize the bandwidth in better way. However it is unfair in heterogeneous RTT. Through simulation and mathematical analysis author in [14] a factor to reduce the increase of window difference between flows. Proposed method brings fairer share of bandwidth with reduced packet loss. Fairness among heterogeneous TCP flows are analyzed over 10Gbps high-speed networks [15] using active queue management techniques (AQM) such as random early detection (RED), CHOKe with DropTail. Result shows that AQM techniques bring more fairness than DropTail for large buffer size. Homogeneous TCP share the bandwidth of network in fair manner than heterogeneous TCP. In [16] author analyzed the fairness between Reno and FAST TCP with an AQM technique RED with DropTail in single bottleneck dumbbell topology. The simulation and

BDP, Friendliness, Compatibility, Transient, and

I.

RELATED WORK

INTRODUCTION

Due to rapid growth of network topologies a number of high-speed protocols have been put forward such as HighSpeed TCP[1], SCALABLE TCP[2], CUBIC TCP[3] and BIC TCP[4], STCP[5], Fast-TCP [6], TCP-LP [7], Compound TCP [8], TCP Africa [9] etc. These high speed protocols obtain bandwidth faster than normal TCP. Highspeed protocols can be divided into loss-based and delaybased like standard TCP. Loss-based protocol rely on packet drops and delay-based rely on queuing delays in addition to packet drops for detecting congestion. High speed protocols are classified into static and dynamic approach based on the type of increase and decrease parameter used to update the congestion window. In static approach the parameter increase and decrease parameters are fixed. In dynamic

74

International Journal of Applied Engineering Research, ISSN 0973-4562 Vol. 10 No.69 (2015) © Research India Publications; httpwww.ripublication.comijaer.htm

experimental analysis shows that FAST TCP can be deployed for better utilization of bandwidth in high speed network. Author in [17] proposed a novel queue management techniques called Approximated-Fair and Controlled-Delay (AFCD) queuing to achieve approximated fairness, controlled low queuing delay, high link utilization. It decides drop probability of each flow based on target delay along with sending rate estimation. Through experiments AFCD achieved approximated fair share of bandwidth among flows and ensure low queuing delay with comparable link utilization. III.

1.3 CUBIC CUBIC is another loss based high speed TCP which uses a cubic function to increase the congestion window based on the receiving of acknowledgement from receiver. CUBIC varies its congestion window based on the time elapsed since last packet drop has occurred. This makes congestion window to grow faster after a packet drop. And also the congestion window rate slows down as it gets closer to the value before the last packet drop occurred. The dependency of CUBIC on the time elapsed since last packet drop makes it fair regardless of its round-trip time (RTT). Because, no matter what the RTT of the two flows may be, the time elapsed from last packet drop will be same for both flows. There is a limit on the maximum size of the congestion window. The congestion window of CUBIC (Wc) is determined by the following equation:

OVERVIEW OF HIGH SPEED TCP

Standard TCP is not able utilize the bandwidth efficiently in high speed network. So high speed protocols are developed to utilize resources efficiently in high speed network where BDP is very high. However behavior of each protocol is different from others.

Wc = C (t – K)3 + Wmax Where C is a scaling factor and t is the time elapsed since last packet drop. Wmax is the congestion window size just before last reduction and K is a factor determined as K=(Wmaxβ/C)1/3 where β is the constant decrease factor for window reduction during a packet drop.

1.1 High-Speed TCP (HIGHSPEED) HIGHSPEED protocol is designed by Sally Floyd for high speed network whose congestion window size is very large. It retains the normal behavior of standard TCP protocol with some modification on sender side. It shows its aggressive behavior in normal scenario (low rate) and behaves gently at high scenario (high rate). Below a threshold value it uses standard TCP’s congestion control algorithm. HIGHSPEED increases and decreases its congestion window depending up on receipt of acknowledgement (ACK) or detection of packet loss, respectively. The Congestion window of HIGHSPEED is modified as given below.

IV.

RESULT AND ANALYSIS

In this section we present the results gathered from all four cases we have considered. The throughput and congestion window of each flow is measured with same RTT in single bottleneck dumbbell topology which is shown in figure 1. Irrespective of cases, first connection from S1 to D1 starts at 0.0 sec and second connection from S2 to D2 starts after 20.0sec to study the transient characteristics. The buffer size of the router R1 is 3000 packets and window size is 5500 packets where each packet is 1500 bytes. To analyze fairness of each protocol we measured throughput with sampling rate 1 sec and plotted window size (or bandwidth utilization) with cwnd/queue sampling is 0.01sec of individual connection. To study the transient characteristics i.e. few second of starting delay between two flows is used for all cases. Starting delay can significantly impact in the performance and fairness of high speed protocols [18]. However, the explanations of the phenomena have not been given yet.

cwnd = cwnd + α / cwnd (Upon receipt of ACK packet) cwnd = cwnd * (1 – β) (Upon detection of packet drop) The parameters α and β are maintained in table as increase and decrease parameters. 1.2 Scalable – TCP Scalable-TCP is another loss based protocol designed by Kelly to improve the performance of HIGHSPEED with modification at sender side. It behaves in the same way as HIGHSPEED with an exception in determining the values of increase (α) and decrease parameters (β) of the congestion window. It updates it congestion window based on following: cwnd = cwnd + α (up on receipt of ACK packet) cwnd = (1 – β * cwnd)(when a packet drop is detected) The value of parameters α and β are 0.01 and 0.125 respectively. It shows its aggressiveness in increasing and less aggressiveness in decreasing the congestion window.

75

International Journal of Applied Engineering Research, ISSN 0973-4562 Vol. 10 No.69 (2015) © Research India Publications; httpwww.ripublication.comijaer.htm Figure 1. Dumbbell topology

Case 1: Inter-Protocol Behavior Inter-protocol fairness or TCP friendliness refers to all the traffic flows based on different protocols can be fair to distribute the link bandwidth. To find fairness and bandwidth utilization between two flows we measure throughput and window size of each flow respectively with 20sec of starting difference between two flows. We studied the inter-protocol fairness considering three scenarios. In scenario 1, S1 uses CUBIC and S2 uses SCALABLE and then alternatively S1 uses SCALABLE and S2 use CUBIC with same RTT. In scenario 2, S1 uses CUBIC and S2 uses HIGHSPEED then alternatively S1 uses HIGHSPEED and S2 use CUBIC with same RTT. In scenario 3, S1 uses SCALABLE and S2 uses HIGHSPEED then alternatively S1 uses HIGHSPEED and S2 use SCALABLE with same RTT.

(b) Figure 2. Congestion window of competing flows, delay- 20sec (a) CUBIC-SCALABLE (b) SCALABLE-CUBIC

Here window size and throughput of each flow is measured for all scenarios. In scenario 1, if CUBIC starts before SCALABLE then it needs approximately 70 seconds for SCALABLE to get equal and more bandwidth than CUBBIC as shown in figure 2(a). As time increases, window size of CUBIC flow decreases and SCALABLE increases. If SCALABLE starts 20sec before CUBIC then window size of SCALABLE is much higher than others (see figure 2(b)). It indicates that SCALABLE uses more bandwidth than CUBIC as it able to control the congestion better way than CUBIC. In scenario 2, S1 uses CUBIC and S2 uses HIGHSPEED after 20 sec and alternatively S1 uses HIGHSPEED and S2 uses CUBIC for simulation duration 90 sec. From figure 3 it is observed that CUBIC uses more bandwidth than HIGHSPEED. In scenario 3, SCALABLE utilizes more bandwidth than HIGHSPEED by increasing their window size even then SCALABLE starts after 20 sec (see figure 4). It needs approximately 40 sec to utilize fair share of bandwidth and to succeed further. From all presented scenarios it is observed that SCALABLE uses more bandwidth and dominate protocol than others.

(a)

(b) Figure 3. Congestion window of competing flows, delay- 20sec (a) CUBIC-HIGHSPEED (b) HIGHSPEED-CUBIC

(a)

(a) (b) Figure 4. Congestion window of competing flows, delay- 20sec (a) SCALABLE-HIGHSPEED (b) HIGH SPEED- SCALABLE

76

International Journal of Applied Engineering Research, ISSN 0973-4562 Vol. 10 No.69 (2015) © Research India Publications; httpwww.ripublication.comijaer.htm

For all three scenarios, throughput of each competing flow is measured which is shown from figure 5 - 7. In scenario 1, SCALABLE achieves much higher throughput than CUBIC for whole duration. However protocol SCALABLE needs 60 seconds to achieve fair share of throughput if it starts 20 after CUBIC (figure 5). In scenario 2, CUBIC achieves high throughput than HIGHSPEED if it starts 0sec. However, CUBIC needs more time to get fair bandwidth of shared link if starts after 20sec (figure 6). As shown in figure 7, SCALABLE get large throughputs share from CUBIC, if it starts at 0sec for scenario 3. However it needs 50 seconds to get fair share of throughput, if it started 20 sec later. From all three scenarios presented, SCALABLE TCP able to get large share of throughput than others due to accurate estimation of window size.

(b) Figure 6. Throughput (Mbps) of competing flows, delay- 20sec (a) CUBIC-HIGHSPEED (b) HIGHSPEED-CUBIC

(a)

(a)

(b) Figure 7. Throughput (Mbps) of competing flow, delay- 20sec (a) SCALABLE-HIGHSPEED (b) HIGH SPEED- SCALABLE

Case 2: Intra-protocol behavior In this section fairness of competing flow is analyzed using similar type of protocol in two connections where starting difference is 20sec. We have considered SCALABLE, CUBIC and HIGHSPEED TCP to study intraprotocol fairness for duration of 100sec. Always first flow starts at 0 sec and second flow starts at 20 sec. Similar to case 1, congestion window and throughput is measured for each flow running similar type of protocol. From figure 810, it is observed that fair share of bandwidth is achievable between flows in HIGHSPEED protocol as compared to CUBIC and SCALABLE. The difference between flows is very high in SCALABLE TCP (see figure 8 and 9).

(b) Figure 5. Throughput (Mbps) of competing flows, delay- 20sec (a) CUBIC-SCALABLE (b) SCALABLE-CUBIC

(a)

77

International Journal of Applied Engineering Research, ISSN 0973-4562 Vol. 10 No.69 (2015) © Research India Publications; httpwww.ripublication.comijaer.htm

Figure 8. Window Size of competing flows, delay- 20sec

Figure 12. Throughput (Mbps) of competing flows, delay- 20sec

Figure 9. Window Size of competing flows, delay- 20sec

Figure 13. Throughput (Mbps) of competing flows, delay- 20sec

Case 3: Compatibility of High speed TCP with TCP Reno This section checks compatibility of High speed TCP protocol with legacy loss-based protocol Reno. Both window size and throughput is measured for each flow considering three scenarios as shown from figure 14-19. In first scenario, S1 is associated with Reno and S2 associated with SCALABLE with 20sec delay difference and then alternatively used SCALABLE as a first and Reno as a second flow. In second scenario S1 is associated with Reno and S2 associated with HIGHSPEED with 20sec delay difference and then alternatively used HIGHSPEED as first flow and Reno as second flow. In third scenario S1 is associated with Reno and S2 with CUBIC with 20sec delay difference and then alternatively used CUBIC as first flow and Reno as second flow. It is observed from figure 14(a)19(a), Reno is somehow compatible with HIGHSPEED as compared to SCALABLE and CUBIC with respected to congestion window and throughput if Reno starts before 20sec before high speed protocol. However Reno is not at all compatible with any one if Reno starts 20sec after high speed protocol. It reveals, starting time greatly influence in getting fair share in a network.

Figure 10. Window Size of competing flows, delay- 20sec

Then we measured throughput of two competing flow with starting delay difference 20 sec and shown from figure 1113. Second flow gets fewer throughputs and suffers more, if the flow starts after 20 sec. It shows starting delay can have a relevant impact on the throughput and window size. Among three protocols we have considered, fair share of throughput between flows are achievable in HIGHSPEED and unfairness exhibit using SCALABLE TCP(figure 12 and 13).

Figure 11. Throughput (Mbps) of competing flows, delay- 20sec

(a)

78

International Journal of Applied Engineering Research, ISSN 0973-4562 Vol. 10 No.69 (2015) © Research India Publications; httpwww.ripublication.comijaer.htm

(b) Figure 14. Congestion window of competing flows, delay- 20sec (a) RENO-SCALABLE (b) SCALABLE-RENO

(a)

(b) Figure 17. Congestion window of competing flows, delay- 20sec (a) RENO-SCALABLE (b) SCALABLE-RENO (a)

(b) Figure15. Congestion window of competing flows, delay- 20sec (a) RENO-HIGHSPEED (b) HIGHSPEED-RENO

(a)

(b) Figure 18. Throughput(Mbps) of competing flows, delay- 20sec (a) RENO-HIGHSPEED (b) HIGHSPEED-RENO

(a)

(b) Figure 16. Congestion window of competing flows, delay20sec (a) RENO-CUBIC (b) CUBIC-RENO

(a)

79

International Journal of Applied Engineering Research, ISSN 0973-4562 Vol. 10 No.69 (2015) © Research India Publications; httpwww.ripublication.comijaer.htm

(a)

Figure 19. Throughput(Mbps) of competing flows, delay- 20sec (a) RENO-CUBIC (b) CUBIC-RENO

Case 4: Compatibility of High speed TCP with TCP Vegas In this section we analyzed compatibility of high speed TCP with legacy protocol Vegas. Window size and throughput is measured for each connection considering three scenarios as shown from figure 20-24. In first scenario S1 is associated with Vegas and S2 associated with SCALABBLE with 20sec delay difference and then alternatively used first flow is SCALABLE and second flow Reno. In second scenario S1 is associated with Reno and S2 associated with HIGHSPEED with 20sec delay difference and then alternatively used first flow is HIGHSPEED and second flow is Reno. In third scenario S1 is associated with Reno and S2 associated with CUBIC with 20sec delay difference and then alternatively used first flow is CUBIC and second flow Reno. It is observed that Vegas is not compatible with any of these protocols keeping huge difference in window size and throughput. High speed protocol dominates because of its more aggressive behavior which steals more bandwidth than Vegas.

(b) Figure 21. Congestion window of competing flows, delay- 20sec (a) VEGAS-HIGHSPEED (b) HIGHSPED-VEGAS

(a)

(a)

(b) Figure 22. Congestion window of competing flows, delay- 20sec (a) VEGAS-SCALABLE (b) SCALABLE-VEGAS

(b) Figure 20. Congestion window of competing flows, delay- 20sec (a) VEGAS-CUBIC (b) CUBIC-RENO

(a)

80

International Journal of Applied Engineering Research, ISSN 0973-4562 Vol. 10 No.69 (2015) © Research India Publications; httpwww.ripublication.comijaer.htm

between them. The intra-protocol fairness of HIGHSPEED is better than others. Reno is somehow compatible with high speed protocol as compared to Vegas and starting delay greatly impact on intra and inter-protocol fairness when multiple flows compete for a link.

(b) Figure 23. Throughput(Mbps) of competing flows, delay- 20sec (a) VEGAS-HIGHSPEED (b) HIGHSPEED-VEGAS

REFERENCES [1] S.Floyd, "HIGHSPEED TCP for large congestion Windows," RFC 3649, 2003. [2] T. Kelly, "Scalable TCP: Improving performance in high speed wide area networks," Computer Communication Review, vol. 33, pp. 83-91, 2003. [3] S. Ha, 1. Rhee and L. Xu, "CUBIC: a new TCP-friendly high-speed TCP variant," SIGOPS Oper. Syst. Rev, vol. 42, pp. 64-74, 2008. [4] L. Xu, K. Harfoush, and I. Rhee “Binary Increase Congestion Control (BIC) for Fast Long-Distance Networks”, IEEE, INFOCOM, Hong Kong, pp. 2514–25242004. [5] R. N. Shorten, D. J. Leith, “H-TCP: TCP for high-speed and longdistance networks”, In: 4th International workshop on Protocols for Fast Long-Distance Networks (PFLDNet), Argonne, 2004. [6] D. X. Wei, C. Jin, S. H. Low, S. Hegde, “FAST TCP: motivation, architecture, algorithms, performance”, IEEE/ACM Transactions on Networking (TON), vol.14(6), pp.1246-1259, December 2006. [7] M. Nabeshima and K. Yata, “Performance Evaluation and Comparison of Transport Protocols for Fast Long-Distance Networks”. IEICE Trans. Commun., Vol. 89(4), pp. 1273-1283, Apr. 2006. [8] K. Tan, J. Song, Q. Zhang, and M. Sridharan, "Compound TCP: A Scalable and TCP-friendly Congestion Control for High-speed Networks", In: 4th International workshop on Protocols for Fast Long-Distance Networks (PFLDNet), 2006, Nara, Japan. [9] R. King, R. Baraniuk and R. riedi, "TCP-Africa: An Adaptive and Fair Rapid Increase Rule for Scalable TCP", In : INFOCOM 2005. [10] D. Miras, M. Bateman, S. Bhatti. "Fairness of High-Speed TCP Stacks", In: IEEE 22nd International Conference on Advanced Information Networking and Applications(AINA), p.84-92, March 25-28, 2008. [11] Y. Douga, M. Bourenane, “New adaptation method of TCP for mobile ad hoc networks”, In: world congress on Computer Applications and Information Systems (WCCAIS), pp. 1-6, 2014. [12] A. Afanasyev, N. Tilley, P. Reiher, L. Kleinrock, “ Host-to-host congestion control for TCP”, IEEE Commun Surv Tutor 12(3), pp.304-42, 2010. [13] C. A. Froldi, F. da, N.L.S. Fonseca, C. Papotti, “Manzato, D.A.G. Performance evaluation of the DCCP protocol in high-speed networks”, In: 15th IEEE International Workshop on Computer Aided Modeling, Analysis and Design of Communication Links and Networks (CAMAD), pp. 41- 46, Dec. 2010. [14]W. Y. Liu, Z. R. Chen, Y. Shi, H. Q. Wang, “Average RTT HSTCP: Improving Fairness in High-Speed Networks”, 2007 International Conference on Machine Learning and Cybernetics, pp. 3820- 3824, 19-22 Aug. 2007. [15] L. Xue, S. Kumary, C. Cui, S.Park, “An evaluation of fairness among heterogeneous TCP variants over 10Gbps high-speed networks”, In: IEEE 37th Conference on Local Computer Networks (LCN), pp. 344 – 347, 2225 Oct. 2012. [16] W. Liang, S. Xu, J. Chang, “Fairness Comparison Based on Queue Schedule between Fast and Reno”, In: 2011 7th International Conference on Wireless Communications, Networking and Mobile Computing (WiCOM), pp. 1- 4, 23-25 Sept. 2011. [17] L. Xue, B. Rouge, S. Kumar, C. Cui, P. Kondikoppa, “AFCD: An Approximated-Fair and Controlled-Delay Queuing for High Speed Networks”, In: 22nd International Conference on Computer Communications and Networks (ICCCN), pp. 1-7, 2013. [18] M.C. Weigle, P. Sharma, and J. Freeman, “Performance of Competing High-Speed TCP Flows”, Proceeding of Netowrking, Coimbra, Portugal, pp. 476-487, May 2006.

(a)

(b) Figure 24. Throughput (Mbps) of competing flows, delay- 20sec (a) VEGAS-SCALABLE (b) SCALABLE-VEGAS

V.

CONCLUSION

We analyzed the fairness of high speed protocols in high bandwidth-delay product (BDP) network considering inter and intra-protocol properties. Here, HIGHSPEED, CUBIC TCP, Scalable TCP is used as high speed protocol and Reno and Vegas is used as legacy loss based and delay based TCP, respectively. We analyzed how the transient state can influence the long-term fairness performance. Then we analyzed the compatibility of high speed protocols with legacy protocol Reno and Vegas. Through extensive study in NS2 we observed that SCALABLE is able to achieve large bandwidth and high throughput and dominant protocol when it competes with CUBIC or HIGHSPEED. In the other way inter-protocol fairness of SCALABLE with others are not very good. Specifically, SCALABLE TCP exhibit very substantial unfairness in this experiment. However CUBIC and HIGHSPEED protocol have better fairness (or friendliness)

81