Oops, wrong paper.

Ignore my previous review...

This paper, despite what I said earlier, does not describe DCCP, but
instead describes the imaginatively name "Congestion Manager" or CM,
which is an additional network layer between TCP/UDP and IP for the
purposes of congestion management. Rather than handling congestion
on a per-flow basis, it manages congestion across all flows and
provides (in the non-TCP case) some level of application-integration
to allow applications to adapt to the network conditions.

The strength of this approach is that for multiple flows sharing the
same points of congestion, such as if the point of congestion is very
close to the end-points, as we discuss this class, or for multiple
flows connecting the same two end-points, this approach should give
better performance, as shown in their experimental results.

Regrettably, their experimental setup involves a largely linear
network topology where the above conditions will always be present.
I'd be curious to see how their approach performs when a user's flows
have considerably less overlap, such as when loading multiple web-
pages simultaneously while simultaneously chatting with a friend and
downloading files using bittorrent (bittorrent alone should result in
numerous flows with little overlap). It is not clear to me that one
heavily-congested connection to a remote server couldn't slow down
all of the other flows.

Additionally, I believe the use of an extra layer of header
information, the CM header is problematic for flows with small
packets, such as VoIP data.

While I was excited to be reading a paper that implemented congestion
control on something other than flows, I found their approach
somewhat problematic, and was also bothered by a somewhat unclear
organization in this paper. It felt as though there were two many
dissatisfying forward references, where our understanding of their
design would hinge upon something that would not be explained until
two days later. It seemed as though when introducing the initial
concept, not enough information was given up front to provide much
overall understanding.
Received on Mon Oct 09 2006 - 23:20:13 EDT