Basic concept of TCP-Vegas

TCP Reno and TCP Tahoe models can determine the congestion in the network only when there some packet loss occurred in the system. So in these models, we have compensated for the packet to sense the congestion in the network. In these models when packet loss occurs the window size is decreased and the system enters the congestion avoidance phase. 

While TCP Vegas senses the congestion in the network before any packet loss occurs and instantly it decreases the window size. So, TCP Vegas handles the congestion without any packet loss occurring. 

TCP Vegas uses round trip time for the increase or decrease of the congestion window. Expected and current throughput is measured whose difference is compared with some min and max threshold values. On the basis of the comparison we increase, decrease, or don’t change the congestion window. 

After that, some drawbacks of TCP Vegas are explained. These are dealing with finding the difference in the forwarding and backward flow of data, rerouting, etc. So, TCP Vegas does not perform better in these conditions. 

It is proved in some papers after experiments and simulation that TCP Vegas performs 40 -70 percent better than other TCP models like Tahoe and Reno. 

TCP Vegas

It is a completely different approach to bandwidth management and TCP was the first attempt at it. And is based on congestion detection before packet loss occurs. TCP Vegas controls the congestion window by measuring the roundtrip times of the packets. In this, we find the extra data which is measured by subtracting expected data and the actual data in the network. This extra data is compared with two thresholds i.e alpha α and beta β accordingly the window size is increased or decreased. 

So the steps in the algorithm are as follows.  

• The sender measures the expected flow rate i.e cwnd/BaseRTT. 
  
• Then the sender finds the current flow rate by using the actual roundtrip time of the packet. 
  
• After that sender computer the extra data in the queue i.e extra data = (expected – actual) * BaseRTT

So, the formula used in TCP Vegas is as follows. 

α <= (expectedOutput-actualOutput)*baseRTT <= β

where -
expectedOutput = window size divided by baseRTT, 
actualOutput = window size divided by currentRTT
baseRTT = It is the minimum RTT measured so far.
extra data in the network = (expectedOutput-actualOutput)*baseRTT

So 3 cases are there as follows. 

• Case-1 :
  If extra data in the network is greater than Beta then the window size is decreased. 

cwnd=cwnd-1

• Case-2 :
  If extra data in the network is less than alpha then the window size is increased. 

cwnd=cwnd+1

• Case-3 :
  If extra data lies between closed intervals [alpha, beta] then the window size is not changed. 

cwnd=cwnd

Note: 
After applying one of the above cases, the same cycle is repeated again in the next round, and based on the result window size is decreased, increased, or does not change. When the network is not congested the actual flow rate will be close to the expected flow rate. When the network is congested the actual flow rate will be less than the expected flow rate. TCP Vegas attempts to utilize the network’s bandwidth without congestion in the network. The window size of TCP Vegas converges to a point that lies between w + alpha and w + beta. TCP Vegas has congestion control ability and also gives stability to the network but it can not fully use the bandwidth.