International Journal of Advances in Science and Technology, Vol. 3, No.

3, 2011

Advanced Performance Analysis of Transmission Control Protocol Collision Control Algorithms

1

J.David Sukeerthi Kumar , 2 Praneel Kumar Peruru, 3 A.Vineela, 4 P. Vidya Sagar,

1 2

Associate Professor, Dept of I.T, Santhiram Engg.College, Nandyal, Kurnool(Dt), A.P,

3

Assistant Professor, Dept of C.S.E, Srinivasa Ramanujan Institute of Technology,Anantapur,A.P, Asst.Professor, Dept. Of CSE, G.Pulla Reddy Engg college, Kurnool (Dt.),A.P,
4

Asst.Professor, Freshman Engineering Dept, K.L. University, Vaddeswaram, Guntur, A.P,

Abstract
The demand for fast transfer of large volumes of data, and the deployment of the network infrastructures is ever increasing. However, the dominant transport protocol of today, TCP, does not meet this demand because it favors reliability over timeliness and fails to fully utilize the network capacity due to limitations of its conservative congestion control algorithm. The slow response of TCP in fast long distance networks leaves sizeable unused bandwidth in such networks. A large variety of TCP variants have been proposed to improve the connections throughput by adopting more aggressive congestion control algorithms. Some of the flavors of TCP congestion control are loss-based, high-speed TCP congestion control algorithms that uses packet losses as an indication of congestion; delay-based TCP congestion control that emphasizes packet delay rather than packet loss as a signal to determine the rate at which to send packets. Some efforts combine the features of loss-based and delay-based algorithms to achieve fair bandwidth allocation and fairness among flows. TCP congestion-recovery scheme to (1) handle bursty packet losses while preserving the self-clocking capability; (2) detect a TCP connection's new equilibrium during congestion recovery, thus improving both link utilization and e_ective throughput; and (3) make the TCP behavior during congestion recovery very close to that during congestion avoidance, thus \extending" the performance model for congestion avoidance to that for TCP loss recovery. Moreover, the new recovery scheme requires only a slight modi_cation to the sender side of TCP implementation, thus making it widely deployable. The performance of the proposed scheme is evaluated for scenarios with many TCP ows under the drop-tail and RED gateways in the presence of bursty packet losses. The evaluation results show that the new scheme achieves at least as much performance improvements as TCP SACK and consistently outperforms TCP New-Reno. Furthermore, its steady-state TCP behavior is close to the ideal TCP congestion behavior. Since the proposed scheme does not require selective acknowledgments nor receiver modi_cations, its implementation is simpler than SACK, and only the servers in the Internet need to be modi_ed while keeping intact millions of clients scattered in the Internet.A comparative analysis between different flavors of TCP congestion control namely Standard TCP congestion control (TCP Reno), loss-based TCP congestion control (HighSpeed TCP, Scalable TCP, CUBIC TCP), delaybased TCP congestion control (TCP Vegas) and mixed loss-delay based TCP congestion control (Compound TCP) is presented here in terns of congestion window verses elapsed time after the connection is established. Key words - Congestion control, High-speed networks, TCP.

1. Introduction
Moving bulk data quickly over high-speed data network is a requirement for many applications. These applications require highbandwidth links between network nodes. To maintain the stability of Internet all applications should be subjected to congestion control. TCP [9] is well-developed, extensively used and widely available Internet transport protocol. TCP is fast, efficient and responsive to network congestion conditions but one objection to using TCP congestion control is that TCPs AIMD congestion back-off algorithm [1] is too abrupt in decreasing the window size, thus it hurts the data rate. Standard TCP constraints the congestion window that can be achieved in realistic environments. most notably due to the slow growth of TCP congestion window that makes TCP unfavorable for high BDP networks. When multiple packets within the same window are lost, the fast recovery algorithm treats each packet loss in a window as an independent congestion signal, thus halving the congestion window multiple times. The TCP Reno's drastic reduction of congestion window size, plus its over-estimation of data packets inhibits the transmission of new data packets, losing its self-clocking ability. A retransmission timeout is triggered and then slow-start begins to recover from packet losses, causing a substantial performance degradation. Recent Internet

Special Issue

Page 75 of 95

ISSN 2229 5216

International Journal of Advances in Science and Technology, Vol. 3, No.3, 2011 measurements [6] show that the majority of timeouts in TCP Reno are caused by bursty packet losses.The rest of the paper is organized as follows: Related works, including TCP modifications and new protocols are reviewed in section 2. Standard TCP congestion control algorithm is described in section 3. Three prominent window-based high-speed TCP congestion control algorithms that use packet-loss as an implicit indication of congestion are described in section 4. TCP Vegas, a delay-based TCP congestion control is explained in section 5. Compound TCP approach is described in section 6. The comparative analysis of these algorithms in terms of congestion window growth function verses elapsed time for different scenarios of two network topologies is presented in section 7. Finally, this work is concluded in section 8.

