From: Tyler Robison (trobison@cs.washington.edu)
Date: Tue Oct 19 2004 - 23:48:16 PDT
This paper puts forth an alternative to TCP, called XCP, which is
described as being far superior to TCP in virtually every way: it makes
efficient use of the available bandwidth more quickly than TCP, it remains
stable when scaled to greater bandwidth and delay while TCP becomes
unstable, and it boosts that there are virtually no lost packets, to name
a few. On top of that, the ideas involved are fairly simple, and should
be easy to implement, and the paper briefly describes how it could be
gradually introduced, and gives a variant that could mingle with TCP
networks.
The complaints against TCP here are numerous: it doesn't scale well, it
grows to fill available bandwidth slowly (a substantial problem given that
much of the Internet's traffic consists of short flows), and that using
packet loss as a signal of congestion is a bad idea as congestion is only
one of its sources and because even if you correctly interpret the signs,
its fairly slow and you only get a yes/no answer. It should be stressed
that, according to the paper, the TCP problems are fundamental to the
protocol, and not the consequence of some particular implementation (such
as choice of queuing method).
XCP makes an effort to fix these problems by adding a congestion header,
which includes the sender's window size and expected RTT, and has
congestion control information set by the routers it passes; essentially,
the bottleneck of the path traveled by the packet will leave its
impression on the packet. This information is used by the receiver to
increase the size of the window (if there is extra bandwidth at the
bottleneck), or to decrease it (if there is congestion). The decision is
made by the routers along the way, and is based off of its available
bandwidth and current traffic conditions. First it calculates f, the
increase/decrease in traffic (this is the job of the efficiency
controller). Then the fairness controller divides this up between the
flows; essentially extra bandwidth is split evenly, and if there is a
shortage, the decreases of a flow are proportional to its throughput (it
only moves toward fairness on the decrease).
The whole thing seems very sound, as it is based off of control theory,
and is backed up by several simulations comparing it to TCP with various
queuing techniques. Besides that, the overall idea makes a good deal of
sense; even if it is mathematically founded, the general idea is fairly
intuitive.
Nonetheless, there are a few potential problems. First, the data is
gathered through simulations, so its hard to say whether the data is
entirely accurate or not. Secondly, and perhaps more importantly, the
security issue isn't fully explored in this paper. True, there is a
section with such a title, but it really doesn't consider all options; for
instance, how well would a XCP system withstand interactions with a
malicious host? The procedure given for detecting a misbehaving host
appears to assume that the host will supply correct header information,
but will simply not alter its window when instructed to; it seems that a
host willing to falsify its header could easily escape detection, and
possibly persuade a router that there is more or less congestion than
there really is. Perhaps this is not the case, but the paper fails to put
forth an argument against this.
This archive was generated by hypermail 2.1.6 : Tue Oct 19 2004 - 23:48:17 PDT