Reviewer: Charlie Wiseman
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? novice
What problem or issue does the paper address? Why is it important?
This paper describes an explicit congestion notification protocal, suited for high bandwidth-delay product networks, to achieve efficient and fair network utilization. As link bandwidth (and overall delay) increase, TCP and other protocols become less efficient, and so the need for a replacement exists.
What are the main contributions of the paper and why are they important?
The Variable-structure congestion Control Protocol (VCP) is designed, simulated, and analyzed.
How significant are these contributions relative to previous work?
The design of VCP is based on ideas gathered from many other protocols, including TCP+AQM/ECN and XCP. As such, there aren't many purely original concepts in this paper; however, it is significant that VCP is able to compete with more complex protocols like XCP and yet be easier to deploy (in theory) on a large scale.
Give detailed comments justifying your view of the paper.
The authors set out to achieve a set of goals with VCP. These goals include: simple congestion feedback, efficient network utilization, fair bandwidth sharing, and easy deployment. So, consider each of these goals.
The congestion feedback mechanism relies on routers encoding their load to fit in the two bit ECN (IP) header field. This seems simple enough, since many routers are already capable of providing information in the ECN field. By the same token, since this requires router interaction (at least at the bottleneck links), some overhead is added. However, comparing only against other explicit network feedback protocols, marking two bits is relatively simple.
According to their simulation, VCP is able to maintain fairly high network utilization across many different scenarios. Looking at all of the many (sometimes hard to read) figures, VCP does indeed generally do a good job of this. There are some anomalies, though, that often occur on the edges of their different cases. For instance, as the bottleneck capacity grows (left graph in figure 3), that link's utilization appears to be headed steadily down; while that capacity is moderately high (5Gbps), it would be nice to see if the trend levels off or not. On the other hand, with very small bottleneck capacities, router queues get very large, which leads to packet drops (center and right graphs in figure 3); here, the capacity is less than 1Mbps, which is becoming less and less likely as a bottleneck link in the Internet. Another oddity is the left graph of figure 4. For high RTTs, the utilization goes down because of their choice of load measurement interval, but also look around 10ms RTTs. The utilization is quite erratic.
The authors also provide simulation results for how well VCP fairly shares bandwidth. When the mix of flows all have somewhat similar RTTs, things go well for VCP. However, since their base assumptions (which are then built upon to get to the actual implementation) are that all flows have equal RTTs, VCP has problems with widely varying RTTs across all flows. Look at the left graph of figure 8. The highest difference is about 4x as much bandwidth for one flow over another. Although it isn't stated, it seems reasonable to assume that the higher RTT flows are the higher numbered flows (getting less bandwidth) since they have acknowledged a problem with longer flows getting less bandwidth. A factor of 4 isn't terrible, but it isn't great either. In addition, figure 9 shows how fast VCP converges to fair sharing (assuming similar RTTs). It seems that convergence can be quite slow. In fact, it takes nearly 100 seconds for the second flow to get the same bandwidth as the first. While that time decreases as more flows are added, it is something that should be addressed.
Finally, consider whether or not VCP is indeed easily deployable. While it is certainly better than XCP, which requires large changes at routers with the possibilty of needing to send large numbers of bits to communicate sending rates, VCP still requires changes at every (at least, bottleneck) router. These changes are simple, but still seem to require a lot work. Of course, there is also the issue of adding a new protocol to end hosts, but in practice this seems to be much less of an issue.
There a few other things worth mentioning. For instance, there are a number of parameters that have to be set for the protocol to function. The results indicate, however, that the numbers they have selected work well across many different environments. Still, these numbers may have to be tuned slightly in different network nodes to achieve optimal performance. Also, as a note, there appears to be a discrepancy between the paragraph description of figure 10 and the figure. They indicate that the added 150 flows stop at time=140 seconds, but the initial utilization drop doesn't occur until time=160 seconds.
In closing, VCP does seem to work quite well in most cases. With a few exceptions, most of the poor performance happens in extreme cases (e.g., very high or very low bandwidth or RTT). Still, in the Internet, such cases can come up often, so any real implementation of VCP would have to find a way to fix the problems. Speaking of real implementation,