A COMPARATIVE STUDY OF TCP RENO AND TCP VEGAS IN A DIFFERENTIATED SERVICES NETWORK

Transcription

1 A COMPARATIVE STUDY OF TCP RENO AND TCP VEGAS IN A DIFFERENTIATED SERVICES NETWORK Ruy de Oliveira Federal Technical School of Mato Grosso Brazil Gerência de Eletroeletrônica ruy@lrc.feelt.ufu.br Paulo Roberto Guardieiro Federal University of Uberlândia Brazil Faculty of Electrical Engineering guardieiro@lrc.feelt.ufu.br Abstract In this paper, we present some simulation results carried out to study the behavior of the Differentiated Services architecture (DiffServ) together with TCP Vegas algorithm in relation to TCP Reno algorithm. We focus on the evaluation of the impact α and β parameters in TCP Vegas and RIO parameters have on fairness in this environment. In particular, this paper examines the feasibly of some values not yet used for adjusting α and β, in a DiffServ network. The results show that much of conclusions concerning TCP Vegas achieved in previous researches, in which only a traditional network was examined, are found in a DiffServ domain too. Besides, they show that the studied parameters are able to minimize the unfairness of TCP Vegas in that environment in some extent, but improvements are still fundamental. I. INTRODUCTION Nowadays, DiffServ architecture [3] has raised as one of most important technology for provisioning Quality of Service (QoS) in the Internet. It maintains the complexity of flow control at the network border and so provides scalability in this scenario. Besides, as this approach is relatively recent, a lot of researches related to it have been published lately [6,7]. But up to now all the ones have concentrate on TCP Reno as congestion control mechanism at the hosts. So, we emphasize in this paper the open issue relative to operation of DiffServ together with TCP Vegas algorithm [9,10,11]. Inside the DiffServ network, congestion control is performed by RIO (RED with IN and Out) algorithm [7], while at the hosts this control is performed by TCP algorithm [1]. Then, the whole congestion control in this environment depends on the interoperation between these both algorithms. TCP Reno represents the most known congestion control mechanism for the IP networks employed nowadays. Despite its large use, this mechanism does not use the network bandwidth effectively, since it induces losses inside the network for detecting congestion. New TCP algorithms have been proposed to improve this utilization. Among them TCP Vegas appears as a promising one. The developers of TCP Vegas have reported that it achieves between 40% and 70% better throughput than TCP Reno does and causes much fewer packet retransmissions [10]. In spite of its higher performance, with regard to the bandwidth utilization, it has been established by previous researches that it raises fairness issues. TCP Vegas relies on two important parameters labeled α and β. In the studies presented in [5,13] the authors have concluded that adequate fairness among connections sharing the network bandwidth can be gotten by making α=β. Besides, in [8,12] researches have shown that suitable adjustment to the parameters of Random Early Detection (RED) algorithm can also minimize the unfairness of TCP Vegas. Therefore, since DiffServ architecture is based on RED algorithm, as part of RIO, it is expected that the same influence observed in such researches can also occur in a DiffServ environment. In this way, as said before, we examine in this paper the impact of RIO parameters as well as α and β parameters on fairness of a DiffServ network, taking into account those previous results. Although RIO has two REDs, one for inprofile packets and another for out-of-profile packets, in this work we limit the analysis to the parameters of the RED associated with out-of-profile packets. The parameters of the RED related to in-profile packets are kept constant. Concerning α and β parameters, they are studied considering the cases where α<β and α=β are used. Based on previous researches that have concluded that α=β case provides a better fairness, we emphasize in this work the exam of this case. So, three sets of values for RIO parameters (relative to out-of-profile packets) and four sets for α and β parameters, one referring to α<β setting and three others referring to α=β setting, are studied. Thus, this study presents an analysis towards practical values to be employed in future implementations of TCP Vegas in a DiffServ environment and most probably these values will also perform well in a traditional IP network using RED. The simulations presented in this paper concentrate on DiffServ AF service class [3,7] that allows the usage of all available network bandwidth dynamically. This paper is organized as follows. In section II, we briefly review some important concepts of TCP Reno, TCP Vegas and DiffServ so as to provide a necessary background to this work. Next, we present the network model that was employed in the simulations and its associated configuration in section III. Section IV is devoted to present the simulation results. Finally, in section V, we make some concluding remarks.

