Review: An Integrated Congestion Management Architecture for Internet Hosts

The paper presents an end-system Congestion Manager (CM) architecture
for managing Internet congestion. The authors claim that changing
internet traffic patterns will require a change from the traditional TCP
congestion control because web transfers (short TCP connections) stress
network congestion heavily, some commercial products turn off TCP's
congestion control to accelerate web downloads, and most importantly
many real-time streaming applications run over UDP and hence do not
react to congestion. Furthermore, TCP deals each flow independently so
that an application with more flows has its traffic reduced more than
those with fewer flows (each flows cwnd is halved).
The proposed approach focuses on shared state learning (flows share
information about congestion and learn from each other) to enable
efficient multiplexing of concurrent flows. It separates congestion
control from loss recovery. The main contributions, as stated in the
paper are:
1. CM algorithms and protocol to perform and integrated congestion
management across an ensemble of unicast flows in an application and
transport independent manner.
2. CM adaptation API for applications and transport protocols to share
congestion information and react to it.
3. CM appliations and perforamance: they implement a web-server over TCP
and an audio server for layered audio streams, and present simulations
of performance.
The CM has two modules:
1. Sender consists of
   a) 'Congestion controller' to adjust the aggregate transmission rate
between sender and receiver according to congestion estimates based on
feedback from the application and from 'Prober'.
   b) 'Prober' sends periodic probes to the receiver requesting
congestion information.
   c) 'Flow Scheduler' apportions available bandwidth amongst the
different flows and notifies applications when they are permitted to
send data.
2. Receiver consists of:
   a) 'Hints Dispatcher' receives application hints for apportioning
bandwidth (communicated by the API) and sends them to the CM sender.
   b) 'Loss Detector' maintains loss statistics and informs the sender
when it detects congestion.
   c) 'Responder' maintains statistics of the number of bytes received
by each flow and participates in the probing protocol.
The CM API allows flows to determine their share of bandwidth, request
and schedule their transimissions, inform the CM about successful
transmissions, and be informed when the CM's estimate of path bandwidth
changes through a set of fucntion calls, e.g cm_request(), cmapp_send(),
cm_mtu(), cm_send(), cmapp_update(), cm_update(), cm_queury(), and
cm_close() (to close the connection and destroy all internal state).
Hence, the applications do not need to maintain any information about
the state of congestion and available bandwidth along a path. The
authors discuss 4 reasons behind their API design:
1. Put the application in control: the CM decides the rate at which each
application flow can transmit, but the application is in control of what
to transmit and deciding the relative fraction of available bandwidth to
allocate to each flow.
2. Accomodate traffic heterogeneity: the CM benefits a variety of
tarffic types. E.g., TCP, real-time.
3. Accomodate application heterogeneity: a particular application style
should not be forces (they claim TCP congection forces application to
have fewer flows).
4. Learn from the application: the API should allow applications to
provide feedback to the CM (e.g. through cm_update()).
The CM incorporates the following protocols:
1. Stable congestion control: A hybrid window-rate scheme in which the
CM maintains a congestion window that changes as the Cm learns from
active flows about the state of the network and increases the rates
allocated to them to probe for spare capacity. Upon a loss, the
congestion window is halved, and when congestion persists, the rate
drops to a small value forcing slow-start.
2. Loss-resilient protocol to periodically elicit feedback from
receivers: The CM uses 2 forms:
   a) Application Notification when the receiver application or
transport protocol provides feedback to the sender application which can
then pass it on to the CM.
   b) Explicit Feedback: involves modifications to the receiver to
respond to periodic probe messages from the CM sender and report losses
or ECN information to the sender. Probes are send twice every RTT
(arbitrarily chosen). The probe consists of a sequence number, the
receiver sends back the sequence number it is responding to, the one
before and the number of packets received for each flow in between these
two probes. The sender can use this to calculate congestion information
and maintain it till the next probe. The authors found some problems to
do with count-matching due to reordering of transmitted data, tried to
modify their protocol to handle this but ended up with too complex a
protocol which was not worth it.
3. Exponential Aging mechanism: when the CM does not receive a response
to a probe message in one RTT, the transmission rate is halved in each
subsequent RTT (which is actually the minimum of all observed RTTs as
maintained by the CM).
4. A scheduler to apportion bandwidth to flows. Currently a HRR
scheduler is used, but the authors say that one scheduler can be swapped
with another without affecting the rest of the system.
The authors have also added a CM packet header to help in loss and
congestion detection as well as differing between loss and reodering of
packets. A handshake allows the CM to know if the receiver is CM-enabled
and if it should include these headers of not.
Finally the paper presents simulations to show the CM enables efficient
multiplxing of logically different streams, ensuring proper congestion
behaviour for an ensemble of flows and improves consistency of
application performance. However, a consequemce of this is throughput
degradataion.

The paper proposes an idea that requires such significant change to both
the sender and receiver at the application and transport protocol layer.
I felt the paper was a bit disorganized in its writing. Also their
argument for the addition of a CM header 'because the CM already
requries receiver changes...' seemed very weak to me.
Received on Sat Oct 07 2006 - 15:32:08 EDT