[Olsr-dev] Little change to olsr core

Teco Boot (spam-protected)
Fri Jul 27 13:01:04 CEST 2012


Op 27 jul. 2012, om 11:28 heeft Henning Rogge het volgende geschreven:

> The current core doesn't support asymmetric links.
Could be.
When all nodes send out their own TC (no topology reduction), all
with outbound costs, what is the problem?

> I am not even sure
> the Dijkstra implementation can handle it.
Should be fixed.

> Setting your local ETX to "a" but having your neighbor announcing an
> ETX of "b" sounds like a lot of trouble.
But this is normal during convergence. Local ETX is changing more
rapidly than arrived messages, send out with fixed intervals.
(yes, there could be loops)

> We should not implement
> something like this before checking the Dijkstra very carefully.
OK, this has to be checked.

> Whats about this, instead of implementing a static LQ/ETX, we could
> allow a user to define a maximum LQ for a link (between 0 and 1).
> Calculation will be running as normal, just that it doesn't go higher
> than a certain value.
We can make a new lq_plugin, for experimentation. Based on 
lq_plugin_default_ffeth. All enhancements are configured, so default 
is 100% compatible. Messages should be compatible too, for mixed mode 
operation. Candidate enhancements:
 - hysteresis (suppress frequent small changes), with config option 
   (LQHYST 0.00 - 0.99)
 - factor for LQ-WEIGHT and NLQ-WEIGHT, so we have asymmetric costs. 
   NLQ is (far) more important than LQ. Sensible value: 0.80 for NLQ-WEIGHT, 
   0.20 for LQ-WEIGHT.
 - LQ window size
 - max costs and max LQ thresholds
 - mixing available L2 feedback with LQ, such as RSSI / DLEP info.
 - a more exponential increase of costs, so links with higher losses 
   have much higher costs could be something like 
   ( 255 * 255 * 255 ) / ( LQ * NLQ * NLQ)


> 
> Henning
> 
> On Fri, Jul 27, 2012 at 10:17 AM, ZioPRoTo (Saverio Proto)
> <(spam-protected)> wrote:
>>> @Saverio: why is the LQ multiplier not enough?
>> 
>> 1) First problem is that I cannot configure asymetric cost:
>> in the current implementation the ETX of the link is the same in both
>> directions (you can have a little shift because cost from A to B is
>> computed on A and cost from B to A is computed on B, but results
>> should be the same).
What happens when unequal LQ multipliers are configured, on A and B?

>> 
>> 2) Second problem is granular costs
>> the ETX using multipliers will be
>> 
>> ETX = 1 / ( LQa  * multA * LQb * multB)
I guess it is ETX =  ( 255 * 255 ) / ( LQa  * multA * LQb * multB)

Yes, this may improve optimal route calculation.

>> 
>> when the link is perfect I can simplify in
>> 
>> ETX = 1 / (multA * multB)
?
This will follow automatically.

>> 
>> But the is very tricky to configure ETX of 18,19,20,21,22,23 adjusting
>> these two multipliers values on the two routers.
I don't follow.

>> 
>> Moreover a packet loss on the link will add a multiplicating factor to
>> my link, that most of the time will go quickly above LINK_COST_BROKEN
Max_costs needs a parameter.

Teco


>> 
>> I would like to set ETX = 18, and then just delete the link if the
>> normal computation of ETX without multiplier goes above
>> LINK_COST_BROKEN
>> 
>> Saverio
> 
> 
> 
> -- 
> Steven Hawkings about cosmic inflation: "An increase of billions of
> billions of percent in a tiny fraction of a second. Of course, that
> was before the present government."





More information about the Olsr-dev mailing list