CSE 770 Paper Review

Reviewer: Mike Wilson
Date: 9-29-2005

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?

Internet bandwidth control is currently done by either ECN (explicit congestion notification) or congestion avoidance by loss detection (normal TCP congestion control). New proposals (XCP) are much more efficient, but has the problem of requiring intrusive changes to the underlying Internet Protocol. The authors present an algrithm (VCP) that supplies the major benefits of XCP while only making non-instrusive changes to the underlying Internet Protocol.

The importance is based in improvements to bandwidth usage. The issue is far from crucial: current technology already does an adequate job. This is merely an improvement.

What are the main contributions of the paper and why are they important?

The authors succeed in duplicating the bulk of the benefits of XCP using only the remaining "free" bits in the IP header. The only benefit left out is that XCP converges to fair much quicker.

The authors also prove the stability of VCP under simple conditions. While these results do not directly apply to more complex configurations, the results are still fairly reassuring.

How significant are these contributions relative to previous work?

XCP was useless without major changes to the internet infrastructure, but provided substantial improvement over prior mechanisms. On the other hand, VCP can be applied (piecemeal if necessary) without being intrusive. This is certainly a major benefit.

However, existing congestion control mechanisms do appear adequate for today's Internet. While the work is well done and well demonstrated, the end result is of moderate importance.

Finally, since most of the concepts in VCP came from traditional congestion control and XCP, the novelty value is also reduced.

Give detailed comments justifying your view of the paper.

The goal of the authors is to provide the same benefits of XCP while still being deployable.

XCP's major goal is to provide more complete link utilization by reducing the convergence time after a multiplicative decrease in sending rate. TCP, with or without AQM/ECN, does not solve this problem because the feedback to the sender merely says that the link was congested. It does not say how congested. The sender must back off multiplicatively and re-approach the congestion zone cautiously, using additive increase. It is entirely possible that the link usage has dropped and that the approach can be multiplicative, but there is no way for a sender to know: congestion notification is binary, "yes or no."

In contrast, XCP tells the sender how congested a link may be. From this, the sender can converge to a more appropriate sending rate much faster without risk of overshoot. Unfortunately, XCP uses too many bits to provide this information.

VCP uses 2 bits to provide a 3-phase congestion notification: low, high, overload. The demonstrations that this is sufficient are convincing. While the convergence may not be quite as fast as in XCP, the improvement over older forms is still very impressive.

The deployability goal requires several things:

1. Backwards compatibility. This is established: an IP router or endpoint running today's software could still function with a VCP host. However, an analysis of the impact of currently deployed use of these bits on VCP would be necessary before attempting to merge VCP into the internet at large! Imagine a receiver that happens to set the VCP bits to "low congestion" on every ACK. The result would be widespread congestion and massive packet loss. One hopes that older technology (TCP's congestion control) would still continue to limit the rate during episodes of loss.
2. Deployability on end systems. This can be done fairly simply in new operating systems; however, the changes are to the underlying kernel and may not be easy to make in currently deployed systems. A piecemeal approach must be used. See above for the potential hazards of heterogeneity.
3. Deployability on routers. Once again, new routers can easily support VCP. Upgrading older routers will not be simple.

Finally, what about flows that don't use TCP? The authors assume for the entire paper that the receiver will be sending ACK packets back to the sender. For some protocols, this assumption may not hold (unidirectional flow), or hold weakly (batch or selective acknowledgements). There is no discussion of applicability to other protocols. If the VCP bits are to be used only in TCP, then perhaps they belong in the TCP header, not in the IP header.

One point not addressed is that the authors decouple the algorithms from the routers. Routers determine the current congestion level. End-systems determine a sending rate. Just as in the case of TCP or TFRC, it is probably possible for a sender to choose to send faster than the algorithm allows. Hopefully this will be addressed in future work.