From: Pravin Bhat (pravinb@u.washington.edu)
Date: Wed Oct 20 2004 - 06:04:43 PDT
Paper summary: The paper proposes a TCP like routing-protocol, XCP, with the
key modification of using a router-centric congestion avoidance mechanism to
ensure near-optimal link utilization and fair distribution of resources.
Simulations show that XCP outperforms TCP in a wide variety of scenarios,
especially for sustained flows over high-bandwidth, high-delay networks.
Paper Strengths:
The key strength of the paper is the results. XCP consistently proves to be
a superior routing-protocol in comparison to TCP and its variants in terms of
efficiency and fairness under varying conditions. Its robustness and stability
in the face of diverse network capacities, topology, delay, number of
concurrent flows, and burstiness of network-traffic is simply phenomenal. Such
an extensive comparison is also a credit to the thoroughness of the authors.
The paper's impressive results are probably rooted in its strong theoretical
foundation. The protocol is analyzed using control theory. The exact conditions
for its stability are provided in terms of valid ranges for any constants used
by the protocol - eliminating all the parameter tuning that is often required
to keep TCP performing optimally.
By placing the throttle for congestion windows in the routers the protocol
eliminates almost all packet drops and at the same time it allows applications
to aggressively utilize a large network-capacity, when available, without
running the risk of destabilizing the network.
XCP uses an explicit signal for congestion instead of an implicit signal like dropped packets which can occur due to reasons besides congestion -
i.e. transmission errors. Not having to deal with such ambiguity
allows XCP to adapt to a wider ranger of networks (i.e. wireless networks).
By moving away from an end-centric system, XCP can provide stronger protection
against malicious or compromised users. This model also allows XCP to better
provide guarantees like fair utilization of network resources and
features like quality of service (QoS).
Limitations and Areas for improvement:
Security is concern that comes to mind. Lets say that a malicious user
gets access to a link at the edge of a network. Under TCP this user could
hurt the traffic being routed to and from the machines in the network
by messing with the packets. However with XCP the user can hurt other
routers and networks by simply setting the congestion window updates on all
packet headers to a high value - in turn getting every machine in the network
to launch a denial of service attack. Conversely setting the window update
to a really low value would cause all the machines in the network to
voluntarily slow down to a throughput of one packet per RTT. Note that such
an attack would not be possible by simply severing a link if alternate routes
exist.
While XCP rids TCP of fatal assumptions like - "a dropped packet is a signal
for congestion", XCP continues to use certain assumptions that could change
in the future. One such assumption is that once a connection is established
packets are routed through static routes (since the congestion-header is
only valid for routers on a given route). It's possible that new routing
schemes that use variable path routing might become dominant in the future.
While the authors make their best effort to propose a deployment plan, the
fact remains that such a drastic shift in the routing-model is going to
be hard to deploy over the entire internet. If not XCP would have been
deployed by now considering the results it has to offer.
Future work:
Deployment: Work needs to be done to make deployment as simple as possible
and to evangelize the merits of the protocol to jump-start a deployment
effort.
Security: XCP moves certain features from host machines to routers. In that
sense routers become the new "end". While malicious ends are less likely in
this model XCP should still be analyzed in terms of its vulnerability to
misbehaving routers.
This archive was generated by hypermail 2.1.6 : Wed Oct 20 2004 - 06:04:44 PDT