An Integrated Congestion Management Architecture for Internet Hosts

Paper Review: An Integrated Congestion Management Architecture for
Internet Hosts

The paper presents an end-to-end scheme for managing Internet
congestion motivated by changing trends in traffic. Their Congestion
Manager (CM) is integrated across all applications and sits below the
transport layer protocols.

The paper explains that web traffic predominantly characterized by
multiple short TCP connections in parallel. The nature of these
connections prevents TCP from stabilizing and causes the parallel
flows to compete for resources. Also, the growth of multimedia
content streaming on the Internet is leading to increasing use of UDP
thus requiring congestion control across transport layer protocols.
In their scheme the CM controls the transmissions and maintains
network statistics. This enables the flows to work cooperatively
rather than in isolation.

The API was designed with the following four design guidelines:
- The application is in control
- Accommodates all variations of traffic
- Accommodates all variations of application development rather than
enforcing a particular style
- Learn information about network conditions by letting the
application notify the API

Although the scheme is a window-based one, it utilizes a rate-based
traffic shaper in its congestion control efforts. This prevents the
bursty nature of Internet traffic which could significantly improve on
congestion, packet loss and throughput. In the face of congestion,
the sender uses exponential aging to reduce the rate. This results in
similar throughput losses as TCP while allowing the sender to continue
transmitting.

The CM was shown to ensure that a group of flows between the same
hosts behaved in a ?socially proper way?. In the face of congestion,
the CM correctly reduced the throughput of each of the flows.
Consistency and predictability of performance was also shown to be
provided.

This work seems to have some very interesting upsides. First, it is
one of the few congestion control schemes that is taking an end-to-end
approach and operating below the transport layer. Therefore it will
not be the case that only TCP will have to adhere to congestion
controlling mechanisms. Secondly, the CM API will aid new Internet
application development by providing network information and
statistics to the applications without significant added effort.

Aside from these benefits, there were several questions that come to
mind after reading this work. First, how will it be adopted? What is
the incentive to use the CM if not everyone is using it? How can the
creators motivate Operating Systems developers to use the CM in their
implementations? The second type of question that comes to mind is
the performance of the scheme. Will the window-based scheme of the CM
interfere with the window-based TCP scheme? Will the overhead caused
by the CM packet header affect performance? Also, does the CM stifle
the original goal of UDP - being a best-effort service without
congestion control or reliability? Finally, can malicious
applications fool the API into providing them with more than their
fair share of bandwidth?

All of these questions need to be addressed as there is a lot that is
unclear about the work. Although the paper was written well in
general, one complaint would be the scattering of implementation
details throughout the paper. The details about the API calls should
be collected into one section as they seem to detract from the
high-level explanation of the algorithm and protocol.

-- Nadeem Abji
Received on Tue Oct 10 2006 - 02:30:29 EDT