Veno-A: Adaptive Congestion Control Approach for Hybrid Network

Transcription

1 Volume 120 No , ISSN: (on-line version) url: Veno-A: Adaptive Congestion Control Approach for Hybrid Network Sanjesh S. Pawale 1, Sandeep B. Vanjale 2 1 Research Scholar, 2 Professor, 1,2 Department of Computer Engineering, Bharati Vidyapeeth Deemed University, College of Engineering, Pune, India. 1 sanjeshpawale@gmail.com, 2 sbvanjale@bvucoep.edu.in July 5, 2018 Abstract Transport Control Protocol (TCP) carries most of the traffic of internet, so the behavior of internet depends on the performance of TCP. One of the factors affecting the performance of TCP is Congestion Control Approach. Many Congestion Control Algorithms work well for the wired network but for wireless and hybrid network they fail to perform well. The original TCP design assumes packet loss is always induced by congestion. This assumption can lead to significant performance degradation in wireless networks as often packet loss is due to random losses. Hence TCP Veno was modeled as it has the ability to distinguish random and congestion loss. Veno has a variable called beta which is constant and which limits the increment in the window size. As a result, TCP Veno fails to utilize the network resources fully. This paper proposes a modification in a congestion control mechanism called TCP Veno which is able to deal with random loss effectively and changes the beta value dynamically. The proposed Algorithm, TCP VENO-A, deals 1 447

2 with the random losses and suppresses the effect imposed due to the beta variable by making it dynamic. It also uses the alpha variable which is used in TCP Vegas to decide when to enter slow start phase. TCP VENO-A modifies the Congestion Avoidance phase of original TCP VENO. Key Words:TCP, Congestion Control, Congestion Window. 1 INTRODUCTION Congestion is a problem that occurs on shared networks when multiple users contend for access to the same resources (bandwidth, buffers, and queues). Analogues to this are roadways. Many vehicles enter on the road without bothering about the traffic on road. Due to this traffic on road increases, and more congestion occurs. In the similar way as flow increases the number of packets too increases beyond the network capacity and eventually, packets are lost. For minimizing the rate congestion control[1] uses a window which limits the number of packets to flow in the network at given time. The size of a window is changed dynamically by TCP variants. TCP variants are categories as per their nature; proactive, reactive or both. Proactive use delay as network parameter to detect congestion i.e. before a packet is actually lost it takes care of congestion window (cwnd)[2]. Reactive uses packet loss as to check whether it is in congestive or non- congestive state. It reacts after loss i.e. it decreases cwnd when it observes that packet is lost. The Hybrid combines the feature of proactive and reactive. When the network is underutilized, it operates in a delay mode and exploits the residual capacity of the bandwidth. When the network becomes congested, it moves to a reactive mode and behaves as Reno[3][4][5] until next packet losses happen. In this paper, we have used Veno and modified it when it operates in delay mode i.e. modified only TCP Vegas part

3 2 TCP VEGAS TCP Vegas[2] is a delay based congestion control TCP variant which means it decreases the cwnd before the packet is lost. Thus it is less aggressive than Reno[6]. Vegas maintain two variables, alpha and beta, which controls the size of cwnd dynamically. Whenever the network is not congested the expected flow rate will be the actual flow rate. In a congested network scenario, the expected flow rate is larger than actual flow rate. With the help of difference between expected and actual flow rate, TCP Vegas[7] estimates available network bandwidth. Using this difference (d), it estimates the congestion level in the network and updates the window size accordingly. This difference in the flow rates can be easily translated into the difference between the window size and the number of acknowledged packets during the round trip time. Thus TCP Vegas tries to keep at least alpha packet but no more than beta packets in the queues and maintains the equilibrium state of cwnd. The following is the algorithm of Vegas: If (d < alpha) then cwnd = cwnd + 1 AI If (d > beta) then cwnd = cwnd 1 AD if (alpha< d < beta) No change in cwnd equilibrium point 3 TCP VENO Veno [4][8][9]is hybrid TCP variant i.e. it is the mechanism of delay and loss based. It combines the proactive nature of Vegas and reactive nature of Reno. Veno was proposed to eliminate TCP performance suffering from wireless links. Since in wireless network there may be multiple reasons [10] for packet loss rather than congestion. Veno uses the same logic as that of Vegas to estimate the state of the connection. If packet loss is detected while the connection is in the congestive state, Veno assumes the loss is due to congestion; otherwise, it assumes the loss is random. TCP Veno [11] makes use of the state distinguishing scheme from TCP Vegas and integrates 3 449

