TCP Vegas Review

TCP Vegas is another end-to-end congestion avoidance algorithm. Unlike
other algorithms, it emphasizes packet delay instead of packet loss as
an indicator of congestion and uses it to adjust sending rates. TCP
Vegas has 37% to 71% higher throughput than TCP Reno and one fifth to
one half of the losses.

The original TCP uses a coarse-grained clock to estimate round trip
times and to trigger timeouts, leading to unnecessary delays in
re-transmissions. TCP Reno's fast retransmit and fast recovery improved
on this but further efficiency could be gained by eliminating the
dependency on coarse-grain timeouts. This is done by having Vegas read
and record the system clock each time it sends a segment and receives
its ACK. It uses these times to perform the RTT calculation. Vegas
then treats the receipt of certain ACKs as indication that it should
check whether RTT has exceeded the timeout. Additionally, it does not
allow for congestion windows to be decreased more than once for losses
occurring during one RTT interval.

TCP Reno does not use any congestion avoidance mechanisms, and relies on
increasing window sizes to create congestion and to estimate the
available bandwidth. This creates losses and may deprive other
connections of valuable buffers at the bottleneck router. To prevent
this, TCP Vegas monitors the relationship between increasing window
sizes and the observed throughput. It considers the difference between
the expected throughput (WindowSize/BaseRTT) and the actual throughput
to decide when to (linearly) increase or decrease the congestion
window. Separate thresholds are used for each decision. Experiments
show that the thresholds have a wide range of permissible values. Note
that TCP Vegas' increased throughput does not take away bandwidth from
TCP Reno but merely uses it more efficiently. Experiments and
simulations confirm this.

In conventional TCP, the switch from slow-start algorithm to linear
increase is heavily dependent on the threshold value. This can result
in packet losses or slow ramp-up. To avoid these problems, TCP Vegas
allows exponential growth only every other RTT to allow a valid
comparison between expected and actual throughput. The switch from
exponential window increase to linear window increase happens when the
actual rate falls below the expected rate by the equivalent of one
router buffer. Vegas* is mentioned as a possible fix for Vegas'
tendency to unnecessarily add to router buffers and to overshoot the
available bandwidth during slow start.

Experiments and simulations show that Vegas is stable, able to
outperform Reno 92% of the time, no less fair than Reno, and does not
cause a significant difference in the average queue size. The x-kernel
simulator, used for the simulations, feels like a more realistic network
simulator than some of the others mentioned as it uses actual protocol
implementation code to simulate the protocols. Furthermore, the
simulations used traffic parameters (probability distributions) derived
from traces of real traffic. As a side note, perhaps as a testament to
the effectiveness of TCP Vegas, Microsoft Vista's CTCP stack uses a
combination of loss-based congestion control (TCP Reno) and delay based
congestion control (similar to TCP Vegas).
Received on Wed Oct 04 2006 - 21:32:23 EDT