From: Craig M Prince (cmprince@cs.washington.edu)
Date: Mon Nov 01 2004 - 02:59:26 PST
Reading Review 11-01-2004
-------------------------
Craig Prince
The paper titled "The Revised ARPANET Routing Protocol" gives a careful
analysis and discussion of the packet routing mechanism used in the
ARPANET and the changes done to this mechanism to allow the network to
continue working efficiently under high load. The paper focuses
specifically on a previous and new method for calculating delay along
links (which are used by nodes to choose paths to route along).
The paper does a good job at correctly identifying the reasons for failure
in the previous algorithm. What I liked best about the given approach is
that it attempts to solve the problem by only changing the algorithm for
computing the delay between nodes. The biggest observation being that the
old method doesn't take into account how traffic will change (and the path
costs) after we send out the current path cost estimates. As a result,
oscillations could easily be setup as we over-compensate for increasing
path costs. The solution does not involve changing the underlying path
selection mechanism, but simply changes the calculation of the cost of the
various alternative paths. This restricts the choice of solutions, but
also makes the proposed solution more adoptable, since the changes are
minor and modularized.
The biggest issue I had with the paper was that the proposed solution
seemed very much ad hoc. While good evidence is given showing that the
solution workd well (via simulations etc.) -- there is little evidence
convincing that the given solution is the "best" or even a "good"
solution. What makes the authors choose the various constant values
associated with the algorithm? And are all the boundaries even necessary?
These algorithmic design choices seemed arbitrary and it would have better
if they were explained more.
This paper is another example showing real problems being addressed in the
internet. In this case, the issue was that the routing protocol was
failing under high load, and a solution was devised that required only a
small upgrade to fix the problem. Clearly if one wants changes to
protocols to be adopted, then the changes must provide clear benefit with
minimal deployment effort.
This archive was generated by hypermail 2.1.6 : Mon Nov 01 2004 - 02:59:26 PST