Analysis and Comparison of TCP Reno and TCP Vegas Review 10-14-04 Jack Meier Discussion leader

Discussion Main Idea – number of bytes in transmit is directly proportional to the expected throughput Well written but figures hard to read Points out both good and bad points Paper does not provide original work There are much better papers that come to the same conclusions Well known protocol and characteristics repeated- TCP Reno, that is currently used as a congestion avoidance mechanism, has some sufficient drawbacks, such as leaving little room for other connections, dependence on the connection delay in terms of fairness, loss causing that reduces throughput. Using TCP Vegas as an alternative, together with its improvements, can avoid several TCP Reno drawbacks. TCP is not a synchronized rate based control scheme The paper “TCP Vegas: New Techniques for Congestion Detection and Avoidance” has a more extensive analysis and identifies most of the key points more clearly Math could be cleaner and unnecessarily complicated Consensus of Students: Lower ½ of 13 papers – definitely not the best paper

Discussion for the Best Paper Well-written summary of the TCP Reno and Vegas algorithms Use RED routers to encourage the deployment of TCP Vegas. RED gateway drops packets thereby decreasing congestion mechanism to avoid persistent congestion in TCP Vegas. Proves that TCP Vegas can be made to work in the Internet and shows how Provides a mathematical model to show that TCP Vegas does not suffer from being "Delay" biased as TCP Reno. simulation results to show increasing link delays has little impact on BW given to a Source for TCP Vegas Increasing link delays for TCP Reno causes the Source associated with that link to get a decrease in BW that is almost linear with increases in link delay TCP Reno causes TCP Vegas to get less than its fair share of network BW Presents some of the draw backs of the TCP Vegas congestion control mechanism and possible first cut solutions Rerouting causing a link to have a increased associated delay. This is misinterprated by TCP Vegas to be a sign of congestion thereby incorrectly decreasing its window size sol: Sample N packets periodically to reset the baseRTT used On initial connection to a congested network TCP Vegas will interpret the RTT values as the baseRTT and push data into the network too quickly thereby making the congestion worse Analytically shows that TCP Vegas is much fairer than TCP Reno to connections with longer end-to-end delays Proves fairness of TCP Vegas with itself

Not Recommended to be the Best Paper A significant portion of the paper simply repeats results from earlier work Earlier papers are better and address nearly all the same points Rerouting and Persistent Congestion are briefly brought up; however, they are ignored in the remainder of the paper. TCP Vegas has major problems if wrong interpretation by the source is made due to topology changes that result in new minimum RTT propagation time changing Continuous congestion Dependence of TCP Vegas on RTT-accurate estimation Propagation delay of a route may change with topology No analysis of TCP Vegas for slow start

Criticisms A vast majority of the paper seems to only summarizing what was written in other papers, and very little appears to be providing any novel information It is ambiguous, its simulations superficial and its conclusion premature. It doesn't adequately explain several relevant points. The amount of buffer needed grows linearly with the number of flows, this causes a major scalability problem for TCP Vegas. Should the paper make this the main focus? The RED gateway is not a solution merely a fix to a known problem Does not explain the way you would implement TCP Vegas Mathematical definitions and proofs are weak

Questions Do you believe that the RED gateway legitimately solves the issues with making TCP Reno more compatible with TCP Vegas? How is the convergence point related to the queue size? Is the assumption that simplifies alpha and beta valid? (quasi-static) – discussed in presentation Is the assumption valid that queue size and throughput is static? How do you adjust the fairness line of the window sized pairs such that the user throughput is the same? Do you think implementing a DRR scheduler to instill fairness will work?