[Olsr-dev] reliable vs unreliable updates

[Juliusz Chroboczek]

> I'm writing this because I am interested in understanding why mesh routing
> protocols send unreliable/unacknowledged TC updates. Modern day wired
> routing protocols such as OSPF and EIGRP both use reliable updates. As OLSR
> is designed for unreliable wireless networks it therefore seems a little
> strange that we have moved to unreliable updates.

To me, it's not as clear as Harald and Henning are making it to be.

As usual, there's a trade-off here.  Reliable deltas (as in BGP, OLSR
and EIGRP) are a big win on a large, stable network.   They are not as
big a feature on wireless networks, where the topology tends to change
all the time (at least if you measure link quality).

If you're not careful, reliable deltas have a rather subtle race
condition: what happens when you've sent a reliable update, but the
other end crashes before it acks it?  You'll typically keep resending
the update until a timeout, which causes some useless traffic.  That's
the essence of the « SIA » issue in EIGRP.

Additionally, as Harald mentioned, the current thinking is not to send
stuff reliably, but to make sure that even if updates are lost, things
continue working, possibly in a somewhat suboptimal manner.  Harald is
referring to a strategy that aims to detect missing data and correct it
in link-state algorithms, but I personally prefer strategies where the
integrity of the network is preserved even when some nodes are operating
with obsolete information (as is done in DSDV, Babel, and to a certain
extent EIGRP).

I'd really like to see some work on reliable updates in mesh networks;
it is quite possible that it would turn out to be a good idea, at least
in sparse networks.  Note that Babel does include a mechanism for
optional reliable updates (Section 2.7.2 of [1]), but it is not
implemented in the current version, and hence its effectiveness has
never been evaluated.

                                        Juliusz