Summary: TCP Vegas: End-to-end Congestion Avoidance on a Global Internet

This paper describes TCP Vegas, an extension to the TCP Reno protocol that
improves throughput and decreases retransmissions. It is fully backward
compatible and can therefore be used alongside TCP Reno. In fact, the paper
claims that TCP Reno flows benefit slightly when competing flows are switched
to TCP Vegas. The improvements are a result of three main adjustments to TCP
Reno.

TCP Vegas uses a new retransmission mechanism. TCP Reno waits for either
three duplicate acks or a timeout to go off before retransmitting a lost
packet. The authors note that the timers that are used are very
coarse-grained (ie. multiples of 500 ms), and this can result in a lot of
lost time when RTTs are small. Even with Fast Recovery, a 19% gain in
throughput can be had by eliminating waits on the coarse-grained timeout.
Vegas adds an additional check to determine if a packet should be
retransmitted. If a duplicate ack is received, it checks the timestamp at
which the first inflight packet was sent against the current time. If it is
more than the RTT, it retransmits the packet immediately, without waiting for
the next two duplicates. Using duplicate ACKs at time-check hints
effectively increases the resolution of the timeout clock without having to
pay the interrupt-and-check penalty that would result if the coarse timer
frequency were increased.

TCP Vegas uses a new congestion avoidance mechanism.
Traditionally, TCP drives the network into overload, notices the packet loss,
and then backs off. The authors note that if the RTT can be carefully
monitored, this isn't necessary. An increasing RTT most likely indicates an
increase in queueing, and can act as an early-warning of packet loss.
Therefore, if the RTT is seen to be increasing, the protocol backs off,
reasoning that if it were to continue at the current transmission rate,
packet loss would soon occur.

This idea is also used to set the slow-start threshold. Vegas doubles the
window size on every other RTT until its RTT measurements indicate that there
is one queued packet along the path. This implies that the links have all
reached their maximum capacity, and thus further increases in the window size
are likely to simply result in additional queueing rather than additional
throughput. Once the single-packet threshold has been reached, Vegas exits
slow start and switches to linear increase. By relying on delay rather than
loss, Vegas can more quickly stabilize at the optimal window size, as it
doesn't need to go through several cycles of exceeding it and dropping back
to find the ideal slow-start threshold for the path.

The ideas presented in this paper seem very useful. I especially liked the
idea of watching the RTT changes over time in order to infer information
about the queue lengths in the routers. It seems that this would greatly
stabilize the throughput, as the protocol no longer needs to probe until
packet losses occur. I also liked the technique for presenting graphs; it
allows a lot of data to be visualized at once. Unfortunately, the authors
were limited to black and white when producing these graphs. As a result, I
have a hard time distinguishing the lines from each other.
Received on Thu Oct 05 2006 - 00:53:19 EDT