[Olsr-dev] reliable vs unreliable updates
Sun Nov 15 11:25:31 CET 2009
Reliable updates could be useful for DB synchronizing
after a startup or manet merge. Fist goal would be fast
DB exchange, either reliable or not.
>Van: (spam-protected) [mailto:olsr-dev-
>(spam-protected)] Namens Juliusz Chroboczek
>Verzonden: zaterdag 14 november 2009 6:10
>Aan: David Murray
>Onderwerp: Re: [Olsr-dev] reliable vs unreliable updates
>> I'm writing this because I am interested in understanding why mesh
>> protocols send unreliable/unacknowledged TC updates. Modern day wired
>> routing protocols such as OSPF and EIGRP both use reliable updates. As
>> is designed for unreliable wireless networks it therefore seems a
>> 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
>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 ), but it is not
>implemented in the current version, and hence its effectiveness has
>never been evaluated.
>Olsr-dev mailing list
More information about the Olsr-dev