2. Background and Related Work

The standard TCP congestion control algorithm which we refer to as TCP Reno [1] was developed in 1988. [4], [5], [6], [7], [8], [10], and [15] explain several enhancements in TCP Reno. Few modifications addressing the conservative approach of TCP to update its congestion window under congestion condition are: i. Loss-based TCP congestion control: HSTCP [11], BIC-TCP [12], STCP [13], CUBIC-TCP [16], HTCP [17] etc. ii. Delay-based congestion control: TCP-Vegas [22], Fast-TCP [3], TCP-LP [18] etc. iii. Mixed loss-delay based TCP congestion control: Compound TCP [19], TCP Africa [20] etc. iv. Explicit congestion Notification: XCP[21] etc Most of these protocols deal with modifying the window growth function of TCP in a more scalable fashion. Tomoya et. al. [2] proposed a TCP-friendly congestion control that realizes efficient data transmission in highspeed networks, fairness with TCP Reno and fair bandwidth allocation among flows with different RTTs. A scheme that determines the size of congestion window each time a new acknowledgment is received instead of employing slow start/congestion avoidance approach is proposed in [14].

3. TCP Reno
TCP Reno implements the TCPs AIMD mechanism of increasing the congestion window W by one segment per round-trip time for each received ACK and halving the congestion window for each loss event per round-trip time. TCP Reno controls the congestion window as follows:

When the link bandwidth does not change, TCP Reno periodically repeats the window increase and decrease. TCP Renos congestion window in terms of packet loss rate (p) is defined as:

As shown in equation (3), TCP Reno places a serious constraint on the congestion window that can be achieved by TCP in realistic environments.

4. High-Speed TCP Variants

Although TCP performs very well in low to middle speed networks (Kbps to several Mbps), it has very poor performance in high (tens of Mbps to Gbps) to very high (Gbps to Tbps) speed networks, as TCP is very inefficient in utilizing the high-speed network bandwidth. HighSpeed TCP HighSpeed TCP (HSTCP) [11] is a modification to TCPs congestion control mechanism for use with TCP connections with large congestion windows. HighSpeed TCPs modified response function only takes effect with higher congestion windows, it does not modify TCP behavior in environments with heavy congestion, and therefore does not introduce any new dangers of congestion collapse. HSTCP uses three parameters, WL, WH, and PH. To ensure TCP compatibility, HSTCP uses the same response function as TCP Reno when the current congestion window is WL at most, and uses the HSTCP response function when the current congestion window is greater than WL. HSTCP ensures that the response function follows a straight line on a log-log scale as does the response function for Standard TCP, for low to moderate congestion. When the value of the average congestion window is greater than WL, the response function is as follows:

Special Issue

Page 76 of 95

ISSN 2229 5216

International Journal of Advances in Science and Technology, Vol. 3, No.3, 2011 HSTCP keeps average congestion window WH and WL, when packet loss rates are PH and PL, respectively. Recommended parameters are: WL = 38, WH = 83000 and PH = 107. This loss rate sets an achievable target for high-speed environments, while still allowing acceptable fairness for the HighSpeed response function when competing with Standard TCP in environments with packet drop rates of 10-4 or 10-5. PL = 103 is computed by using equation (3), when WL = 38. Thus, the HSTCP response function is computed as follows:

It is clear from equation (6) that HSTCP is more aggressive than TCP Reno and a HighSpeed TCP connection would receive ten times the bandwidth of a standard TCP in an environment with packet drop rate of 10-6, which is unfair. Scalable TCP : Scalable TCP [13] is designed to be incrementally deployable and behaves identically to traditional TCP stacks when small windows are sufficient. Scalable TCP (STCP) and High Speed TCP were originally designed for high-speed backbone links. STCP is a simple sender side modification to TCP congestion control, and it employs Multiplicative Increase Multiplicative Decrease (MIMD) technique. If STCP is mixed with regular TCP then STCP dominates the bandwidth for sufficiently large bandwidth-delay product region.

