TCP Reno and TCP Vegas use different mechanisms in detecting congestion. TCP Reno's congestion detection and control mechanisms use the loss of packets as a signal that there is congestion in the network. TCP Reno has therefore no mechanisms to detect incipient stages of congestion before losses occur, and hence cannot prevent such losses. Thus TCP Reno is reactive, as it needs to create losses to estimate the available bandwidth of the connection. On the contrary, TCP Vegas congestion detection mechanism is proactive, i.e., it tries to sense incipient congestion by observing changes in throughput rate. Since TCP Vegas senses incipient congestion, it reduces the sending rate of TCP sources, resulting in decrease in the number of packets dropped. The approach adapted by TCP Vegas is conservative.

Conservative approach is suitable when available bandwidth is less, and network is congested. But, in order to support new applications that require more bandwidth and real-time delivery, such as streaming applications or virtual reality, the link capacity of Internet backbone is growing exponentially. Hence modifications are needed to TCP Vegas to exploit the increasing bandwidths.

TCP Vegas, similar to other TCP implementations, uses four inter-wined algorithms SlowStart, Congestion Avoidance, Fast Retransmit, and Fast Recovery to control congestion. Two thresholds ? and are defined, ? corresponding to having too little and too much extra data in the network respectively. TCP Vegas does not continually increase the congestion window during Congestion Avoidance. Instead, it tries to detect incipient congestion by comparing the measured throughput to its notion of expected throughput. The congestion window is increased only if these two values are close, i.e., if there is enough network capacity so that the expected throughput can actually be achieved. Congestion window is reduced if the measured throughput is considerably lower than the expected throughput; this condition is taken as a sign for incipient congestion. Experimental studies, including our own reveal that, TCP Vegas tends to prematurely stop the exponentially increasing SlowStart, and enter the slower Congestion Avoidance, until it reaches its equilibrium congestion window size. TCP Vegas spends most of its time in Congestion Avoidance. Hence modifications are needed to Congestion Avoidance to improve the performance of TCP Vegas.

In this paper, modifications are made to the congestion avoidance of TCP Vegas, and the modified algorithm is called “Dynamic Vegas”. Dynamic Vegas calculates the available bandwidth that still needs to be utilized. Instead of increasing the congestion window linearly by reciprocal of congestion window, it makes the amount of increase scalable. The amount of increase depends upon the available bandwidth, and is not constant which the case in the original TCP Vegas is.

Several studies have been made to improve the performance of TCP Vegas, and to solve its interoperability with TCP Reno. Hengartner et.al, in [1] has shown that performance gains of TCP Vegas are achieved primarily by new techniques for SlowStart, and that the Congestion Avoidance mechanism of TCP Vegas has only a minor influence. TCP Vegas uses congestion sensitive window update strategy. TCP Reno's faster and unresponsive exponential opening of the congestion window may result in overshooting the available bandwidth quickly and loosing multiple packets. When TCP Reno and TCP Vegas are interoperated, TCP Reno steals the bandwidth of TCP Vegas, as TCP Vegas is conservative.

Studies have been made to improve the performance of TCP Vegas over high speed and long delay links. HighSpeed TCP[2] involves a subtle change in the Congestion Avoidance response function to allow connections to capture available bandwidth more readily. Scalable TCP[3] is similar to HighSpeed TCP, in that the congestion windows response function for large windows is modified to recover more quickly from loss events, and hence reduce the penalty for probing the smoothed available bandwidth. Similar to TCP Reno, both HighSpeed TCP and Scalable TCP use packet loss as an indication of congestion. This causes periodic oscillations in the congestion window size, round-trip delay, and queue size of the bottleneck node. AdaVegas [4]and FAST TCP [5] are two congestion control algorithms based on TCP Vegas. AdaVegas uses constant increments to increase its window size. It is too sluggish when the connection passes through a very high-speed and long delay path. FAST TCP adopts a more aggressive way to update its window size. However, it needs a large bottleneck buffer (queue) to prevent packet losses.

Quick Vegas proposed in [6]adds some aggressiveness to TCP Vegas. Quick Vegas is suitable for high bandwidth delay product networks, since it reaches the equilibrium quickly. Once equilibrium is reached no further improvement in performance is possible. Also, it aggressively decrements the value of congestion window when ? > ? (? is defined below). Incrementing the value of the congestion window in scaled manner,when ? < ? is one of the good features of Quick Vegas.

