[Olsr-dev] Bug in function olsr_tc_update_edge ?

[Hannes Gredler]

> 
> let me propose the following:
> 
> 1. remove the "significant" change check at the receiver side

We will need some kind of criterion to determine if a node needs to do SPF.

i'll remove all teh inbound checks altogether, since the SPFs are gated
by a backofftimer no harm will be done ...

If nothing changes at all in the TC database, it is pointless to do SPF. 
We must all help in saving on CO2 :-)

commencing a SPF on the other hand does no harm either. (its the 
opposite case that creates correctness issues, right ?)


SPF backoff protection of 1000ms is good enough for keeping the
CPU load on a 200Mhz RISC embedded CPU to 1%.
we are quite efficient these days ;-)

> 2. mitigate SPF runtime going through the roof
>    by adding a 1000ms inter-SPF backoff timer.

That seems a good idea. If 400 nodes are 'spamming' their TC data every 5
seconds, we don't want to end up doing SPF 80 times/second. It would be a
good strategy to save and record the TC data for a fixed amount of time,
then recalculate the routes. The interval may even be configurable so that
it can be set to a longer value for low-power / small-CPU nodes. I think
that a route update within a second is quite fast; it could be done as slow
as once every 10 seconds, about the same order of time needed to achieve a
link quality measurement.

> 3. get CSN into the field

Could you give some background into this 'periodic resync of the TC DB 
usinga protocol extension called "CSN" '?

the  idea is basically stolen from the IS-IS (ISO10589/rfc1142) 
protocol. each IS-IS speaker periodically (10s) transmits the
LSDB headers on all interfaces (basically pair of IDs and seqnumber)

CSN serves as a soft-refresh mechanism to avoid nodes spamming
their network with no-change TC messages.

e.g. TC{192.168.1.1, seq 123}, {192.168.1.2, seq 124} ....
if a neighboring router detects that a neighbor has an older
seq then the it will be retransmitted with a TTL of 1.


> 4. move the "siginificant" change check to the sender before
>    pesting the world with our TC updates.

Isn't there a fixed rate (TcInterval) at which a node sends its TC 
updates into the world? Or does OLSRd have some mechanism that is used 
by a node to immediately tell the world of any changes in the TC database?

Tcinterval controls the timedomain ... i was more envisioning some
control of about the space domain i.e. the contents (read: tc_edges) itself.

/hannes