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

Reviewer: Mike Liu

1. State the problem the paper is trying to solve.
The main problem the paper is dealing with is explaining the TCP Vegas protocol, analyzing its performance, and arguing for its strengths and adoption.
2. State the main contribution of the paper: solving a new problem, proposing a new algorithm, or presenting a new evaluation (analysis). If a new problem, why was the problem important? Is the problem still important today? Will the problem be important tomorrow?  If a new algorithm or new evaluation (analysis), what are the improvements over previous algorithms or evaluations? How do they come up with the new algorithm or evaluation? 
The main contribution of this paper is that it outlines in detail and analyzes the performance of the TCP Vegas protocol. The three key techniques employed by TCP Vegas that are an improvement over the current protocol, TCP Reno, are a new timeout mechanism, a novel approach to congestion avoidance, and a modified slow-start mechanism. After detailing the improvements, the paper also presents extensive analysis on the performance improvements of TCP Vegas over TCP Reno. To perform this analysis, they built their own network simulator based on the x-kernel. The x-kernel-based simulator provided a realistic setting for evaluating protocols by modeling the actual C code rather than a more abstract version of it. The simulator used a protocol called TRAFFIC that implemented TCP Internet traffic based on tcplib.
3. Summarize the (at most) 3 key main ideas (each in 1 sentence.) 
The three 3 key main ideas are: (1) TCP Vegas uses three techniques to improve its performance over TCP Reno: A more timely decision to retransmit a dropped segment; The ability to anticipate congestion an adjust its transmission rate accordingly; Modifying the TCP slow-start mechanism to avoid packet losses while trying to find the available bandwidthduring the initial use of slow-start. (2) TCP Vegas achieves 37 to 71% better throughput and one-fifth to one-half as many as losses as TCP Reno. (3) TCP Vegas is just as fair as TCP Reno, does not suffer from stability problems, and does not adversely affect latency.
4. Critique the main contribution
   • Rate the significance of the paper on a scale of 5 (breakthrough), 4 (significant contribution), 3 (modest contribution), 2 (incremental contribution), 1 (no contribution or negative contribution). Explain your rating in a sentence or two.
   I give this paper a rating of 5 because it does a really great job of explaining the improvements found in TCP Vegas, clearly shows the differences it has with TCP Reno, analyzes the performance of these improvements, and discusses the safety of deploying TCP Vegas, all in a very convincing fashion.
   • Rate how convincing the methodology is: how do the authors justify the solution approach or evaluation? Do the authors use arguments, analyses, experiments, simulations, or a combination of them? Do the claims and conclusions follow from the arguments, analyses or experiments? Are the assumptions realistic (at the time of the research)? Are the assumptions still valid today? Are the experiments well designed? Are there different experiments that would be more convincing? Are there other alternatives the authors should have considered? (And, of course, is the paper free of methodological errors.)
   Their methodology was rather convincing. They used simulations of TCP Vegas to illustrate how its three improvements give better performance than TCP Reno. These were experiments on a simulator and so they were empirical results but not empirical results from the real Internet since they had not deployed this protocol widely yet. Their research is rather realisitic. With regards to the new retransmission mechanism, they explained how TCP Vegas detects losses much sooner than Reno by explaining that TCP Vegas does not wait for the three duplicate ACKs to detect a loss but rather uses the system clock to generate time stamps which are compared with a timeout value to determine whether or not to retransmit. It does this not just for the first lost packet but also for the first or second following a retransmission, to catch any other segment that may have been lost previous to the retransmission without having to wait for another duplicate ACK. With regards to the new congestion avoidance mechanism, the authors used empirical evidence to demonstrate TCP Reno keeps increasing its window size until there is congestion which results in losses both to itself and to other background connections. On the other hands, TCP Vegas looks at changes in the sending its rate. This increased its throughput without creating losses and this was done without taking bandwidth away from Reno connections, which showed that it was an improvement gained by more efficient utilization of the bottleneck link rather than a tradeoff. Finally, with regards to its modified slow-start mechanism, TCP Vegas uses a self-clocking protocol which uses ACKs as a 'clock' to strobe new segments in transit and also only allows exponential growth on every other RTT. For this improvement, the authors also used empirical testing to show that this mechnaimsm was highly successful at preventing losses incurred during the initial slow-start period.
   • What is the most important limitation of the approach?
   The key limitation of such an approach, however, is that since it is not based on real-world empirical data, it is not as convincing and as accurate as test results shown from a real world experiment. However, the testing mechanism did simulate the real world rather well and so this was not too much of a problem. Also, this problem is faced by the proposal of any new protocol being considered since it is running these tests to prove that it should adopted widely and can not run tests that assume it has already been implemented widely in the real world. Also, with the modified slow start mechanism of TCP Begas, two potential problems still persist. First, segments are sent at a rate higher than the available bandwidth and so as network speeds increase, so does the amount of buffering required. Second, while Vegas' congestion avoidance mechanism during the initial slow-start period is quite effective, it can still overshoot the available bandwidth, and depends on on enough buffering at the bottleneck router to prevent losses.
5. What lessons should researchers and builders take away from this work. What (if any) questions does this work leave open?
The lessons that researchers and builders should take away from this work are that it is possible to build a relatively accurate and elaborate real-world simulator to test the performance of new protocols and to evaluate their performance with current ones and that TCP Vegas presents itself as a very convincing improvement over TCP Reno that is more efficient and safe and easy to implement. The questions that this paper leaves open are the performance of TCP Vegas vs. TCP Reno in terms of Queue Behavior when better analytical tools become available to study their real-world performance to determine if latency is in fact affected by TCP Vegas. Another question would be to study TCP Vegas under different BSD variations such as having an ACK every segment, an ACK every segment, increasing the window during linear growth by one segment per RTT or half a segment per RTT per 1/8th of the maximum segment sizer per ACK received during that RTT, or using a time-stamp option. Finally, more work could be done to analyze TCP Vegas' effect on fairly and effectively allocating resources on the Internet, in terms of guaranteeing bandwidth to real-time connections, or using select ACKs to decrease the number of unnecessarily retransmitted packets. Also, the situations in which the addition of Vegas* would be more beneficial and its actual performance in such situations have yet to be studied. Finally, the most important work that may follow this paper is actual empirical tests of the TCP Vegas protocol on the real Internet.