Review - TCP Vegas

Review of TCP Vegas: End to End Congestion Avoidance on a Global Internet
by Ivan Hernández

The paper presents TCP Vegas an improved version of TCP Reno. Vegas
follows the TCP specification, it just a new implementation that only
takes effect in the sending end. Vegas increases the throughput and
decreases losses.

One of the shortcomings that presents Reno is its mechanism to detect
and retransmit lost segments. In spite of Reno's implementation of the
Fast Retransmit and Fast Recovery mechanism, the underlying mechanism
is based on bulky timeout measures, this results in bandwidth
underutilization. Vegas solves this problem calculating an accurate
RTT estimate based on the times in reading the clock each time it
sends a segment and when its corresponding ACK arrives. Using this
accurate RTT Vegas improves its decisions about when to retransmit.

Next, the authors explore the problem of use lost segments as a signal
of congestion in Reno. This leads Reno to congest the network and then
decrease the window size over and over again. They authors propose a
proactive approach to this problem. They calculate the Expected and
actual sending rates and calculate the difference between these. Next,
they define two thresholds (a,b), that say how much extra data can the
sender have in the network. If the difference is < a, then we can
increase the congestion window. If the difference is > b, then we have
to decrease the congestion window. Both, increment and decrement, are
lineal.

The third improvement in Vegas is in the slow-start mechanism. Vegas
uses the information of the actual rate to switch from slow-start mode
to the increase-decrease mode. This approach is based on the packet
delay instead of the original packet loss and avoids the congestion
during this first.

This is a nice paper, it describes clearly how works TCP Reno and its
problems. The paper gives solution to three important issues in Reno,
that result in a better throughput and a decrease in the packet
loss. Vegas calculates the actual sending rate for each packet and
uses this information to adapt its window and avoid congestion,
instead of the congestion control that Reno needs and its packet loss
signal; it is important to mention that the overhead of this constant
process is negligible, and furthermore, it provides big benefits.
Vegas performs better than Reno in the simulations, improving the
throughput and decreasing the retransmissions. The best part is that
TCP Vegas is does not modify the TCP specification. In order to use
this protocol, a sender just has to change its TCP implementation to
Vegas.
Received on Wed Oct 04 2006 - 15:13:42 EDT