2 II. OVERVIEW OF TCP AND DIFFSERV This section gives a briefly insight into some important features of both TCP algorithms mentioned and also into DiffServ architecture. More details can be met in [1,2,3,10]. A. TCP Reno and TCP Vegas We explain here only the main difference between TCP Reno and TCP Vegas, which refers to their manner of operating in Congestion Avoidance phase. More details on both can easily be found in the literature, like [10,11] among many others. In order to detect congestion inside the network, TCP Reno sender continually expands CWND until it receives a signaling that a segment has been lost. The way CWND is increased, in that phase, at time t+t is given by equation 1. 1 CWND ( t + t ) = CWND( t) + (1) CWND( t) Differently from TCP Reno, TCP Vegas detects network congestion by monitoring the changes in RTTs of the segments that have been sent previously by the connection. Thus, if observed RTTs increase, TCP Vegas recognizes incipient network congestion so it decreases congestion window (CWND) by one. Otherwise, if observed RTTs diminish TCP Vegas infers that network is relieved from congestion and accordingly it increases CWND by one. There is a range in which CWND remains unchanged. The extension of this range is determined by α and β parameters, as shown in equation 2 [5]. CWND ( t CWND ( t ) + 1, if t ) = CWND ( t ) 1, if Unchanged, if + α Diff < ; β < Diff ; α Diff base rtt Diff = CWND ( t ) / CWND ( t) / rtt β base rtt Where rtt means the measured RTT, base_rtt is the smallest value of observed RTTs and α and β parameters are minimum and maximum thresholds, respectively, for the admitted range on RTT variation without changes in CWND. While variations in observed RTTs are between α and β (divided by base_rtt), TCP Vegas infers that the network is not under danger of congestion. Then, it maintains CWND unchanged to prevent losses inside the network. The key idea here is to use all the available network bandwidth, but without causing excess traffic inside the network. B. DiffServ network This architecture [3] is largely intended to provide bandwidth assurance for the end-users according to their respective services specification. It provides two new service classes: Expedited Forwarding (EF) and Assured Forwarding (AF). The former is designed for real-time traffic while the latter is for non-real-time traffic that needs minimum bandwidth guarantee and possibility of making use of leftover resources. (2) DiffServ networks employ border routers that provide full functionality over the traffic entering the network, including classification, policing and shaping. As a result, the core network routers are simplified since they only need to forward packets based on their respective PHBs (Per Hop Behaviors), that indicate the service class of packets and are identified by the value of DS field in the packets header. Within DiffServ network RIO algorithm performs the congestion control. At the edge routers there are traffic profiles for end-users so that a flow is marked in-profile when it does not exceed the contracted target rate and out-ofprofile otherwise. The RIO algorithm owns two RED algorithms, one for in-profile packets and another for out-ofprofile packets. In times of congestion, out-of-profile packets are dropped first, since the network commits to deliver inprofile packets only. III. SIMULATION ENVIRONMENT The simulations were performed using the well-known NS network simulator. The simulated network model is that depicted in fig. 1, where there are two sources (S1, S2) sending data to two destinations (D1, D2, respectively), two border router connected by a DiffServ link (RIO queue) and four simple links (FIFO) connecting the end-hosts to routers. S1 S2 Sources Connection 1 - X Mbps 10 Mbps R R 10 Mbps 1 ms 1 ms Fig. 1 Network model. Connection 2 - Y Mbps Destinations This scenario defines two connections, one between S1-D1 and another between S2-D2, connection 1 and 2, respectively. Both capacity and delay for each link as well as the target rate of each connection are shown in fig. 1. X represents the target rate of connection associated to S1 and Y the same for S2. Their values can vary from one simulation to another. The sources generate infinite FTP traffic so that only the adjusting in the conditioner at the network boundary imposes the target rate of connections. The analyzed RIO parameters are those shown in table 1. Note that while the threshold parameters for in-profile packets are maintained unchanged, the ones for out-of-profile packets vary within the shown limits. This procedure was followed to make viable this study. Analogously, the values analyzed for α and β parameters in TCP Vegas were restricted as well. Table 1 RIO parameters in-profile Out-of-profile Min th (packets) 20 3/5/7 Max th (packets) 40 6/10/14 Max p 0,02 0,1 The set of values used for Min th and Max th relative to RED associated to out-of-profile packets, and called here REDO, are REDO:3-6, REDO:5-10 and REDO:7-14, according to table 1. In the same way, four sets of values for α and β D 1 D 2

