Review - MCA

From: Ivan Hernandez <ivanxx_at_gmail.com>
Date: Sat, 7 Oct 2006 22:41:47 -0400

Review of An Integrated Congestion Management Architecture for Internet Hosts
by Ivan Hernández

The paper presents a Congestion Management Architecture (CMA). The
architecture uses a Congestion Manager (CM) that will be running in
the end hosts. In the transmitter, the CM will gather network
information and will use this to vary bandwidth between different
network flows. In order to do this the transmitter implements three
modules Prober, Congestion Controller and Flow Scheduler. In the
receiver, the CM will gather statistics regarding to packet lost and
bytes received by flow, then will send this information as feedback to
the sender; the implementation is optional. The new architecture adds
a new layer between IP and the transport layer and defines the new
header (through this header, the sender and receiver will exchange the
information and feedback). Additionally, the new architecture provides
an API that applications and transport protocols can use to query the
network statistics and use them to shape the amount of traffic to send
per flow.

The paper states that due the Application-Level Framing principle
(ALF), the CM permits the applications to have the final say in
deciding what to transmit at each point of time and what fraction of
bandwidth to allocate to each flow. This means that now the
application has to take the decision on how to manage the traffic! The
ALF principle states that networking mechanisms should be coordinated
with application-level objectives. For me a clear a good example of
this principle is preferential treatment of ip telephony flows thanks
to the use of the IP ToS; and not good example is the stated in the
paper. On the other hand, the paper says that frees applications from
having to maintain information about the state of congestion an
available bandwidth along any path, but applications do not have
this information; furthermore, the CM provides this information to the
applications through the CM API.

The paper starts describing the problem of congestion control with two
examples of TCP and UDP traffic. Then, the paper claims that with the
new CMA all transport protocols will be benefited. Nevertheless, the
architecture prototype just works on TCP. A similar issue is presented
in the discussion of section 4.5, they do not have a complete
prototype.

I think that the main contribution of the paper is the addition of a
new layer, between network and transport layer, that only provides
congestion control. With these TCP will only have to provide reliable
reliable and in-order delivery of data. We have not talk in class
about how UDP traffic either impacts or gets affected about all this
traffic, but as a guess I think that UDP traffic will get benefited
about a minimal congestion control service (because there would be
less packet lost). I think that this congestion control should have
the characteristic of being disabled for specific scenarios with
predictable traffic, for instance a network where most of the senders
are sensors (small devices) and the receiver is a server that gathers
information of the sensors. Finally, I think that the idea is fine --
it should be considered --, nevertheless is bad presented.

I did not like this paper. The authors started with a very broad
description of their architecture and their prototype was very limited
and did not provide all the described characteristics. Additionally,
the results of the simulations does not provide cogent evidence
about the benefits of using the CMA.
Received on Sat Oct 07 2006 - 22:41:57 EDT

This archive was generated by hypermail 2.2.0 : Sun Oct 08 2006 - 15:34:11 EDT