From: Danny Wyatt (danny@cs.washington.edu)
Date: Tue Oct 19 2004 - 22:38:48 PDT
Congestion Control for High Bandwidth-Delay Product Networks
Dina Katabi, Mark Handley, Charlie Rohrs
This paper presents XCP, an extension to TCP, that provides explicit
congestion information to hosts as well as decouples fairness control
from congestion control. It achieves this through additional packet
headers that are modified by routers along a path so that they may tell
the hosts by how much to increase or decrease their window size. In
this scheme, dropped packets are no longer a sign of congestion to hosts
(since the network should prevent itself from ever becoming congested
enough to drop packets) so they can react more intelligently to
congestion and timeouts.
As a protocol, I find it straightforward and intuitive. It achieves its
aims---as the authors both prove and demonstrate. But when compared to
the other papers we've read so far, it seems like a much less inspired,
more "traditional" software engineering approach to protocol design.
As we've seen them up to now, IP and TCP are fairly simple systems
implemented almost entirely within the hosts. The properties of the
network are actually emergent phenomena due to the interactions of many
such simple hosts. It is true that it then becomes hard---if not
impossible---to modify one network property without modifying others,
since such modifications could be achieved only through changes to the
simple systems from which the network emerges. But to deride that as a
tightly coupled system is, I think, to confuse coupling with elegance.
A highly coupled system---in the software engineering sense---usually
mixes concerns sloppily and unnecessarily. An elegant system solves
many unrelated problems with one coincident mechanism. When a highly
coupled system is decoupled, its implementation often becomes simpler.
That is not the case for the "decoupling" of flow control and fairness
in XCP. The authors ostensibly show the simplicity of their
implementation with the pseudocode in appendix A, but XCP won't be
implemented as a C program. It must modify every packet that passes
through a router, and such a scheme would only be implemented in
massively optimized, specialized silicon. The "End to End" paper gave
an example of how even a plain IP implementation can have insidious bugs
when it is optimized down to the hardware. The complexity introduced
for XCP just seems like it is more likely to introduce more
hard-to-predict, hard-to-find errors in router implementation.
As we mentioned the first day of class, bandwidth is increasing with no
end in sight. So the problems addressed in this paper must be dealt
with some day, but it will probably take an already-occurring crisis
before that happens.
This archive was generated by hypermail 2.1.6 : Tue Oct 19 2004 - 22:39:08 PDT