3 parameters are studied: α=1 and β=3, α=β=1, α=β=2 and α=β=3. IV. SIMULATION RESULTS It is presented in this section the main results obtained from the combined values of studied parameters. This analysis concentrates on fairness ability in that environment with regards to proportional bandwidth sharing. Since TCP Reno has already proved proper in providing good fairness for the scenario here studied, we focus on TCP Vegas solely and on its interoperation with TCP Reno. A. Influence of α and β parameters In simulations shown in this sub-section, REDO parameters were maintained constant making it possible the analysis of α and β parameters only. Each connection on the network model (fig. 1) has a target rate of 1 Mbps and sources are TCP Vegas. S1 starts working at time t=0 seconds and S2 at t=5 seconds. To facilitate the view of the extent of results, simulation duration of 30 and 100 seconds were employed. In this way, four simulations were performed, in which the REDO:3-6 setting and the four sets of values for α and β parameters, mentioned before, were analyzed. Because of the limited space only the results from α=1 and β=3 and α=β=2 scenarios are presented in figs. 2 and 3, respectively. increase in RTT1) and CWND2 to reach 4 segments. After then, both RTTs stabilize around 18 ms and, consequently, TCP Vegas algorithm infers that there is no congestion inside the network so it stops altering CWND size. The reason why connection 2 in fig. 2a achieves more bandwidth than connection 1 can be explained recalling the way TCP Vegas works. At the moment a TCP Vegas sender begins transmitting, it measures the RTT of first segment sent to determine whether its CWND can be increased or not. So, since the instant connection 2 joins the network, only S1 is transmitting, the value of the RTT evaluated for connection 2 must be close to the one measured for connection 1 (figs. 2c and 2d). Thus, S2 starts transmitting and the more it injects data into the network the more both RTTs increase. As a result, TCP Vegas algorithm decreases CWND1 causing decline in flow rate of connection 1. This tends to carry on until both connections reach the equilibrium around t=6.7 seconds. Afterwards, TCP Vegas algorithm infers that the CWND of connections must maintain unchanged (because of their stable RTTs) resulting in the unfairness problem mentioned before. Therefore, under this condition the original TCP Vegas algorithm, with α=1 and β=3 setting, does not provide adequate fairness between the connections in this network. In [5,13] it has been emphasized that TCP Vegas can provide a good fairness in a traditional network (based on BE service) by using α=β setting. So, we simulated three sets of values considering α=β in order to evaluate the efficiency of this approach in a DiffServ network. Fig. 3 exhibits the results from α=β=2 case. It can be seen by fig. 3a that in this case both connections competed for bandwidth in a fair way. Comparing these results with the ones presented in fig 2, we can observe that the main difference between them is that in fig. 3 the CWND of connections continuously oscillate due to the variation in their respective RTTs. Fig. 2 TCP Vegas with α=1 and β=3: a) Bandwidth achieved by the connections b) Congestion window of connections c) Round Trip Times d) Zoom in on RTTs around the instant S2 starts The result depicted in fig. 2a shows that connections 1 and 2 did not receive equal bandwidth from the network like would occur with TCP Reno. This result complies with the ones presented in [5], in which it has been shown that this unfairness problem occurs due to the fact that with α<β the CWND of connections keep stable (fig. 2b, after t=6.7 seconds). As a result, the connections get different bandwidth from each other. It happens because the RTT of connections only suffer variation at the time of the sources begin transmitting. Accordingly, figs. 2c and 2d show that as connection 2 joins the network (t=5 seconds) the RTT of both connections begin oscillating and so continue until around t=6.7 seconds. It causes CWND1 size to decrease to 3 segments (due to the Fig. 3 TCP Vegas with α=2 and β=2: a) Bandwidth achieved by the connections b) Congestion window of connections c) Round Trip Times d) Zoom in on RTTs around the instant S2 starts In fact, the RTT of connections vary constantly because the usage of α=β setting makes equation 2 becomes equation 3.