Vegas-A [7] proposes a modification to TCP Vegas. TCP Vegas has fixed values for ? and ?. TCP Vegas strategy is to adjust the source congestion window in an attempt to keep a small number of packets buffered in the routers along the path. Thus, when TCP Vegas connections compete with TCP Reno connections, the fairness problem is worse with larger router buffers. Since the average number of packets in the router buffer is to be kept within ? and ?, the main idea in Vegas-A is that, rather than fixing ? and ?, they may be made adaptive. At the start of the connection ? and ? are set to their default values. These values however change dynamically depending on the network conditions. Vegas-A decision of increasing the values of ? and ? are based on whether the throughput is increasing or not. When all the connections start at the same time, fairness can be achieved, but Vegas-A favours old connections to new connections.

The Pseudo code for Congestion Avoidance algorithm of original TCP Vegas is as follows:

Expected = Current Window Size / BaseRTT

Actual = number of packets in transit / RTT

Where, Expected is the expected throughput, actual is the actual throughput, RTT is the round trip time, BaseRTT is the minimum of all round trip times measured, cwnd is the congestion window, current window size is the size of the current congestion window.

Dynamic Vegas uses the following procedure:

If (?-?) < (?-?), procedure is similar to ? < ? case, where by the cwnd is incremented by incr2/cwnd. Initial value of incr2 is zero. If condition continues to hold,incr2 is incremented by one. The maximum value by which cwnd is incremented is (?+?) / 2)/cwnd.

• If ? < ?, increment the cwnd by incr1/cwnd, instead of reciprocal of cwnd. Initial value of incr1 is zero. If condition ? < ? continues to hold, increment the value of incr1. The maximum value by which cwnd is incremented is one (even if incr1 becomes greater than cwnd). If ? becomes greater than ? or SlowStart is activated, incr1 is reset to zero.
• When ? > ? , cwnd is decremented by one.
• ? When the value of ? is between ? and ?, the procedure adopted is as follows:

else

increment cwnd by 1/cwnd.

The idea is that, if increment was successful it might be the case that there is enough bandwidth, and it is worthwhile to move to a more aggressive increasing strategy. Hence the scaled value of increment is used when ? < ? and (?-? ) < (?-?). ? value is kept between (?+?) /2 and ?

Pseudo code of Dynamic Vegas

Slow Start:

Values of incr1 and incr2 are set to zero.

Congestion Avoidance:

Methodology

The topology is as shown in Figure1. Of the ten sources, five sources act as TCP Reno sources and the other five sources act as either TCP Vegas or Dynamic Vegas sources. Bandwidth and propagation delay of all links except bottleneck link is 50Mbs and 5ms. Bandwidth of bottleneck link is variable and takes values 0.1, 0.5, 1, 5, 10, 20, 30, and 50Mbs. Propagation delay of bottleneck link is 5ms. FTP is used as traffic generator and packet size is 1000 bytes. No limit on queue size is imposed, and its default value is 50. TCP window size is limited to a maximum value of 50, and are set to their default values 1and 3 respectively. For simulation, NS2 is used and graphs are generated using Xgraph. Each run of the simulation is for 200sec. The metrics used are number of packets delivered successfully, and the number of packets dropped.

Figure 1. Dumbell Topology

As can be observed from Figure 2 and Figure 4, there is a lot of difference in the number of packets delivered successfully of TCP Reno and TCP Vegas. TCP Reno being aggressive captures all the available bandwidth, whereas TCP Vegas stabilizes in low throughput region. The main reason for low throughput of TCP Vegas when operated with TCP Reno is the rate at which it increases the cwnd size. Though TCP Reno drops more number of packets than TCP Vegas, as may be observed from Table 1, it delivers more number of packets successfully. Dynamic Vegas competes with TCP Reno in capturing the available bandwidth. It successfully delivers more number of packets than TCP Vegas and is approximately equal to TCP Reno at almost all bandwidths as shown in Figure 3 and Figure 5.

Figure 2. Variation of Number of packets delivered successfully of TCP Reno and TCP Vegas with Bottleneck link Bandwidth

Figure 3. Variation of Number of packets delivered successfully of TCP Reno and Dynamic Vegas with Bottleneck link Bandwidth

Figure 4. Variation of Number of packets delivered successfully of TCP Reno and TCP Vegas with Time

Figure 5. Variation of Number of packets delivered successfully of TCP Reno and Dynamic Vegas with Time

Table 1. Number of packets dropped by TCP Reno, TCP Vegas and Dynamic Vegas at different Bottleneck Link Bandwidths

”Dynamic Vegas”, a modified TCP Vegas algorithm is proposed and evaluated. Modifications are made to congestion avoidance of TCP Vegas, and interoperated with TCP Reno. When TCP Reno and TCP Vegas are interoperated TCP Reno performs better than TCP Vegas at low congestion levels. But it is not the case when Dynamic Vegas is interoperated with TCP Reno. Dynamic Vegas prevents TCP Reno from stealing its share of the bandwidth. TCP Vegas drops less number of packets than TCP Reno and Dynamic Vegas, but it delivers less number of packets.