CM Review

This paper proposes a framework for congestion management at the sender,
designed to properly allocate network resources between concurrent flows
from different applications. The core premise is the end-to-end argument:
applications know best how to control their traffic in the face of
congestion. To this end, the Congestion Management (CM) module, described
in this paper, exposes an API for applications to provide and query
information about network conditions. Modifications are required at both
the sender and receiver for optimal results but it also allows for
incremental deployment with sender-only implementations. Such
implementations can be effective, especially when CM is used with a
transmission protocol that performs congestion control and informs the CM
(such as TCP/CM).

The Congestion Management module at the sender is composed of a flow
scheduler, a congestion controller and a prober. The congestion controller
is responsible for regulating the combined transmission rate between a
sender and receiver, using information passed to it from the application and
the congestion prober module. The flow scheduler module divides bandwidth
among the different flows and helps applications with scheduling their
transmissions using a request/call-back programming paradigm. The prober
periodically queries the receiver for congestion information.

Communication with the CM receiver module is facilitated through the use of
a CM header. This decision was made after it was shown that it was not
trivial to implement a prober to satisfy all flow monitoring requirements.
The programming paradigm for transmissions at the sender either involves the
submission of a send request followed by a call-back when the CM decides the
app should transmit or a regular buffered send which is transmitted when the
CM decides it is appropriate for the particular flow to transmit. The
actual congestion control is implemented as a hybrid of TCP-like window
based schemes and rate-based schemes in order to avoid bursts of
transmissions and to accommodate applications which provide scarce feedback
about received data. Experiments with NS simulator show that CM's rate
control and Newreno have similar throughput-loss relationships.

This approach requires alterations to TCP stacks, OS networking APIs and the
way applications are written. It could be useful for streaming applications
which currently do not implement any kind of congestion control but
implementing this system would be a significant change for any OS. We are
left with several unresolved questions such as the correct feedback
frequency rate, the reliability of the prober, and the justification for the
overhead of including CM headers (in particular for media streaming
protocols which may send many small packets.) Additionally, the simulations
performed by the authors seem somewhat lacking: they only compared this
scheme to TCP Reno and showed that it can indeed apportion bandwidth
equally. It did not investigate different network configurations, different
application requirements on the same host, network congestion environments,
and un-cooperative or malicious applications.
Received on Mon Oct 09 2006 - 16:52:24 EDT