4 Where it can be seen that since Diff (α=β)/base_rtt, CWND must change at each ACK received by TCP Vegas sender. CWND ( t CWND ( t ) + 1, if t ) = CWND ( t ) 1, if Unchanged, if + Diff < ; < Diff ; Diff = ; Thus, these results confirm that, like [5,13] without DiffServ, the usage of α=β setting is essential in getting fairness among connections in a DiffServ network too. The analysis of α=β=1 case reveled that this setting was not enough to cause oscillation in the RTT of connections. As a result, it could not provide fairness between connections 1 and 2. Concerning α=β=3 case, even though it has provided good fairness between the connections, it caused a higher level of oscillation in RTTs and, consequently, in CWNDs, which made the network to become much unstable. Therefore, the best setting seems to be α=β=2 indeed. B. Influence of RIO parameters In this sub-section the goal is specifically to examine the impact of REDO parameters on bandwidth sharing. Like before, both connections have a target rate of 1 Mbps and the sources are TCP Vegas sources. In this case, however, α and β parameters values were fixed at α=β=2 and the other two sets of values studied for REDO parameters (REDO:5-10 and 7-14) were simulated. The results show that for both cases the network performance was exactly the same. Fig. 4 presents the ones, where it can be seen that bandwidth is not divided in a fair way. Fig. 4 TCP Vegas with REDO: 5-10, 7-14 and α=β=2: a) Bandwidth b) RTT Fig. 4b reveals that the RTT of connections 1 and 2 does not vary after the transitory imposed by the start of connection 2 (between t=5 and t=5.4 seconds interval). It happens due to the fact that the higher are REDO setting values the larger is the amount of traffic inside the network, once fewer segments are dropped in this situation. As a result, the queuing delay experienced by each packet increases and so the RTTs of connections 1 and 2, which are larger than the values achieved with REDO:3-6 setting presented before. In this way, the results suggest that DiffServ network can only provide adequate fairness for its end-users, considering the scenario here studied, if extremely small values for REDO parameters and α=β=2 setting are used. (3) C. Connections with different target rates In this sub-section we analyze not only the situation in which the network is over-provisioned but also that one in which it is under-provisioned. Both sources are TCP Vegas and their connections have different target rates. Connection 1 has a fixed target rate of 1 Mbps while connection 2 has a variable target from 1 to 3 Mbps (Y Mbps), as shown in fig. 5. The α=β=2 and REDO: 3-6 settings were used and each simulation run lasted 100 seconds. Fig. 5 Capacity of TCP Vegas in distributing bandwidth in a proportional way. It is noticed by Fig. 5 that before the network starts becoming under-provisioned (Y=2 Mbps), both connections get their respective target rate. After then, connection 1, that starts first, maintains its target (1 Mbps) whereas connection 2 cannot get more than 2 Mbps, in spite of its target rate that continues increasing up to 3 Mbps. Such a behavior is related to the fact that at any vestige of congestion into the network, TCP Vegas algorithm causes both connections to reduce its sending rate (by reducing their CWNDs) in order to avoid effective congestion. When the target of connection 2 goes beyond the rate of 2 Mbps, it tends to cause congestion inside the network that is detected by a relevant increase in its measured RTTs. It makes the connection to diminish its CWND, leading RTT of both connections to a stable state so their achieved bandwidth. The disadvantage of such an intrinsic feature of TCP Vegas in a DiffServ environment refers to its impossibility of providing proportional share of bandwidth for the end-users, according to their respective contracted services. D. TCP Vegas and TCP Reno In this sub-section, we deal with the interoperation of TCP Vegas and TCP Reno algorithms. Two sets of simulations were employed for this analysis. In the first one, depicted in fig. 6, sources S1 and S2 are TCP Reno and TCP Vegas sources, respectively. Both sources start transmitting simultaneously at time t=0 second and their connections have a target rate of 2 Mbps each one, which indicates the network is under-provisioned. It was maintained α=β=2 value for S2 (Vegas) and the three sets of values for REDO parameters were considered, as shown in fig. 6. Simulations run lasted 100 seconds. The results show that only REDO:3-6 setting provided equal bandwidth for connections 1 and 2 (same average bandwidth). In addition, they indicate that the higher the REDO setting the more TCP Reno surpasses TCP Vegas. This happens because decreasing the REDO setting so does the amount of out-of-profile packets inside the network.

