Re: Comments on draft-spagnolo-manet-ospf-design-00.txt

[Tony Przygienda <prz at XEBEO.COM>]

Richard Ogier wrote:

> Gary,
>
> Please see my comments below.


Richard, Gary, Russ,

chewed my way through the recent threads and simulation results and here
are my 'meta'-comments.
From simple to hard:

a) The simulation is considering relatively-low-rate-of-neighbor-change
scenarios to jump to
the conclusion that incremental-hellos are of little value (as has been
observed by other people).
On one hand, I agree obviously with the argument that with higher
density of nodes can cause
much higher rates of neighbor change as well as neighbor numbers, on the
other hand, the
complexity of the proposals is low enough to make the incremental-hellos
a belts-and-suspenders
optimization kind of thing, even if the link bandwidth overhead will not
be staggering.
Finally, I didn't drill through the proof of TBRPF to have an opinion as
to the merits
of either proposal but Russ's stuff looks simple enough ;-)
b) Obviously flooding is a more interesting topic and I liked to read
all the interesting tossing of ideas.
i) As first observation, the predicting of transitions between
acknowledgable and non-to-be-acked LSAs
will be hard (more in c) or rather prohibitive in terms of computing
power if done well.
ii) As second, having two different flooding mechanisms flipping will
make something that is very fragile doubly so
so it should be probably kept as a life-saving mechanism only.
iii) Third, from my experience with OSPF & ISIS flooding implementation
and deployment I observed that ISIS
flooding tended to be somehow simpler to implement and debug and keep
stable in the field. BDR did not buy much
in practical deployment and the initial-TDBX was somehow faster but
insignificantly so. My point is probably
that if you find that unreliable flooding is in most cases a good or
better solution, it may not be worth to
build a hybrid or tweak reliable flooding much (albeit the protocol
definitely very much deviates from OSPF then ;-)
The cost is however that you have to shape the flooding on the link (the
famous 33msec timer that can
be deadly for a large-scale implementatoin if done naively) but that can
be implemented using proper
leaky-bucket techniques fairly cheaply.
The argument about mobile-non-moving networks is strange to me (I mean
the sensors network thing) since
it seems to go into the direction of an orthogonal, low link quality-low
bandwith routing rather than mobile routing (kind like ALSR).
iv) Fourth, prunning of the flooding tree (MBR work, flooding spanning
tree and such) is hard to get right
and I don't know which of the ideas have most merit. I have to read and
think more here.
The MBR looks reasonable to me (albeit the algorithms
to be run are a tad convoluted), I also always liked the
flooding-spanning-tree idea with a token passed
around to generate the spanning tree and am surprised nobody picked up
on that.
c) Finally, I personally think from having seen it in another context
that the 'predicting future' to know when to ACK
and when not is
bound to either fail or end up in some pretty heavy math that cannot be
run real-time. Either we're dealing
with something that is unpredictable (in terms of self-similarity
beta=0.5), kind like exponential distribution or
otherwise we can think about stuff in terms of self-similar pattern
(since I do not believe that a single correlation
over a well-known time-scale can be observed). If we know the beta (or
measure it, which is
a tad expensive computationally), there are methods to detect the
time-scale of trends that we encounter (and therefore
predict the future but only in terms of absolute beta, you know that the
trend will persist with some probability
but you cannot know which direction it is heading) and based on that an
educated guess could be taken. But this
again takes some serious computing power which I cannot believe will pay
in mobile nodes just to optimize flooding. And
in case you can do all that, yes, the at-source-squelching approach
works much better that receiver based for
couple of reasons I won't dwell further into.

As a 'meta'-'meta' in connection to the group's meeting (sorry for this
time, I try to be in D.C.) I think even more
than before that the wireless extensions should be kept in a special
OSPF area. The ideas passed around are radical enough
to almost certainly make a general-interface-type-solution overburdened
and the mix of different interfaces in same
area very fragile deployment-wise.

thanks

-- tony