From: Michael J Cafarella (mjc@cs.washington.edu)
Date: Mon Oct 18 2004 - 20:21:14 PDT
Congestion Control for High Bandwidth-Delay Product Networks
By Kitabi, Handley, Rohrs
Review by Michael Cafarella
CSE561
October 20, 2004
Like many networking papers, this one wants to maximize bandwidth
utilization and fairness. However, it's shown that TCP has a lot
of problems with very high-bandwidth (or high-latency) links. TCP
packet-loss-based congestion control does not react quickly enough
to prevent router congestion. TCP slow start, which probes to find
a congestion-safe send rate, does not grow quickly enough to utilize
bandwidth except on the most long-lasting connections.
Instead, the authors suggest providing hosts with explicit
congestion through a congestion header. The transmitting host includes
some information, such as its current congestion window and its rtt
estimate. Routers along the path write information into the header,
too, in the feedback slot. Routers along a flow use the cwnd and
rtt info to make various decisions; they communicate back to the
host via the feedback slot. Because routers communicate congestion
info explicitly, without packet-loss side effects, they can do so
very frequently. Indeed, the authors say routers ought to do so
once every estimated rtt period.
Routers also divide congestion and fairness control. First, a
congestion controller determines how much the total flow into the router
can be reduced or increased. The fairness controller then allocates
this positive or negative feedback to hosts, via the feedback header
info.
A great part of this paper is how they phrase congestion control as
a control-theory problem. Much of the TCP work we've seen has felt
a little too informal for safety's sake, when considering the strange
issues queues can introduce. But by considering XCP as a control
theory problem with delay of the estimated rtt, it's easy to analyze.
It's also clear that TCP, whose control delay depends on factors like
current congestion, router queues, etc, has some problems.
Many papers like this face deployment problems, but the issues here
seem modest. The actual packet modification is very small. Routers
do not need to keep substantial amounts of state (though they do need
to be rewritten). The biggest issue is probably security, though
it's not clear XCP has more problems than TCP in this regard. The
authors also discuss how to build routers that could integrate XCP
into a TCP framework.
Overall I liked this paper very much. The idea is sensible, there is
a lot of performance information, and there's a good theoretic framework.
There aren't any obvious areas I would have covered.
This archive was generated by hypermail 2.1.6 : Mon Oct 18 2004 - 20:21:15 PDT