(no subject)

This paper proposes a novel framework for managing network congestion
from an end-to-end perspective. This paper presents an end-system
architecture centered around a Congestion Manager that ensures proper
congestion behavior and allows applications to easily adapt to
network congestion. It uses a window-based control algorithm, a
scheduler to regulate transmissions, and a lightweight protocol to
elicit feedback from receivers.

Internet traffic patterns have been changing rapidly. Web workloads
stress network congestion control heavily. Some commercial products
"accelerate" web downloads by turning off or changing TCP's
congestion control in unknown and potentially dangerous ways.
Moreover, several increasingly popular realtime streaming
applications run over UDP using their own user-level transport
protocols for good application performance, but do not adapt or react
properly to network congestion. All these trends threaten the long-
term stability of the Internet. The paper work attempts to overcome
these problems by developing a novel framework for managing network
congestion from an end-to-end perspective.

The resulting framework is independent of specific applications and
transport protocols, but provides the ability for different flows to
perform shared state learning. The core of the designed architecture
the paper proposed is the Congestion Manager. It maintains network
statistics and orchestrates data transmissions governed by robust
control principles. Internally, the CM ensures stable network
behavior by the sender, implements a robust and lightweight protocol
to elicit feedback from receivers about losses and status, and
schedules data transmissions by apportioning available capacity
between different active flows.

At the sender, the congestion manager maintains network statistics on
a per-receiver basis, performs congestion avoidance and control,
schedules transmissions, and exposes an API based on ALF principles
to enable applications to adapt to congestion. At the receiver, the
CM maintains loss statistics, responds to sender probes, and exposes
an API for applications to provide hints on apportioning bandwidth.

After analysis and simulation, then comes to the conclusion that the
full benefits of the CM architecture require changes to both senders
and receivers.

The paper is well written, with fine and clear presentation.
Obviously, it is a novel framework. The main contribution is that
authors propose an Integrated mechanism through which various
applications could adapt the network and get congestion control. It's
totally new and a good work with originality. However, there are some
problems in the paper and the framework.

The whole framework seems too complicated. I think authors should
think about the balance between functions and cost. Although this
framework could integrate lots of applications and protocols in the
transport layer, and it's true it's a flexible framework, it still
seems too complicated and hard to deploy. Moreover, only if both
sender and receiver use this framework, it could get the full
benefits. That means we should redeploy the whole transport layer
protocols.

The simulation and performance analysis part in this paper seems week
to convince the readers. This framework is a big project. Authors
should test and do experiment both by simulation and real Internet
environment.

Another problem is that this framework does not consider the fairness
problem, at lease, it's not presented in the paper in detail. It's a
big problem, because as the development of the networks, many kinds
of applications or protocols want to compete the bandwidth and have
multiple concurrent. How to solve the fairness problem should be
important in this framework.

In this paper, it seems it still does not solve the problem about the
congestion control for UDP. Nowadays, the applications using UDP face
the problems of congestion avoidance and control. Although this
framework provides the mechanism to congestion control, for UDP
application, it's not described clearly. Is it possible to add some
mechanism to enhance UDP congestion control?
Received on Sun Oct 08 2006 - 15:34:08 EDT