Reviewer: Manfred Georg
Date: 9-29-2005
How would you rate this paper, relative to others we have read? top 50%, but not top 25%
How would you rate your knowledge of the topic of this paper? expert
What problem or issue does the paper address? Why is it important?
This paper presents a new congestion control algorithm based on minimal router support. TCP was designed for connections that were slower than modern network links. Unfortunately, it does not scale well to fast network, due to its AIMD (Additive Increase Multiplicative Decrease) congestion control algorithm. This has recently lead to a number of proposals for alternate algorithms that scale well to fast, high latency (high Bandwidth-delay-product) network. This paper presents such an algorithm.
What are the main contributions of the paper and why are they important?
The paper contributes a scalable congestion control algorithm that can be implemented with minimal effort in the Internet. It evaluates this algorithm theoretically and in ns-2 simulation.
How significant are these contributions relative to previous work?
This paper presents an interesting approach to designing a scalable solution for modern congestion control, taking into account the limitations of IP headers and the standardization process. Though better techniques for solving this problem have already been proposed, they are difficult to implement in the Internet. This paper has a more realistic, though suboptimal solution. The choice is really, about how significant a problem the scalability issue is. If it is a big deal that threatens the ability for the Internet to function, then this paper does not address the problem adequately. On the other hand, if a patch to the current situation is sufficient, then this paper details a possible solution. It is important to have such choices; this paper presents a significant contribution.
Give detailed comments justifying your view of the paper.
This paper is simply a hack patched onto the current situation. I have no problems with the analysis, ideas, or motivation of this work. However, I believe it does not adequately solve the problem. In a way, this paper is deceiving.
In figure 1, notice that it takes the second flow about 20 seconds to converge to approximate fairness. This slow convergence is caused because when one flow is utilizing the link, the network is in AIMD mode. The second flow is never allowed to use MI to find a fair rate quickly. Since AIMD scales linearly with respect to capacity Although, 20 seconds might be acceptable, this AIMD convergence scales linearly with capacity. Therefore, imagine scaling the capacity of the network one hundred fold to 1Gbps (Not unrealistic even in today's networks). It will now take the second flow 20*100 sec = 2000 sec = 33 min to converge. This illustrates the fact that this algorithm only hides the inherent scalability issue of AIMD in the special case of an unloaded network. (A note from discussion with Maxim Podlesny: if a link carries many slow flows, this is not an issue. It is a scalability problem with the bandwidth of the actual flow, not the capacity of the link.)
Although, this particular objection may not be a fundamental, unsurmountable problem, I don't think it is a good idea to implement this protocol and imagine that all the scalability problems of the new Internet will be solved. When we fix this problem, we need to fix it at the root (the AIMD algorithm) so that it never occurs again. Until then, we will have an endless supply of patches, like this paper.
I'm sick of looking at proposals for new Internet protocols that completely ignore the issue of misbehaving clients. This is especially relevant when were are talking about networks were individual hosts are fully capable of injecting massive amounts of data into the network (otherwise scalability wouldn't be a problem).
In my opinion, this paper correctly addresses the issue of fairness. That is to say, fair throughput should not be inversely proportional to RTT, but more appropriately, inversely proportional to the number of congested bottleneck links traversed. I didn't understand the exact topology they were using for this experiment, it may be that the long flow as actually over-penalized.