5 Fig. 6 Effect of REDO parameters on TCP Reno and TCP Vegas traffics: a).redo:3-6 b) REDO:5-10 c) REDO:7-14 Then, since such packets are mainly generated by TCP Reno connection, due to its property of increasing CWND continuously until losses happen within the network, its aggressiveness against TCP Vegas connections is reduced. Consequently, the fairness in this environment is improved. For the over-provisioned case, similar results were obtained. In the second set of simulations, illustrated in fig. 7, the purpose was to evaluate how much the aggressiveness of TCP Reno can impacts the capacity of TCP Vegas on getting the bandwidth requested by the end-users. Two groups of simulations were performed. In the first one, the target rate of connection 1 (Reno) was fixed at 1 Mbps while the target rate of connection 2 was varied from 1 to 3 Mbps (Y Mbps). In the second group, the situation was inverted, as indicated in fig. 7. Both sources begin transmitting at t=0 second. Analogously to the previous sub-section, the α=β=2 and REDO:3-6 settings were adopted, and also the same simulation duration of 100 seconds was used for each run. Fig. 7 Comparison between TCP Reno and TCP Vegas in terms of bandwidth guarantees: a) Target rate of TCP Reno connection fixed at 1 Mbps b) Target rate of TCP Vegas connection fixed at 1 Mbps In fig. 7 it is shown that the aggressiveness of TCP Reno makes it outperforms TCP Vegas. By fig. 7a it is noticed that although connection 1 (Vegas) has a crescent target rate competing against connection 2 (Reno), which has a target fixed at 1 Mbps, that does not achieve any growth in its achieved bandwidth beyond the rate of 2 Mbps. On the other hand, in the situation depicted in fig. 7b, connection 1 (Reno) manages progressive increase in its achieved bandwidth, causing degrading to connection 2. V. CONCLUSIONS This study has extended some results gotten in earlier researches concerning TCP Vegas, such as α, β and RED influence on fairness capacity of TCP Vegas, to a DiffServ environment. The results here obtained imply that in a DiffServ environment it is essential to use α=β setting for TCP Vegas algorithm, as well as extremely small values for the RED associated with out-of-profile packets of RIO algorithm (REDO). It causes continuing oscillations in the CWND of connections so provides reasonable fairness in this scenario, although there is no proportionality under congestion. Furthermore, in this case, the stable property of TCP Vegas is lost and it tends to behavior like TCP Reno. Those procedures also minimize the aggressiveness of TCP Reno against TCP Vegas in some extend, but in general the former surpasses the latter. Concerning α and β parameters, the α=β=2 adjustment seems to be the best value to be implemented, since higher values cause increased instability inside the network. In summary, we conclude that the fairness feasibility of TCP Vegas in a DiffServ environment, in relation to TCP Reno, is highly dependent on improvements. In this way, we suggest for future works the analysis of the Explicit Congestion Notification (ECN) mechanism, according to which has been proposed in [7], as an attempt to enhance the fairness of TCP Vegas in a DiffServ network. We also suggest for future researches the study of different scenarios, for instance one with a larger number of sources. REFERENCES [1] M. Allman, V. Paxson, and W. Stevens, TCP Congestion Control, RFC 2581, April [2] K. Nichols, A Two-bit Differentiated Services Architecture for the Internet, RFC 2638, July [3] S. Blake et al., An Architecture for Differentiated Services, IETF RFC 2475, December [4] S. Floyd, and V. Jacobson, Random Early Detection Gateways for Congestion Avoidance, IEEE/ACM Transactions on Networking, 1(4): , July [5] G. Hasegawa, M. Murata, and H. Miyahara, Fairness and Stability of Congestion Control Mechanisms of TCP, in Proceedings of INFOCOM 99, pp , March [6] F. Baumgartner, T. Braun, and C. Siebel, Fairness of Assured Service. [7] W. Fang, TCP mechanisms for DiffServ Architecture. [8] J. Mo, et al., Analysis and Comparison of TCP Reno and Vegas, in Proceedings of INFOCOM 99, pp , March [9] L. Peterson, and L. Wang, Understanding TCP Vegas: Theory and Practice. [10] L. S. Brakmo, S. W. O Malley, and L. Peterson, TCP Vegas: New Techniques for Congestion Detection and Avoidance, in Proceedings of ACM SIGCOMM 94, pp , London, October [11] U. Hengartner, J. Bolliger, and T. Gross, TCP Vegas Revisited. [12] A. M. Raghavendra, and R. E. Kinicki, A Simulation Performance Study of TCP Vegas and Random Early Detection, in Proceedings of 18 th Int. Performance Computing communications Conference, pp , [13] C. Boutremans, and J. Boudec, A Note on the fairness of TCP Vegas, in Proceedings of International Zurich Seminar on Broadband Communications, pp , Zurich, Switzerland, February 2000.