Congestion Control for High Bandwidth-Delay Product Networks

From: <nadeem.abji_at_utoronto.ca>
Date: Mon, 2 Oct 2006 16:55:49 -0400

Paper Review: Congestion Control for High Bandwidth-Delay Product Networks

The paper introduces a new transport layer protocol called eXplicit
Control Protocol (XCP). XCP was created to handle congestion control
in networks facing high bandwidth-delay products since TCP is said to
be inefficient and unstable in such circumstances. The protocol is
based on the Explicit Congestion Notification protocol (ECN). TCP?s
future in high-bandwidth networks has been a hot topic and this paper
attempts to provide an alternative.

The protocol has some key aspects. First, rather than single-bit
congestion notification, the routers inform senders about the degree
of congestion, an improvement over ECN. Second, the protocol attempts
to decouple utilization control from fairness control. Third, the
protocol differentiates between error and congestion losses, which can
be a major benefit in wireless networks.

The paper argues that the reactionary method of inferring congestion
from packet loss is very poor. The XCP approach is an improvement
over the single-bit scheme used in ECN. Every router along the path
can update congestion header in the XCP packet. Thus at the end of
the trip, the packet will contain the feedback information of the
bottleneck router. The sender uses the feedback information to
increase or decrease its send window after initializing it with a
desired value.

The routers in XCP play a pivotal role. Packet dropping is minimal, a
key feature, and thus XCP operates on the principle of preventing
queues from reaching a congested state. The routers attempt to avoid
burstiness by estimating feedback over averaged time intervals. An
efficiency controller is used to ensure that all spare bandwidth is
being used and any persistent queue is drained without worrying about
fairness issues. The fairness controller on the other hand sets the
feedback values proportionally (using AIMD) to ensure that all flows
are receiving equivalent bandwidth. XCP is claimed to converge to
fairness faster than in TCP. Fairness convergence is caused by the
multiplicative decrease in the window size. Since XCP uses explicit
notification rather than inference from packet drops, the convergence
occurs more rapidly.

The paper takes the approach of a fluid model, control theory analysis
to show that the Nyquist stability criterion is met. Simulations are
also used to demonstrate the effectiveness of their protocol. The
following presents some results from an ns-2 simulation used to
compare XCP to TCP Reno over several queueing disciplines (RED, REM,
AVQ, CSFQ).

- As link capacity is increased, bottleneck utilization decreased and
packet dropping increased in TCP while remaining stable in XCP.
- As propagation delay increased, utilization once again decreased in
TCP while remaining stable in XCP.
- XCP was shown to work well in situations with high short web-traffic
common in today?s Internet.
- XCP was shown to be more fair than TCP.
- XCP coped well when RTT variation was very high.

Although analysis and simulations are a good starting point, both are
based on a set of assumptions which may not hold in the Internet (i.e.
Poisson traffic model is not a good model for real traffic). Another
pitfall in this protocol is the fact that senders are limited to send
at a rate that a bottleneck router can handle. This may result in
significant under-utilization of a large number of routers not
experiencing congestion. IP is a best-effort service and thus some
packet loss is acceptable. Attempting to rid all packet loss may have
adverse effects on performance. On the other hand, by decoupling
utilization and fairness control the paper opens up the possibility of
differentiated services in the Internet. Whether the idea is feasible
or not, the paper addresses a key issue by investigating possible
alternatives to TCP, which many feel is not suited for next generation
Gigabit networks.

-- Nadeem Abji
Received on Mon Oct 02 2006 - 16:56:20 EDT

This archive was generated by hypermail 2.2.0 : Mon Oct 02 2006 - 17:13:55 EDT