Review: TCP Vegas

Paper: TCP Vegas: End to End Congestion Avoidance on a Global Internet

Name: Robert Danek.
Course: CS2209, Fall '06.

    This paper explores an alternate implementation of the TCP Protocol,
called TCP Vegas. This new implementation is intended to replace the
Reno implementation distributed in 4.3 BSD Unix. Furthermore, this
implementation does not make any changes to the existing TCP specification.

    TCP Vegas manages to achieve 37%-71% better throughput compared to
Reno. It does this by making more efficient use of existing bandwidth,
instead of trying to aggressively steal bandwidth from other flows. The
other benefit of Vegas over Reno is that it manages to decrease losses.

    There are three main techniques that Vegas uses in order to achieve
its results.

    The first technique involves modifying the retransmission mechanism.
The problem with the retransmission mechanism in Reno is that it uses a
coarse-grained clock for checking when timeouts have occurred. Because
of this, Reno usually ends up waiting longer than necessary before
resending a segment. Fast retransmit and recovery mechanisms were
introduced into Reno to alleviate this problem, but Vegas was able to
make further improvements. It does so by using certain ACKS as a hint
for checking when timeout should occur. With this technique, Vegas will
wait less time than Reno to retransmit a segment.

    The second technique involves introducing a congestion avoidance
mechanism. The problem with Reno is that it cannot detect congestion
before losses start occurring. Vegas tries to determine when congestion
is about to occur by comparing the measured throughput rate with the
expected throughput rate.

    The third technique involves modifying the slow-start mechanism. The
problem with slow-start in Reno is that there is no safe window
threshold for slow-start that can be set when the connection starts. If
it's set too low, then the window will not grow fast enough; if it's set
too high, losses will result. In Vegas's version of slow-start, Vegas
tries to make effective use of bandwidth without incurring losses by
using its congestion detection mechanism with some minor modifications.

    Finally, the authors provide extensive simulations and graphs to
demonstrate Vegas's superiority over Reno. In particular, they even
examine the case where flows using both Vegas and Reno coexist, showing
that gains can be made in that scenario as well without adversely
affecting flows that use Reno.
Received on Wed Oct 04 2006 - 14:36:23 EDT