4 it into congestion window evolution scheme of TCP Reno. In Vegas, the sender measures the so-called Expected and Actual rates: Expected = cwnd / Base Round Trip Time (RTT) Actual = cwnd / RTT Where cwnd is the current congestion window size, BaseRTT is the minimum of the measured round-trip time, and RTT is the smoothed round-trip time measured. The difference of the rate is : D = Expected - Actual When RTT > BaseRTT, there is a bottleneck link where the packets of the connection accumulate. Let the backlog at the queue be denoted by N. We have: RTT = BaseRTT + (N / Actual) Rearranging, we have: N = Actual (RTT BaseRTT) = D BaseRTT = (cwnd / BaseRTT cwnd / RTT) BaseRTT The main idea of Veno is to use the measurement of N as an indication of whether the network is in congestive state or noncongestive state. At any time, if N = beta, Veno deduces the link as in congestive state and considers the packet loss as congestion loss. Otherwise if N beta, the link is in non-congestive state and the packet loss is a random loss. Here beta is normally set to be 3. Based on the differentiated state, Veno applies different algorithms to Renos additive increase (AI) and multiplicative decrease (MD) phases, thus makes cwnd evolution more efficient. In AI phase, IF (N<beta) THEN set cwnd = cwnd + 1 //cwnd for every new acknowledge (ACK) ELSE IF (N >= beta) THEN set cwnd = cwnd +1 //cwnd for every other new ACK In MD phase, 1. Retransmit the missing packet, and IF (N<beta) THEN set Slow Start Threshold (ssthresh) = cwnd 4/

5 ELSE IF (N >= beta) THEN set ssthresh = cwnd Each time another dup ACK arrives, increment cwnd by one packet. 3. When the next ACK acknowledging new data arrives, set cwnd to ssthresh (value in step 1). 4 PROBLEM WITH VEGAS AND VENO In both Vegas and Veno the variables, alpha and beta are constant. These variables are responsible for the increment of cwnd. As they are set constant, they restrict the further growth of cwnd even if the network is not fully occupied. Thus their throughput decreases. If we make this variable dynamic then they will not limit the cwnd size if the network is not fully occupied. Veno in congestion avoidance stage checks if N is greater than beta (which is constant); then increases window by 1 every other RTT, making it less aggressive. Thus even if there is scope to increase cwnd per RTT, it doesnt allow it. Vegas-A suggests a modification of alpha and beta variables and makes it dynamic and it was proposed for Vegas. Hence we tried to use it with Veno with some modification as Veno is a combination of both Vegas and Reno. In wired network TCP performance enhanced by modifying TCP NewReno[12]. We have kept Renos part as it is, and has changed only its congestion avoidance phase (specifically in AI phase). Original Veno does not use variable alpha, but the modification in Vegas used it for deciding when to switch to Slow Start from Congestion Avoidance (RFC 2582)[13]. 5 VENO-A Veno-A (VEno-A+reNO) makes the alpha and beta variable dynamic so that it does not restrict the increment of a window. Veno- A keeps the Slow Start and Multiplicative Decrease phase same as Veno[7][14]. The following is the modification done in Additive Increase phase. Original Venos Algorithm: 5 451

6 if (N < beta) then cwnd = cwnd + 1 //every RTT else if (N >= beta) then cwnd = cwnd + 1 //every other RTT Proposed Algorithm (Veno-A): Initialize alpha = 2 & beta = 4 Case 1: N in between alpha and beta Its time to increase the limitation of beta (making alpha and beta dynamic) if current rate increases. if (beta>n && N>alpha) cwnd ++; //every RTT if (current rate > prev rate) alpha++; beta++; Case 2: N is below alpha Its time to be more aggressive hence enters in slow start phase. elseif (N < alpha) slowstart(); Case 3: N goes above beta Its time to be lenient hence increase cwnd every second RTT and also decrease the value of alpha and beta. elseif (N > beta) if (alpha>1) alpha ; beta ; cwnd ++; //every other RTT Once packet is lost it behaves same as Veno. 6 SIMULATION OVER A HYBRID NET- WORK (WIRED-CUM-WIRELESS NETWORK) To check the effect of the modification done in Veno, we have simulated it in NS-2. For Simulation purpose, we have used Agent/TCP/Linux/ from NS-2 and selected Vegas and Veno in-built code for comparison and modification. The sample network is shown in fig

