The currently used implementation of TCP - TCP Reno - has many problems that can lead to bad congestions on the Internet. TCP Vegas, which this paper describes, provides an alternative implementation that addresses some of these problems so that TCP performance improves. TCP Vegas essentially uses the same TCP specification, but it uses a more robust retransmission strategy that can reduce the lad of the Internet significantly.
TCP Vegas uses three different techniques to increase throughput and decrease llsses.
First, it makes a more timely decision to retransmit a dropped packet. In Reno, a method called coarse-grain timeouts calls for the receiver to send out duplicate acknowledgements for missing packets. Reno waits for 3 duplicates before retransmitting, whereas Vegas compares the timeout with the difference between time when packet was sent and current time. If the latter is greater, a packet is retransimitted immediately. This is a huge advantage because in a highly congested network, 3 duplicates may never be received by the sender, and the receiver will keep sending duplicates, which further congest the network.
Second, Vegas improves congestion control by attempting to anticipate congestion. In addition to adjustment the congestion window due to packet loss, Vegas uses a BaseRTT to compute an expected throughput and compares it with the actual throughput. The congestion window is thus micro-managed by the amount of extra-data that are on the network, not only by dropped packets.
Third, Vegas improves the slow-start strategy by reducing the doubling of the congestion window size to every two RTT. After every intermediate RTT, it compares expected and actual sending rates. If the rates decrease by a router buffer, then Vegas stops the exponential increase and uses linear increase in congestion window size. This strategy can still make sure that as much bandwidth as possible is used, but not too much that the network becomes congested so quickly.
TCP Vegas was tested using a simulator running a an x-kernel. One important factor to note is that the protocols are implemented in C, so that the same experiments carried out on the simulators can easily be repeated in real life. Different testing conditions are used when testing with Reno and with background traffic. Vegas clearly outperforms Reno.
I give this paper a rating of 4 because it offered a much better implementation of TCP that improves congestion control significantly. However, there are clear problems. First, I think more tests need to be run on real networks of larger scale to litmus test Vegas. Second, I'm not convinced the Vegas is fair when running with Reno. If we are to migrate to Vegas, there will be a heteorogenous network of Reno and Vegas nodes on the network during the transition stage, and unpredictable results can occur if Vegas were to compete unfairly.