TCP Vegas: End to End Congestion Avoidance on a Global Internet
- 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.
- 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.
- 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.
- 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.
- 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.