The recovery time after packet loss is 13.42RTT, i.e. proportional to the RTT and independent of congestion window size. An STCP connection can recover even a large congestion window in a short time and so that it makes efficient use of the bandwidth in high-speed networks. Suppose a TCP connection has a 1500 byte MTU and a round trip time of 200ms, then for 10Gbps network, congestion window recovery time after packet loss for STCP is 2.7 sec whereas that for Standard TCP is approximately 4hrs 43mins. CUBIC TCP CUBIC TCP[16] is an enhanced version of Binary Increase Congestion Control shortly BIC[12]. It simplifies the BIC window control function and improves its TCP- friendliness and RTT fairness as BICs growth function is too aggressive for TCP especially under short RTT or low speed networks. CUBIC function provides good scalability and stability. The protocol keeps the window growth rate independent of RTT, which keeps the protocol TCP friendly under short and long RTTs. The congestion epoch period of CUBIC is determined by the packet loss rate alone. As TCPs throughput is defined by the packet loss rate as well as RTT, the throughput of CUBIC is defined only by the packet loss rate. Thus, when the loss rate is high and/or RTT is short, CUBIC can operate in a TCP mode. The congestion window of CUBIC is determined by the following function:

where, C is the scaling factor, t is the elapsed time from the last window reduction, Wmax is the window size just before the last window reduction, and K = (Wmax/C) 1/3, where is a constant multiplicative decrease factor applied for window reduction at the time of loss event (i.e., the window reduces to Wmax at the time of the last reduction). To achieve reasonable TCP friendliness, fairness, scalability and convergence speed, we set C to 0.4, to 0.2, and Smax (window increment) to 160. The entire window growth function of CUBIC is described by just one function, it dose not need different phases of window control as in BIC, thus simplifying the complexity of BIC.

5. Delay-Based Congestion Control

Delay-based TCP congestion control algorithms like TCP Vegas attempt to utilize the congestion information contained in packet round-trip time (RTT) samples. The algorithm depends heavily on accurate calculation of the Base RTT value. Base RTT is set to be the minimum of all measured RTTs; it is commonly the RTT of the first segment sent by the connection. If the connection is not over flown by the traffic, the expected throughput is given by:

Special Issue

Page 77 of 95

ISSN 2229 5216

International Journal of Advances in Science and Technology, Vol. 3, No.3, 2011

where Window Size is the size of the current congestion window Then current actual sending rate is calculated once per round trip time as:

The congestion window is adjusted depending upon the difference between expected and actual sending rates.

Also two thresholds a and b are defined such that, a < b and a > b correspond to having too little and too much extra traffic in the network, respectively. When Difference < a, TCP Vegas increases the congestion window linearly during the next RTT, and when Difference > b, TCP Vegas decrease the congestion window linearly during the next RTT. The congestion window is left unchanged when a < Difference < b.

6. Mixed Loss-Delay Based TCP Congestion Control

Loss-based high speed algorithms are aggressive to satisfy bandwidth requirement but this aggressiveness causes TCP unfairness and RTT unfairness. Delay-based approaches provide RTT fairness but it is difficult to meet TCP fairness. Thus there is another approach that is a synergy of delay-based and loss-based approaches that addresses the problems in the two approaches. Compound TCP : Compound TCP [23] integrates a scalable delay-based component into the standard TCP congestion avoidance algorithm. This scalable delay-based component has a fast window increase function when the network is under-utilized and reduces the sending rate when a congestion event is sensed. To implement Compound TCP maintains the following state variables; cwnd (congestion window), dwnd (delay window), awnd (receiver advertised window). TCP sending window is calculated as follows:

cwnd is updated in the same way as controlled by standard TCP. Here in this case, on arrival of an ACK, cwnd is modified as:

Delay-based component is derived from TCP Vegas as explained in the above sub section.

7. Performance Evaluation
We assessed performance in terms of congestion window verses elapsed time. We used Network Simulator version 2 (ns-2) for simulations of three loss-based, high-speed TCP variants High Speed TCP, Scalable TCP, and CUBIC TCP; delay-based TCP congestion control namely TCP Vegas BDP is set to 30,000. All simulations were run long enough to ensure that the system had consistent behavior. Figure 1 and figure 7 show simulation topologies 1 and 2 respectively. The type of data traffic is FTP for both scenarios. Simulation Topology 1 For simulation topology 1, equal number of data sending nodes is connected to each main node labeled as 0, 1, 2 and 3. All main nodes have direct connections with one another in our topology. Flow of data between i number of nodes (where i = 1, 2, 3, 4, 5) connected to each main node (0, 1, 2, 3) is as follows

Special Issue

Page 78 of 95

ISSN 2229 5216

International Journal of Advances in Science and Technology, Vol. 3, No.3, 2011 Case a: Ai is a source node for Bi, Ci, and Di. Bi is a source node for Ai, Ci, and Di. Ci is a source node for Ai, Bi, and Di. TCP TAHOE TCP RENO

