‘Abnraci— We propose some improvements of TCP Vegas an compare ss peeformance characterises wit TCP Rene, We argue trough aa that TCP Vegas th He better bandwidth eotimaton scheme wes the rework resurees more eficiesty and fy than TCP Reno. Simulation ‘sul are given hat support the resus af the aalsis. Kowords—TCP Reno, TCP Vegas, Congestion Control Fairness 1. Intropucrion Followinga series of congestion collapses starting in October of "86, Jacobson and Karels developed a congestion control ‘mechanism, which was later named TCP Tahoe [9]. Since then, ‘many modifications have been made tothe transmission control ‘protocol (TCP) and several different versions of TCP have been implemented [9] (10). Recently Brakmo ctal{2] have proposed a new version of ‘TCP, whichis named TCP Vegas, with a fundamentally different congestion avoidance scheme from that of TCP Reno (4.3BSD) and claimed that TCP Vegas achieves 37 t0 71 percent higher throughput than TCP Reno, Albn et al.[1} have evaluated the per- formance of TCP Vegas on their wide area emulator and shown, that TCP Vegas does achieve higher efficiency than TCP Reno and causes much fewer packet retransmissions. However, they have observed that TCP Vegas, when competing with other TCP Reno connections, does not receive a fair share of bandwidth Floyd has observed that TCP Reno is biased against the con- nections with longer delays (5) (7] . The intuition behind this behavior is as follows. While a source does not detect any con- gestion, it continues to increase its window size by one during ‘one round trip time. Obviously connections witha shorter de- lay can update their window sizes faster than those with longer delays, and thus capture higher bandwidths. Based on this ob- servation, Floyd and Jacobson [6] have proposed a constant rate ‘adjustmentalgorithm. Henderson et a8] have simulated a vari- tion ofthis scheme and reported that ifthe rate of increase of, the window size is not excessive, this scheme isnot harmful 10 the other connections that use a diferent version of TCP. More- ‘over, as expected, this scheme results in better performance for the connections with longer delays. However, choosing the pa sameters for such algorithms is stil an open problem. Mo and ‘Walrand (15) have demonstrated the existence of fair end-to-end ‘window-based congestion contre protocols and proposed an al- gorithm similar to TCP Vegas, for which convergence results are proved. In this paper we explain the performance characteristics of| ‘TCP Vegas in relation to its queve-based control mechanisins; we demonstrate through both analysis and simulations that TCP ‘Vegas does not suffer from delay bias as TCP Reno does. We 0-7808-5417-6/99/610.00 ©1999 IEEE. show the incompatibility of TCP Reno and TCP Vegas. The rest of the paper is organized as follows. In section 2 we describe the congestion detection and avoidance schemes of TCP Reno and TCP Vegas, Section 3 presents a few problems intrinsic in the original TCP Vegas and explains a possible solution to them. In soction 4 we discuss the faimess of TCP Vegas using a simple closed fluid model. Section $ compares TCP Vegas with "TCP Reno and explains the incompatibility between them. We confirm our analysis with simulation results in section 6, and finish with some conclusions and future problems, TL, ConGESTION AVOIDANCE MECHANISM In order to make efficient use of network bandwidth, TCP controls its flow rate using the feedback from the network. In ‘order to contolits flow rat, TCP needs to estimate the available ‘bandwidth inthe network using a bandwidth estimation scheme. ‘Among many new features implemented in TCP Vegas, the most ‘important difference between TCP Vegas and TCP Reno lies in this bandwidth estimation scheme used to estimate the avail- able bandwidth. As will be shown shortly, TCP Reno views packet losses asa signal of network congestion, while TCP Ve- {25 uses the difference in the expected and actual rates to adjust its window size. This fundamental difference in the bandwidth estimation schemes enables TCP Vegas to utilize the available ‘bandwidth more efficiently A. TCP Reno ‘TCP Reno induces packet losses to estimate the available bandwidth in the network. While there are no packet losses, ‘TCP Reno continues to increase its window size by one during each round tip time. When it experiences a packet loss, it reduces its window size to one half ofthe current window size. ‘This iscalled additive increase and multiplicative decrease, The additive increase and multiplicative decrease algorithm is based fn the results given in [3]. There itis shown that such an Algorithm leads to a fair allocation of bandwidth. TCP Reno, however, fils to achieve such fairness because TCP is not & synchronized rate based control scheme, which is necessary for the convergence results of (3), ‘The congestion avoidance mechanism adopted by TCP Reno causes a periodic oscillation inthe window size duc tothe con- stant update of the window size. This oscillation in the window ‘size leads to an oscillation inthe round trip delay ofthe packets Ths oscillation results in larger delay iter and an inefficient use of the available bandwidth due to many retransmissions of the same packets ater packet drops occur. 1556B, TCP Vegas ‘TCP Vegas adopts a more sophisticated bandwidth estimation scheme, Ttuses the difference between expected and actual ows rates {0 estimate the avzilable bandwidth in the network. The ‘dea is that when the network is not congested, the actual flow ‘ate will beclose tothe expected flow rate. Otherwise, the actual flow rate wll be smaller than the expected flow rate. TCP Vegas, using this ference inflow rate, estimates the congestion level in the network and updates the window size accordingly. Note that 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, using the equation Diff = (Bzpected ~ Actual) BaseRTT, © ‘where Expected isthe expected rate, Actual isthe actual rate, ‘and BaseRTT is the minimum roundtrip time. The details ofthe algorithm ae a follows: 1. Fst, the source computes the expected flow rate Expected = 22 Pr, where CWND is the current window size and BaseRTT is the minimum round tip time 2, Second, the source estimates the current flow rte by using the actual round trip time according to Actual = SUP, where RTT is the actual roundtrip time of packet. 3, The source, using the expected and actual flow rates, computes the estimated backlog in the queue from Diff = (Expected-Actual) BaseRTT. 4. Based on Dif, the source updates its window size as fol- lows. if Diff 8 otherwise cwnp cwND-1 cwNnD41 cwnD a Fg. Window contol of TCP Vezns igure 1 illustrates the behavior of TCP Vegas. Consider imple network with one connection and one link with ca pacity C. Let BareRTT be the minimum round wip delay. The throughputofthisconnectionis 248, when window < C'x BaseRTT. Inthe gue, w corresponds tothe window size where window = C x Base RTT. When window > w, aqueve starts to build up and (Expected - Actual) > 0. TEP Vegas in the window size by one during the next roundtrip time if win- dow < w + a and decreases the window size by on if window > w+, Otherwise it eaves the window size unchanged. In the figure, Diffis user i's estimated backlogged queve size in the Link. "This will be explained in more details in section 3, ‘TCP Vegas tries to keep a least a packets but no more than ° packets inthe queues. The reason behind this is that TCP Vegas attempts to detect and utilize the extra bandwidth whenever it becomes available without congesting the network. Thus, when there is only one connection, the window size of TCP Vegas converges to point that lies between w + a and w+ 8. Note that this mechanism is fundamentally different from that used by ‘TCP Reno. TCP Reno always updates its window size to guar- antee full utilization of available bandwidth, leading to constant packet losses, whereas TCP Vegas does not cause any oscillation Jn window size once it converges to an equilibrium point. MI, TCP Vecas ‘TCP Vegas has a few problems that have not been discussed before, which could have a serious impact on its performance. (One of the problems isthe issue of rerouting. Since TCP Vegas uses an estimate ofthe propagation delay, baseRTT, to adjust its ‘window size, i is very important for a TCP Vegas connection to have an accurate estimate ofthis quantity. Rerouting a path ‘may change the propagation delay of the connection, and this could result in a substantial decrease in throughput. Another ‘important issue isthe stability of TCP Vegas, Since each TCP ‘Vegas connection atempts to Keep afew packets in the network, when the estimation of the propagation delay is off, tis could lead the connections to inadvertently keep many more packets in the network, causing a persistent congestion. La er a.[13] have investigated these issues, We summarize the results here. For more details, refer to [13] A. Rerouting ‘TCP Vegas, as first suggested by Brakmo et al{2], does not hhaye any mechanism thet handles the rerouting of connection. In this section, we show that such a lack of mechanisms could lead to strange behavior for TCP Vegas connections. Recall that in TCP Vegas BaseRTT isthe smallest round wip delay, whic an estimate of the propagation delay ofthe path First, if the route of a connection is changed by a switch, then without an explicit signal from the switch, the end host cannot directly detect it, If the new route has a shorter propagation ‘delay, this does not cause any serious problem for TCP Vegas because most likely some packets will experience shorter round trip delay and BaseRTT will be updated. On the other band, if ‘the new route for the connection has a longer propagation delay, ‘the connection will not be able to tell whether the increase in the ‘ound rip delay is daeto acongestion in the network or achange inthe route, Without this knowledge the end host will interpret the increase in the round tip delay as a sign of congestion in the network and decrease the window size. This is, however, the ‘opposite of what the source should do. When the propagation delay of connection iis dy, the expected number of backlogged packets ofthe connection is wi — da, where wis connection 's window size and 1; is the flow rate. Since TCP Vegas attempts to keep between a and @ packets inthe switch butfers, ifthe propagation delay increases, then itshould increase the window size 10 keep the same numberof packets inthe buffer. Because 1587‘TCP Vegas relies upon delay estimation, the rerouting could impact the performance substantially. Since switches in the network do not notify the connections ‘of changes in routes it is required for sources ofthe connections tobe able to detoct such changes. La er a.{13] have suggested the following modification, For the first A packets, where J isa prefixed parameter, the modified protocol works the same way as TCP Vegas. After the ACK forthe Kth packet ative, the source keeps track of the minimum round tip delay of V consecutive packets. Ifthe minimum round trip time ofthe last EAN packets is much larger than the current baseRTT, the source updates baseRTT to the minimum round wip time ofthe last packets and resets the congestion window size based on thisnew baseRTT. ‘The basic idea behind this mechanism is as follows. If the ‘minimum round trip time computed for NV packets is consis- tently much higher than baseRTT, then itis likely thatthe actual Propagation delay is Targer than the measured baseRTT, and it makes sense to increase baseRTT. However, its possible thatthe increase is due to a persistent congestion in the network. This problem is briefly discussed in scetion II-B. Since the increase Indelay forces the source to decrease its window size, the round wip delay comes mostly from the propagation delay of the new route. Thus, the minimum round trip delay ofthe previous NV packets is a good estimate of the new propagation delay, as is >baseRTT for the previous route. The detiled description ofthe ‘mechanism is given in 13] with simulation results. 1B Persistent Congestion Since TCP Vegas uses baseRTT as an estimate ofthe propaga- tion éelay of route, its performance is sensitive to the accuracy of baseRTT. Therefore, the connections overestimate baseRTT duetoapersistent congestion, the overestimation can have asub- stantial impact on the performance of TCP Vegas. We consider 1 scenario where the connections overestimate the propagation {delays and possibly drive the system toa persistently congested ‘Suppose that a connection starts when there are many other ‘existing connections, the network is congested, and the queues are backed up. Then, due to the queuing delay from other backlogged packets, the packets from the new connection may ‘experience round trip delays tha are considerably larger than the actual propagation delay of the path. Hence, the new connection will set the window size to a value such that it believes that its ‘expected number of backlogged packets lies between a and 8, when in fact it has many more backlogged packets due to the inaccurate estimation of the propagation delay ofthe path. This scenario will repeat for each new connection, and itis possible that this causes the system to remain ina state of persistent con- gestion. This is exactly the opposite of what is desirable. When the network is congested, we do not want the new connections 10 ‘make the congestion level worse. This same situation may arse with TCP Reno or TCP Tahoe. However, itis more likely tohap: pen with TCP Vegas due to its fine-tuned congestion avoidance ‘mechanism, (Once RED gateways are widely deployed, this problem can be handled by the same mechanism suggested in section ILA. The inuition behind this solution is as follows. When the network stays in a persistently congested state, the connections interpret, the fasting increase in the round trip delay as an increase in the propagation delay and update their haseR7T. This creates a temporary increase in congestion level inthe network, and most connections, ifnotall, ack offas they detect the congestion. As connections reduce theit window sizes, the congestion level will, ‘come down, which allowsthe connections to estimate thecorrect baseR7T. Once most connections have an accurate measurement of the propagation delay, the congestion level will remain low. Since RED gateways drop packets independently, the synchro- nization effect will not be a big problem. For more details and simulation results, see [13]. IV. FAIRNESS OF TCP VEcAS ‘As we have mentioned before, TCP Reno is biased against the connections with long delays [5], [7], (14), In this section ‘we show that TCP Vegas does not suffer from this delay bias as ‘TCP Reno docs by analyzing a simple closed fuid model, and confirm the resulting analysis by simulation in section 6, We assume that the packets are infinitely divisible, ic, we use a ‘uid model, and the propagation delay is deterministic. ” at — Tw Oe . a | Fig 2. Newort with wo users Consider the simple network in Figure 2, There are two users with possibly different round tip delays, which share a single bottlensck link. User é has round trip delay dy and exercises window-based flow control. Without loss of generality we as sume thatthe capacity of the bottleneck Tink is normalized to Let gi(t) denote the user i's queue size at time £, o(t) (ai(t), 4208), and £(#) = D2, (0s which isthe total backlog a Gime t. Define (2) ~ ui(t)) + di, which denotes the round wip delay experienced by user i's packet whose ACK arrives al the souree at time f. We assume thatthe switch adopts the FIFO service discipline and has infnite buffer size. Sup- pose ei(t) denotes the rate at which connection i receives ACK, as shown in Figure 2, and the capacity is fully utilized, ie. ei(t = di) + ex(t — da) = 1, Users update their window sizes ‘once during each roundtrip time. ‘Since the window size is equal to the sum of the amount of| ‘uid in queve and in transit, a time ¢ we have wal) = a + [esa ® [Note thatthe second term on the right hand side is the amount ‘of fluid in ransitat time ¢. Each source computes the expected 1558backlog using the product of the propagation delay and the dif- ference between the expected flow rate and the actual flow rate ‘Thus, the estimated amount of backlogged fluid computed by gift Wl Srvc) Dit et) elsids, @ A heuristic argument for the convergence of window sizes after some time to to point such that osm) fi wilt) Jewry alee se “ isgivenin the Appendix. Now suppose that window sizes satisfy equation (4). If we substitute (2) in (4), we have aft i) ei(slds < 9. (3) wie) asat+ [ etsds— ‘Once the window sizes satisfy (4, the sources do nt change the ‘window sie. Suppose thatthe system is quasi-static and) is relatively constant. ‘The, the second and third terms in (5) cancel cach other out, andi yelde a 0, the amount by which users update their window sizes. Suppose (11, wa) = (wy(0),w3(0)). Let A= (wy +4m, wy + hn) |O< w, +4m) < whmacs OS a + 8g S WymaeyM1, 92 © Z}, where w1,mar and 13 mas ate the maximum congestion window sizes declared by the receives. Then, Ais the st of all possible window size pairs. If wimae nd w2ymee ae finite, then N' A [is finite, We will ist state a lemma that willbe used inthe proof of Theorem I. Suppose that the distance between the ay and fj lines is atleast 25, Lemma 1: No window size pair outside region (5) can be visited twice, Proof: Suppose that there exists a window size pair that could be visited twice outside region (5). Then, this implies that there exists a loop generated by window size updates as shown in Figure 7. We will now show that no such loop can exis In regions (1) through (6), user 2 never increases its window size, Hence, if user 2 updates in regions (1) through (3), then it is not possible to return to the same windows size pair since ‘we have assumed thatthe distance between a fine and line is larger than 6, Moreover, if wser 1 updates its window size in either region (1) or), then the previous window size pair cannot be revisited withoutreaching ether region (2) or(S) because user 1 does not update its window size in the opposite direction in the same region. However, once the window sizes reach a point in region (2) o (5), then for the same reason given above, it is not possible to return to the previous window size pair because 1562Faimess ig.7, Ancrample of op at most only user 2 will update its window size and decrease it ‘Therefore, iis not possible fora window size pair in region (1) through (3) to be visited more than once. By symmetry between users | and 2, itis not possible tohave such a Toop for a window size pairin region 3), (6) and Similarly, since user 2 does not decrease its window size in region (4) through (9), none of window size pairs in regions (7) through (9) can be visited twice. Again by symmetry, the same is tue for regions (1), (4, and (7). Therefore, none of the window ‘ize pairs outside region (5) can be visited more than once. Theorem 1: The window sizes converge to a point in region (6) within a finite amount of time, starting from a point in the ‘egion bounded by tae aNd 13 mae: Proof: From Lemma | we know that no window size pair outside region (5) can be visited more than once. Therefore, if (wiyu2) = (wi(0),w2(0)) and N= | A |, then assuming that the time between window size updates ofeach connection is finite, the window sizes converge toa point in (5) because there fare at most 1 other pairs the window size pair could take on before teaches apoint in region (5), and once the window sizes are in region (5), they do not change. . 1563