7 Fig. 1: Wired-Cum-Wireless Network The sample network consists of two wireless nodes (client 1 and client 2), one access point and one wired node (server). Client 1 and client 2 are mobile and are registered with an access point. Client 1 starts sending packets at time 10 and client 2 sends at 20 and eventually both stops at 100. A link between AP and server is of 5Mbps and that of wireless is 10Mbps. A link delay of the wired link is 50ms. After applying Vegas, Veno and Veno-A, we received results shown in fig.2. Fig. 2: CWND vs Time The above graph is plotted using Xgraph where Veno1 (Veno-A) is our proposed algorithm. As there are two flows we can see two variations in cwnd for each algorithm. Table 1 shows the average congestion window size of Vegas, Veno, and Veno-A and their comparison: TABLE 1: AVERAGE CWND SIZE 7 453

8 Table 2 gives the total data sent using Vegas, Veno, and Veno-A and compares them: TABLE 2: TOTAL DATA SENT Table 3 compares the throughput achieved by Vegas, Veno, and Veno-A and compares them: TABLE 3: THROUGHPUT COMPARISON The fig. 3 shows a graph comparing Vegas, Veno, and Veno-As throughput versus link delay: Fig. 3: Throughput vs Link delay 8 454

9 The given Table 4 compares the throughput achieved by Vegas, Veno, and Veno-A for a network having different link delay. From these results, we make a conclusion that Veno-A gives better results than Veno and Vegas. Fig.8. Von Mises graph for Bi-Morph structure 7 CONCLUSIONS In this paper, we have modified Veno by making beta variable dynamic and the modified Veno is named as Veno-A, where A stands for adaptive. Thus if difference increases, the beta also increases if the current rate has increased than its previous value. As a result, the difference does not go above beta and cwnd increases with every RTT and not with every other RTT. In Veno-A, we have introduced Vegas variable alpha. Whenever a difference is below alpha, Slow Start procedure is called where it becomes more aggressive. If in case difference goes above beta, cwnd increases every other RTT and checks if alpha is above its default value then both alpha and beta are decreased. Simulation results show that the performance of Veno-A is better than original Vegas and Veno. Veno-A not only performs well in hybrid but also has given better results in wired and wireless networks. But for a network with very less link delay Veno-As throughput is as close as Veno, in fact, is less than Veno. So as link delay increases Veno-A gives much better result than Original Veno. References [1] Van Jacobson, Aug, 1988, Congestion Avoidance and Control SIGCOMM 88, ACM

10 [2] Alexander Afanasyev, Neil Tilley, Peter Reiher, and Leonard Kleinrock Host to Host Congestion Control for TCP. IEEE Communications survey & tutorials, Vol.12 No.3. third quarter. [3] Ghassan A. Abed, Mahamod Ismail and Kasmiran Jumari A survey on the performance of Congestion Control Mechanisms for standard TCP version, Australian Journal of Basic and Applied Science, 5(12) : [4] Cheng-Yeun Ho, Yaw-Chung Chen, Yi-Cheng Chan, Cheng- Yun Ho,2008, Fast retransmit and Fast recovery schemes of transport protocols: A survey and taxonomy, Elsevier ScienceDirect, computer network 52, [5] M. Allman, V. Paxson and W. Stevens, April 1999, TCP Congestion Control, RFC [6] Mrs. Reena Rai and Dr. Maneesh Shreevastava, Performance Improvement of TCP by TCP Reno and SACK Acknowledgement. [7] K.N. Srijith, LillyKutty Jacob, A.L. Ananda, TCP Vegas-A: Improving the Performance of TCP Vegas. [8] Bin Zhou, Cheng Peng Fu, Dah-Ming Chiu, Chiew Tong Lau, and Lek Heng Ngoh, A simple throughput model for TCP Veno. [9] Chengpeng Fu and Soung C. Liew. 2003, TCP Veno: TCP Enhancement for Transmission over Wireless Access Networks, IEEE Journal on selected areas in communications, Vol. 21, No. 2. [10] Ye Tian, Kai Xu, And Nirwan Ansari, 2005, TCP in Wireless Environments: Problem and solutions, IEEE Radio Communication, Volume 43 Issue 3. [11] Jacobson, V., April 30, 1990, Modified TCP Congestion Avoidance Algorithm, end2end-interest mailing list

11 [12] S.S.Pawale, S.J.Wagh, R.S. Jadhav, Dec.2017, An efficient congestion control methodology to enhance the performance of TCP in wired network. [13] Floyd and T. Henderson, April 1999, The NewReno Modification to TCPs Fast Recovery Algorithm, RFC [14] Yi-Cheng Chan, Chia-Liang Lin, Chia-Tai Chan, Cheng-Yuan Ho, 2010, Code TCP: A competitive delay-based TCP

12 458