Re: [B.A.T.M.A.N.] Unterstanding gateway-mode - why do nodes have a "sticky" gateway

[NicoEchániz <nicoechaniz@altermundi.net>]

Hi all,

I wanted to share this proposal we arrived at after discussion with some AlterMundi hackers, so we can discuss it during our future IRC session. I've previously shared it with yanosz, who had some observations that he can better explain, but agreed on this initial assumption which triggered the proposal:

The scenario we see in our networks is that over a certain link quality which is considered acceptable, we want the clients to choose the gw with better bandwidth. So if for example this quality floor is TQ 100, then if a gw has 6Mbit/s advertised b/w and another has 3Mbit/s, the clients that see this gateways with a TQ above 100 will choose the faster one between them.


We observed that in the current implementation, advertized gateway throughput is used to modify the final gw selection by publishing unrealistic bandwidth. The proposal tries to fix this, as well as the "dynamic switching" for selection class 1. Looking at the current code involved we also believe it would allow to make the implementation simpler.


This would be the proposed options:

gw_sel_class [1,2]
 1 will consider gw throughput, 2 will only consider TQ. When using selection class 1, clients will switch gateways if one with better throughput becomes available and reachable with a TQ above gw_tq_floor (see below). Defaults to 2.

gw_tq_floor
 Only relevant for gw_sel_class 1. Above this TQ floor, the gw with the
best advertised throughput will be chosen.* Defaults to 100(?)

gw_tq_threshold
 TQ delta that triggers a gw switch in the client. If gw_sel_class is 1,
the tq_threshold will only be considered to choose between two or more
gateways advertising the same winning throughput on the net. Defaults to 20.



The old config options would be deprecated but to maintain backwards compatibility, if gw_sel_class is set to... say 20, it would be internally translated as:
gw_sel_class 2
gw_tq_threshold 20


I believe this proposal maintains current behavior for sel_class>1 while IMHO it better handles sel_class 1.


Cheers,
NicoEchániz


* if no gw can be reached with TQ over the tq_floor, the client should choose one anyway, probably the one with better TQ; this should be discussed further. Another option would be to choose no gateway and the network admins should fix the net :) or lower the tq_floor values.