[Olsr-dev] Bug in function olsr_tc_update_edge ?

[sebastian sauer]

Tue 19 Feb 2008 10:09, Hannes Gredler wrote:
> 
> 
> Henning Rogge wrote:
> > Am Montag 18 Februar 2008 23:39:08 schrieb Hannes Gredler:
> >> hi eric,
> >>
> >> your observation is correct, now asking what is the right fix ?
> >>
> >> we are getting in the waters of system design here.
> >>
> >> the more interesting question to ask is why does a node
> >> emit a less than 10 percent change and flood the TC throughout
> >> the network in spite that everyone will not trigger a SPF
> >> calculation ?
> >>
> >> IMO the right thing to do, sender should hold-back the information
> >> locally and once the change is significant enough, flood it
>  >
> > If we do this we have problems with new nodes... if nodes hold their TCs back 
> > until a significant change, new nodes will not know this node until it 
> > release a TC.
> 
> i'd like to decouple the two issues.
> 
> the first is a correctness issue
hell, yes :) i would even say it's a bunch of correctness issues, and
hennig may have a different opinion than i but i disagree that the ETX/LQ
in the MIT paper suffers from the same correctness issues.
it's just us.

and yes, you got me, i'm mixing up here a little bit; hi-jacking this
particular "correctness issue" for my favorite claim that the olsrd LQ
implementation is voodoo. ;)
but if you look at the code, you'll see these correctness issues all
relate mostly from this strange way the linkquality is implemented.

fixing it in a sound and clean way without breaking some of the existing
end-user functionality is tough thou. :( 

> and the second (new node starting up) can
> be fixed by a periodic resync of the TC DB using a protocol extension called "CSN",
> that i want to implement in the 0.5.6-0.5.7 time frame.
i _think_ [0] this is really a good thing to implement.


cheers,
s.

[0] unlike the linkquality stuff, network protocol design/implementation is 
not my field of expertise