[Olsr-dev] [PATCH v3 1/1] smart gateway: add threshold configuration parameter

Teco Boot (spam-protected)
Wed Dec 14 11:52:20 CET 2011

A default of 1.0 is bad: flapping NAPT and broken connections.
A default of 0.0 is bad: stick to SGW with bad path: lousy 
(thus broken) connectivity.
So we have to pick something in between.

I used NATthreshold 0.9. This was already loopy. Lower is bad. 
But I want lower, having a more stable NAPT.

I'm fine with 0.5. But what I saw quite frequently: nearby candidate 
GW with ETX=1 and selected GW with lousy path: 1.<high>. I do not
recommend such lousy performance as default. What happens when I 
restart selected GW? Hint: see below.
s-  1.000   1       120     1000    ipv4(n) -       -
u-  1.816   1       120     1000    ipv4(n) -       -

Related topic: ETX needs improvement:
 - links are not symmetric, and L2-ack loss is very unlikely
 - links with ETX higher than 1.3 doesn't make me happy
Expect some work on this later. With new LinkQualityAlgorithm
plugin, using L2 feedback in addition to loss. Based on Hennings 


(spam-protected):~# ping -s 1000
PING ( 1000(1028) bytes of data.
1008 bytes from icmp_req=6 ttl=64 time=41.9 ms
1008 bytes from icmp_req=13 ttl=64 time=47.9 ms
1008 bytes from icmp_req=14 ttl=64 time=76.3 ms
1008 bytes from icmp_req=15 ttl=64 time=41.4 ms
1008 bytes from icmp_req=16 ttl=62 time=28.0 ms
--- ping statistics ---
16 packets transmitted, 5 received, 68% packet loss, time 15008ms
rtt min/avg/max/mdev = 28.059/47.152/76.330/15.977 ms

Op 14 dec. 2011, om 11:14 heeft Ferry Huberts het volgende geschreven:

> On 12/14/2011 11:03 AM, Markus Kittenberger wrote:
>> btw nice SGW gets finally tested/debugged/fixed,..
>> and ACK, i would not really consider SGW as "very" stable in olsrd,..
>> but ...
>> On Tue, Dec 13, 2011 at 10:31 AM, Ferry Huberts <(spam-protected)
>> <mailto:(spam-protected)>> wrote:
>> how about changing the default to 67 percent for the threshold?
>>    we would really like to change that.
>> ... afair the main idea/reasoning for SmartGateways in first place, was
>> to provide a solution for users suffering from changing gateways (which
>> are doing NAT), leading to changing "public" ips.
>> (i.e the same issue Nat-Threshold was aimed at, but ...)
>> or are there new (widely/predominantly used) SGW usecases, i am not
>> aware of?
> we have _highly_ mobile adhoc networks (e.g. vehicles driving around).
> therefore we'd like to always choose the best gateway (with some obvious
> hysteresis/delay)
>> imho the "only" behaviour matching the original goal, is to change the
>> gateway only if the old one ist lost (or maybe got extremely bad/costly),.. 
>> i.e. 0 (or a very low value) would be the "correct" default for the
>> SGW-Threshold
>> but imho 0.67 is not!
>> as it might even cause switching between gateways every some minutes in
>> some spots in some networks,..
> in a static setup (like in a city) this should not cause switching under
> normal circumstances, while enabling the highly mobile case to function
> per default as well. win-win
> -- 
> Ferry Huberts
> -- 
> Olsr-dev mailing list
> (spam-protected)
> https://lists.olsr.org/mailman/listinfo/olsr-dev

More information about the Olsr-dev mailing list