Summary: An Integrated Congestion Management Architecture for Internet Hosts

This paper describes a new sublayer of the network component of the
traditional four-layer network stack. The purpose of this component is to
handle congestion control. Placing congestion control in its own sublayer
beneath the transport layer (where is usually resides) brings a number of
benefits:

a) All flows are congestion controlled, even if they are not TCP. This frees
applications that don't want the reliable stream semantics of TCP from having
to implement their own congestion control on top of a protocol with weaker
guarantees (ie. UDP). It also protects the network from software which uses
non-TCP protocols without any regard to congestion control.

b) It allows congestion control to be done on a host-to-host basis, rather
than per-flow. The paper provides evidence that with TCP you can have a
number of flows stabilize at very different throughputs even though they are
between the same two hosts. This is because the flows begin to compete with
each other. Using the unified congestion manager layer presented in this
paper, a sender can co-ordinate all of the flows heading to the same machine
in order to optimize throughput.

I thought the concepts of "Application Level Framing" referenced in this paper
were very interesting. The concept seems to argue that modelling the network
as a rigid protocol stack doesn't offer applications enough flexibility. It
isn't enough to allow applications to simply dump data into the network layer
and subsequently forget about it.

Instead, ALF suggests that the application should be much more integrated with
the network software. This allows an application to dynamically tailor its
network activity to current conditions. For example, using the CM, an
application requests permission to send, and the CM later calls back into the
application with information on the current RTT time and exactly how much
data may now be sent. It is only at this point that an application must
decide exactly what data to pass into the network.

Although this approach can substantially complicate application design, it
does open several interesting possibilities. One interesting example
presented was a web server that sent lower-quality images when it detected
that it was under high congestion. As long as a "simple" programming model
is retained for applications that don't require the extra functionality, I
think this could be a very interesting and useful way of designing a network
API.
Received on Tue Oct 10 2006 - 00:59:22 EDT