Subject: Re: Your recent I-D

From: [email-masked] (Joseph P. Macker)
Date: Tue, 7 Nov 1995 01:20:40 -0500

I am reposting Noel's note to the mmnet list for group benefit.
>Date: Mon, 6 Nov 95 12:27:52 -0500
>From: [email-masked] (Noel Chiappa)
>To: [email-masked]
>Subject: Re: Your recent I-D
>Cc: [email-masked]
>
>    I shall read your longish message on "soft state" definition.
>
>Lixia and I are a having a conversation about "soft state" on the "flows"
>list, which is dedicated to high-level discussions about the general concept
>of flows (i.e. it's not for any specific protocol using this idea).
>
>    > I'm dubious that link-state approaches to routing in a dynamic
>    > environment are really that much inferior to your new approach, in terms
>    > of their dynamicity.
>
>By which I meant their ability to respond quickly to a change to create
>workable forwarding tables.
>
>    One of the key points of the draft-RFC is to point out the "congestion
>    enhancing" effects of shortest path routing in ... actually any
>    environment.
>
>This is a good point. SP routing has all sorts of problems with this,
>including (when, as in the LS ARPAnet routing, load is included in the
>metric) causing oscillations in load patterns as traffic patterns chase their
>own tail, going after the unloaded parts of the fabric.
>
>    There is architectural design issue relating to the expected number of
>    mobile routers and the topology change rate.
>
>Exactly; the size and change rate are the two single most important factors in
>any routing system. Let either one get big enough, and you have to go to
>hierarchical routing to solve the problem.
>
>Once you have hierarchy, of course, you can dial in the variables of protocol
>overhead (of whatever design you have chosen), acceptable overhead levels, and
>change rate, and out comes your maximum area size. This makes the choice of
>algorithm less critical; if a design which has the characteristics you want
>has a higher overhead in some important metric (bandwidth, memory, CPU,
>stabilization time, etc) than another less desireable one, you just crank down
>on the area size and go on your way.
>
>Of course, introducing areas has negative consequences of its own, principally
>non-optimal routes, but that's life, and another large can of worms...
>
>    Other routing approaches besides link-state MAY have some performance
>    benefit here.
>
>Umm. Any routing design includes tradeoffs from one area to another. The
>design in your I-D has some interesting features. I was just somewhat
>questioning about the claims that it reacted faster than LS, and used less
>bandwidth, since that wasn't the perception I had after looking at it.
>
>    Our intention was to raise these issues for the community and stimulate
>    more in-depth research and discussion.
>
>Routing in highly mobile environments has not been given as much attention in
>the IETF environment as it could. However, many of the people working on
>Nimrod at BBN have experience in this area, from work on SURAN, and I think
>application to the mobile area has been considered by some of them.
>
>    Noel, FYI we have mailing for discussion of this RFC and relating issue
>    pertaining to the upcoming BOF.
>
>I signed up. If you guys are interested, the Nimrod WG mailing list can be
>joined by sending mail to "[email-masked]", which I think is
>probably a human.
>
>    Thanks for your comments,
>
>Sure, hope they were useful.
>
>        Noel
>
>

    _/      _/ _/_/_/_/  _/       Joseph P. Macker, Code 5523
   _/_/    _/ _/     _/ _/        Naval Research Laboratory
  _/  _/  _/ _/_/_/_/  _/         Washington DC 20375-5337
 _/    _/_/ _/   _/   _/          [email-masked]
_/      _/ _/     _/ _/_/_/_/     http://tang.itd.nrl.navy.mil/macker.html