Review: Congestion Control for High Bandwidth-Delay Product Networks

The paper proposes a new congestion control protocol, eXplicit Control
Protocol (XCP), to overcome the inefficiency, instabilitly and
unfairness of TCP found in networks with high bandwidth-delay products
(comprised of optical links and satellite links) by explicitly informing
the sender of the degree of congestion at the bottleneck through a set
of bytes in the packet header. The most important consequence is the
decoupling of efficiency control form fairness control.
The authors argue that packet loss is a poor signal of congestion
because it is not the only source of loss, it is difficult to say for
sure that a packet is lost and it provides no information of the degree
of congestion.
XCP provides joint design of end-systems and routers. The paper
describes XCP as a window-based congestion control protocol for best
effort traffic. Each sender maintains their congestion window (cwnd) and
rtt, and sends this as part of the packet's congestion header (H_rtt,
H_cwnd). Routers monitor the rate of input traffic to each output queue,
and according to the link bandwidth as well as sender's cwnd and rtt,
tell the flows to increase or decrease their cwnd (by modifying the
H_feedback, originally set by sender to its desired window increase). A
router later in the path can overwrite a header if it is more congested
so that eventually the packet contains feedback from the bottleneck. The
feedback reaches the receiver and is then copied to the ACK and sent
back to the sender. The rare packet losses are delt with as in TCP.
An XCP router must compute the feedback needed to make the system
converge to optimal efficiency and min-max fairness. It does not drop
packets by preventing queues from growing so large that packets need to
be dropped. The computations are done over the average RTT as determined
from information in the packet header. A single control decision is made
every average RTT to allow a sender's response to be observed. The
router maintains a per-link estimation timer set to the most recent
average RTT, and updates the timer as well as control decisions when the
timer expires. The router computation consists of the:
1) Efficiency controller that looks only at total traffic and aims at
maximizing link utilization while minimizing drop rate and persistent
queues. The aggregate feedback is proportional to the spare bandwidth
and to the persistent queue. That is, it uses MIMD to quickly acquire
positive spare bandwidth even over high capacity links.
2) Fairness Controller divides the aggregate feedback to individual
packets in order to achieve fairness. It uses additive increase when
throughput should be increased, and multiplicative decrease
(proportional to a flow's current throughput) when it should be
decreased. When the throughput is about optimal, it uses bandwidth
shuffling in which bandwidth is allocated and deallocated at the same
time so total traffic doesn't change but throughput of each flow does.
Any error in estimates affect convergence time and not correctness of
controllers.
Furthermore, the explicit feedback simplifies action against misbehaving
or unresponsive sources by sending the flow a test feedback asking it to
reduce its congestion widnow to cwnd and if it does not respond in one
RTT, the policing agents at the edges (which are monitoring behaviour
flows and keeping per-flow state) will know it is misbehaving.
The paper provides simulations comparing XCP with TCP over RED, REM, AVQ
and CSFQ. They show that XCP maintains good utilization and fairness,
low queuing delay and drops very few packets. In all cases it
out-performs TCP.
Finally, the paper briefly talks about the ease of using different
fairness policies with XCP and gradual deployment methods.

The paper is well written and presents the protocol well. However, they
do not discuss the difficulty in deployment resulting from the fact that
XCP requries re-design of both end-systems and routers. Furthermore,
they do not talk about the overhead of adding feedback information to
the header. Finally, they say the router maintains no state at one
point, but later say that the router maintains the per-link average RTT.
Received on Mon Oct 02 2006 - 17:13:53 EDT