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

2. 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

3. 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

4. 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

5. 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

6. 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?