Di is a source node for Ai, Bi, and Ci.Performance of all the above mentioned algorithms was individually tested for TCP connections explained in case a for figure

Special Issue

Page 79 of 95

ISSN 2229 5216

International Journal of Advances in Science and Technology, Vol. 3, No.3, 2011

Figures 2-7 show the results of case a of simulation topology 1. It can be seen that all flavors of TCP congestion control give same response because equal number of sink nodes are connected to each source node. Thus, no serious congestion event resulting in packet drops occurs at any backbone link even though aggregate side bandwidth of the links with each main node exceeds that of the main links. Case b: Case b analyzes simulation topology 1 in four different ways. Four different scenarios with their simulation results is shown below. Scenario I: All TCP connections with i=1 have HighSpeed TCP support. All TCP connections with i=2 have TCP Reno support. All TCP connections with i=3 have Scalable TCP support. All TCP connections with i=4 have CUBIC TCP support..

Figure 8 shows there is no serious congestion collapse when each network node receives data traffic from Scenario IV: All TCP connections with i=1 have HighSpeed TCP support. All TCP connections with i=2 have TCP Reno support. All TCP connections with i=3 have TCP Vegas support. All TCP connections with i=4 have Compound TCP support. The simulation results for this network flow show unfair bandwidth allocation to TCP Reno depicted in figure 9 also Compound TCP also waits and increases window as explained in equation 14 and 15. When no congestion event occurs and network underutilization is noticed, i.e. for HighSpeed TCP, cwnd = WL; difference < a for TCP Vegas; Compound TCP as explained above in section V. Scenario III: All TCP connections with i=1 have TCP Vegas support. All TCP connections with i=2 have TCP Reno support. All TCP connections with i=3 have Compound TCP support. All TCP connections with i=4 have CUBIC TCP

Special Issue

Page 80 of 95

ISSN 2229 5216

International Journal of Advances in Science and Technology, Vol. 3, No.3, 2011 This scenario as shown in figure 10 results in serious congestion events and retransmissions and slow cwnd increase behavior. Scenario IV: All TCP connections with i=1 have HighSpeed TCP support. All TCP connections with i=2 have TCP Vegas support. All TCP connections with i=3 have Scalable TCP support. All TCP connections with i=4 have Cubic TCP support. Figure 11 depicts serious congestion events for scenario IV like scenario III because high-speed loss-based and delay-based TCP algorithms are competing with each other for bandwidth allocation Four scenarios of case b show that scenario I has optimum results among all other scenarios.

Flow of data from sender hosts to receiver hosts is explained for simulation topology 2 in table 1.

Special Issue

Page 81 of 95

ISSN 2229 5216

International Journal of Advances in Science and Technology, Vol. 3, No.3, 2011

Figure 16 shows that the congestion window growth behavior of CUBIC TCP is much better and smooth as compared to other loss-based TCP variants and there are less abruptly falling congestion windows and congestion window remains constant over the wide range of elapsed time. Compound TCPs behavior is almost similar to HSTCP as shown in figure 17 new congestionrecovery mechanism, called Robust Recovery (RR),to improve the performance of TCP flows in the presence of bursty packet losses. RR is evaluated by 22 simulation, and found to be able to recover from multiple packet losses in a window of data without any significant performance degradation. The key feature of RR is a variable-length recovery period, during which a sender recovers from packet losses, while also sending new packets to probe the new equilibrium of the TCP connection. Also, RR makes the TCP behavior during congestion recovery very close to that during congestion avoidance, thereby extending the performance model for TCP congestion avoidance to represent that for TCP congestion recovery as well.With existing TCP congestion-recovery strategies, making it possible to deploy RR incrementally in the Internet. Finally, figure 18 shows that TCP Vegas is the smoothest of all TCP congestion control algorithms and majority of TCP connections grow to attain the available capacity. Thus TCP Vegas allocates a fair share of bandwidth to each connection and resulted in no packet drop event. Thus, it is favorable to transmit traffic flows with TCP Vegas support for such network environment.

