Reviewer: Chakchai So-In
Date: 4-26-2007
How would you rate this paper, relative to others we have read? top 25%, but not top 10%
How would you rate your knowledge of the topic of this paper? familiar, but not expert
What problem or issue does the paper address? Why is it important?
The issue here is to design the CC algorithm (TCP-liked) to achieve high link utilization in high speed network with small buffer.
What are the main contributions of the paper and why are they important?
Design the TCP-liked protocol, E-TCP, to prevent the packet loss probability from going to zero as sending rates increase. In other words, E-TCP drives the bottleneck to an equilibrium state of moderate congestion. Instead of W = W+1/W and W=W-W/2 (TCP), W=W+1/25 and W= W-W/(25*(2+0.01W)) are used for AIMD. The authors also introduce the reliable data mechanism to mitigate this.
How significant are these contributions relative to previous work?
Consider the only result from the paper; I am surprised that this protocol outperforms others: HSTCP, STCP, CUBIC, LTCP, and FAST.
Give detailed comments justifying your view of the paper.
I believe in the comparison among all simulation protocols, the authors used just 20 packets buffer; however, in real world the routers have much more packets than that so I think it's better to discuss the issue on the effect of queuing delay or some other factors if it really impacts on protocol performance. One issue here is that the author fixed the number of flows to either 1 or 50 flows. It'd be more convincing if a variety of number of flows have been tested and perhaps, if the protocols' performance are independent of #flows. The author did not run it against TCP (TCP-friendly issue) so it'd make a strong result if the fairness between this protocol and TCP is tested (maybe not in high speed network since we know TCP performs poorly in that environment) It's quite misleading here when at the first look, the authors claim that the utilization are based on only loss rate; however, loss rate is based on RTT anyway. The authors did not plot the queueing behavior. I think it's good idea to see the queueing oscillation behavior. It seems that the big problem on this protocol is the convergent time (several seconds to be in stable state) In figure 11, we thought that CW1 should be green and CW2 should be red since CW1 needs bigger w in order to get fair rate at the bottleneck link.