[Babel-users] [Henning Rogge] Re: Ideas about Babel

[Henning Rogge]

On Dienstag 23 Dezember 2008 18:22:27 Juliusz Chroboczek wrote:
Just as a comment, I'm using the following file as my only source of 
information about Babel:
http://www.pps.jussieu.fr/~jch/software/babel/draft-chroboczek-babel-
unpublished.txt

I noticed that it mentions acknowledged packages, but does not mention how 
they are handled/retransmitted and how the internal databases will be changed 
when retransmissions/acknowledgements fail.

> >> Section 3.4.1 of the protocol spec, which is implemented in the function
> >> update_neighbour in the Babel sample implementation.
> >
> > Hmm... on a first look it does seem to be a straight forward Hello
> > mechanism with adaptive timings, which are allowed in NHDP. I think
> > I even remember NHDP talk about constraints how you can change the data
> > rate and tell it your neighbors correctly.
>
> Section 5.3 of the NHDP draft.  Unless I'm missing something, it doesn't
> reliably detect changes in the hello interval in the presence of packet
> loss (it will mis-compute the link quality in that case).  Babel doesn't
> have that issue.
You are mixing multiple things together...

NHDP is about link sensing and construction of symmetric link 2-hop neighbor 
informations. It's not about metric calculation.

The only timing parameter NHDP cares about is the "validity time"... all other 
time values are optional, but not necessary for NHDP itself (but maybe useful 
for protocols based on NHDP).

If the routing protocol wants to use the "hello interval" value to calculate a 
link quality, it should implement some kind of "graceful fallback" if the 
value was changed but we missed the first package. But that's not the job of 
the NHDP RFC.

> >> I'd rather you explained how OLSRv2 solves the problems of mis-behaviour
> >> of link-state in unstable networks.  I do understand the mechanisms that
> >> avoid this misbehaviour in OSPF.  I've seen no such mechanisms in
> >> OLSRv2.
> >
> > Unstable links should be handled on a link level... just create a routing
> > metric that add a penalty to unstable link so you try to use better
> > links.
>
> That is not the issue.
>
> In the presence of instabilities in the network topology, the link-state
> databases of different nodes become unsynchronised.  In the presence of
> packet loss, this desynchronisation may persist for relatively long periods
> of time.  Given enough instability and packet loss, the link-state
> databases never get a chance to synchronise.
>
> The SPF algorithm is not a distributed algorithm, it's a replicated one.
> Hence, it creates routing loops and other pathologies in the presence of
> desynchronised link-state databases.
>
> OSPF and IS-IS deal with that by using a reliable protocol for flooding of
> LSAs, which ensures timely resynchronisation.
>
> EIGRP, DSDV, AODV and Babel deal with that by using a distributed algorithm
> that behaves well even when the data is desynchronised.
>
> Please point me at the place in the OLSRv2 spec where they either deal with
> the issue of desynchronised link-state databases, or ensure that the
> link-state databases will resynchronise in a timely manner.
resynchronization in OLSR is done through regular floods of TCs and timeout 
values. If you don't get an update you throw away the information after some 
time.

typically it's not necessary for OLSR to have a good knowledge about nodes far 
away, you just need a rough view of the big picture, because your routing 
algorithm will only calculate the next hop.

reliable flooding is a good thing, but on a shared medium like 802.11 it can 
make the situation even worse because of more collisions between packages.

So OLSR is a tradeoff between synchronization, convergence time and airtime 
usage.

Henning

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://lists.alioth.debian.org/pipermail/babel-users/attachments/20081223/c3a62b6b/attachment-0001.pgp