References :
[1]. V. Jacobson, Congestion avoidance and control,the ACM SIGCOMM88 [2]. Tomoya Hatano, Hiroshi Shigeno and Ken-ichi Okada, TCP friendly congestion control for highSpeed network, IEEE, 2007. [3]. David X. Wei, Cheng Jin, Steven H. Low, and Sanjay Hedge, Fast TCP: Motivation, Architecture, Algorithms, Performance, IEEE/ACM transactions on networking, 2006 [4]. W. Stevens, TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms, RFC2001, Jan. 1997 [5]. M. Allman, V. Paxson, and W. Stevens, TCP Congestion Control, RFC 2581, Apr. 1999 [6]. S. Floyd and T. Henderson, The NewReno modification to TCPs fast recovery algorithm, RFC 2582, Apr.1999. [7]. V. Jacobson, R. Braden, and D. Borman, TCP extensions for high performance, RFC 1323, May 1992 [8]. M. Mathis, J. Mahdavi, S. Floyd, and A. Romanow, TCP selective acknowledgment options, RFC 2018, Oct. 1996. [9]. Jon Postel, Transmission Control Protocol, September 1981, RFC 793 [10]. Allman, M., Balakrishnan, H. and S. Floyd, Enhancing TCPs Loss Recovery using Limited Transmit:, RFC 3042, January 2001 [11]. S. Floyd: HighSpeed TCP for Large Congestion Windows, RFC 3649, December 2003 [12]. Lisong Xu, Khaled Harfoush, and Injong Rhee: Binary Increase Congestion Control for Fast, Long Distance Networks, 2003 [13]. Tom Kelly: Scalable TCP: Improving performance in high-speed wide area networks; ACM SIGCOMM Computer Communication review, April 2003. [14]. Hamed Vahdet Nejad, Mohammad Hossien Yaghmaee, Hamid Tabatabaee, Fuzzy TCP: Optimizing TCP Congestion Control, IEEE, 2006 [15]. M. Allman, S. Floyd, C.Partridge, Increasing TCPs initial window, September 1998 [16]. Injong Rhee, and Lisong Xu: CUBIC: A New TCPFriendly High-Speed TCP Variant, Sangtae Ha, Injong Rhee, Lisong Xu. [17]. D. Leith, and R. Shorten: H-TCP: TCP Congestion Control for High Bandwidth-Delay Product Paths, June 20, 2005 [18]. Aleksandar Kuzmananovic and Edward W. Knightly, TCP-LP: a distributed Algorithm for low priority data transfer, IEEE 2003

Special Issue

Page 82 of 95

ISSN 2229 5216

International Journal of Advances in Science and Technology, Vol. 3, No.3, 2011 [19]. Kun Tan Jingmin Song, Qian zhang, Murari Sridharan, A Compound TCP Approach For High-Speed and Long Distance Networks. [20]. R. King, R. Baraniuk and R. riedi, TCP-Africa: An Adaptive and Fair Rapid Increase Rule for Scalable TCP, In Proc Infocom 2005 [21]. Dina Kitabi, M. Handley, and C.Rohrs, Internet Congestion Control for High Bandwidth-Delay Product Networks. ACM SIGCOMM 2002, August, 2002 [22]. Brakmo LS, Peterson LL, TCP Vegas: end to end congestion avoidance on a global internet. IEEE Journal on Selected Areas in Communications 1995 [23]. Kun Tan, Jingmin Song, Qian Zhang, Murari Sridharan, A Compound TCP Approach for High-speed and Long Distance Netowrks.

Author Profiles :
1]J.DAVID SUKEERTHI KUMAR was born in Nandyal, A.P, India. He received the B.Tech (Computer Science and Engineering) degree from the Jawaharlal Nehru Technological University, Hyderabad in the year 2004 and M.Tech ( Computer Science) from the same University, Hyderabad in the year 2008.He is currently working as an Associate Professor of the Dept I.T, at Santhiram Engineering College, Nandyal. (Email id: [email protected] ). His field of interest includes Computer Networks and Artificial Intelligence etc.

2]Praneel Kumar Peruru received the B.Tech (Computer Science and Engineering) degree from the Jawaharlal Nehru Technological University, Hyderabad in the year 2005 and Pursuing M.Tech from the Jawaharlal Nehru Technological University, Anantapur .He was Working as an Asst.Professor in Dept of CSE at Srinivasa Ramanujan Institute of Technology, Rotary Puram, Anantapur, A.P. (Email id: [email protected] ). His field of interest includes Network, Wireless networks, and Cloud computing

3]. A.Vineela working as Asst.prof in CSE Dept. G.Pulla Reddy Engg. college,she Completed M.Tech from JNTU Hyd. Her Research interests in areas are Network Security and Mobile computing and wireless networks. Mail id:[email protected]

4] P. Vidya Sagar Working as a Asst. Professor in K.L. University, Guntur. He has completed his M.Tech Acharya Nagarjuna University & presently pursuing PhD. He is having total 9 years of experience of which 6 years of industry experience and 3 years of teaching experience.

Special Issue

Page 83 of 95

ISSN 2229 5216