From: Craig M Prince (cmprince@cs.washington.edu)
Date: Tue Oct 19 2004 - 23:56:12 PDT
Reading Review 10-20-2004
-------------------------
Craig Prince
The paper titled "Congestion Control for High Bandwidth-Delay Product
Networks" is a novel paper describing a new congestion control mechanism
that is far more robust than TCP's congestion control mechanism. The paper
correctly identifies the problem that using packet-loss to signal
congestion, while accurate, is a very slow way to detect congestion since
packets are only detected as being lost after a timeout. Another correct
observation is that using packet loss gives a very coarse indication of
how congested a network is (either it is congested and is losing packets,
or isn't). These are just two of the issues that cause TCP to break down
under high load. Another issue has to do with the artificial damping
(slow-start, AIMD) introduced into TCP's congestion control to prevent
oscillations (which the paper shows still don't work under
high-bandwidth/high-delay). This damping effectively reduces the
efficiency of the network under normal operation.
In light of all of these problems it seems obvious that there must be a
better congestion control protocol and the authors proposed such a
protocol, called XCP. The basic idea behind XCP is that bandwidth is
carefully managed by the individual nodes to prevent sources from sending
more than the link can handle. There is an explicit signaling mechanism
(the XCP header) which informs the sources how much bandwidth there is
available (for that source). The routers in a network can now prevent
congestion before it occurs and as a result will not get more incoming
bandwidth than there is outgoing room for. This results in very little
oscillation and means maximum utilization is quickly reached -- even under
high load.
Unlike other such stable protocols which rely on per flow state in the
router, this protocol places the state in the individual packets
themselves and so the nodes can actually be completely stateless. I find
this neat because there is a great reluctance to add state to routers and
so having a stateless protocol means it actually has a chance of being
deployed.
Another cool aspect of the protocol is that it actually decouples the
issues of utilization from fairness. TCP combines these two into one which
makes it very difficult to modify one without affecting the other. The XCP
protocol cleanly separates the two. This makes sense since to prevent
dropped packets all we care about is managing how many bits flow through a
link; how a router chooses to divide those bits amongst the various
parties is its own business (literally).
I found it a little surprising that there was almost no packet loss in any
of the experiments conducted. This seems to suggest that the explicit
notification scheme is very powerful and effective; however, I wonder if
there are cases where their system will begin to break down.
One concern I have with the protocol is in the brief treatment given to
security (Section 7). In this section, they compare their protocol's
security to TCP's security. The only problem I have is that in TCP the
worse an adversary can do is to try to use too much bandwidth (which is
limited by the adversary's bandwidth); however, in XCP the router relies
on the cwnd and rtt values from the packet to perform important
calculations. Is there some security issue here not present in TCP --
after all the router is now trusting input from an untrustworthy source.
Overall, I found the arguments in this paper to be very effective. I think
this paper illustrates some of the important arguments that need to be
made when proposing new protocols: show it fixes a (important) problem,
show that it doesn't cause new problems, show that it's cost is low, and
show that it can be deployed incrementally. This paper does all of these
and so the question remains: Why aren't we using this protocol yet?
This archive was generated by hypermail 2.1.6 : Tue Oct 19 2004 - 23:56:12 PDT