Summary: Congestion Control for High Bandwidth-Delay Product Networks

This paper describes the Explicit Control Protocol (XCP), a generalization of
Explicit Congestion Notification (ECN). The authors note that TCP
performance degrades substantially as the delay-bandwidth product of the link
increases. They argue that no adjustment to the queueing policy will prevent
this from happening if the delay-bandwidth product is pushed high enough.
Instead, they propose a replacement for TCP that offers "high utilization,
small queues, and almost no drops, independent of capacity or delay".

The main problem with TCP is that it relies on packet loss to signal
congestion. Packet loss is not always caused by congestion (ie. garbled
packets over wireless links). Furthermore, it can take quite some time (esp.
over high RTT links) to notice that packets have been lost. Finally, using
packet loss requires that the protocol constantly be pushing the network into
overload and then backing off, in order to ensure that all the available
bandwidth is being used.

XCP solves this problem by using explicit signalling between the sender and
receiver (along with all the routers in between). Each packet includes the
sender's current congestion window size and estimated RTT for the path. It
also includes a field which allows the sender to request an increase in the
cwnd. This field is adjusted by the routers and receiver, and is then sent
back in an acknowledgement packet. In an uncongested network, the sender can
reach its desired cwnd size with just a single RTT (ie. no TCP slow-start,
etc.).

One of the major features of the protocol is that it separates efficiency and
fairness. Efficiency is concerned with ensuring that the links are maximally
used, but not overloaded, without regard to the flows passing through the
links. Fairness is concerned with ensuring that each flow is receiving an
appropriate share of the link bandwidth. The paper explains that the
efficiency control loop must be very responsive in order prevent the symptoms
of congestion (ie. packet loss, queue buildup, etc.). The flow controller
does not need to be so fast. In fact, since it needs to look at the long
running behaviour of individual flows, it can't respond as fast by necessity.

The biggest problem here is that it isn't TCP, and therefore faces a very
uphill adoption battle. Although the protocol can be deployed alongside TCP,
for this to have any practical benefit, there has to already be some critical
mass of other XCP-enabled hosts. This creates the typical chicken-and-egg
problem that keeps many good ideas from being practical.
Received on Tue Oct 03 2006 - 02:32:42 EDT