[B.A.T.M.A.N.] Unterstanding gateway-mode - why does node have a "sticky" gateway

[B.A.T.M.A.N.] Unterstanding gateway-mode - why does node have a "sticky" gateway

[Jan Lühr]

Hello,

I started using batman-adv's gateway mode. Sadly, I ran into some trouble - A client is connected to two gateways via vpn (fastd):
# batctl gw_mode
client (selection class: 1)

# batctl gwl
      Gateway      (#/255)           Nexthop [outgoingIF]: gw_class ... [B.A.T.M.A.N. adv 2012.4.0, MainIF/MAC: wlan0-1/f6:ec:38:e9:72:35 (bat0)]
   6a:4b:93:de:00:84 (255) 6a:4b:93:de:00:84 [  mesh-vpn]: 207 - 48MBit/48MBit
=> aa:31:0e:4a:0f:1d (254) aa:31:0e:4a:0f:1d [  mesh-vpn]:  39 - 1024KBit/1024KBit

# batctl o
[B.A.T.M.A.N. adv 2012.4.0, MainIF/MAC: wlan0-1/f6:ec:38:e9:72:35 (bat0)]
  Originator      last-seen (#/255)           Nexthop [outgoingIF]:   Potential nexthops ...
aa:31:0e:4a:0f:1d    0.500s   (255) aa:31:0e:4a:0f:1d [  mesh-vpn]: aa:31:0e:4a:0f:1d (255)
6a:4b:93:de:00:84    0.940s   (255) 6a:4b:93:de:00:84 [  mesh-vpn]: 6a:4b:93:de:00:84 (255)

The client should use 6a:4b:93:de:00:84 as a gatway, since it provides much higher data rates - however, it is stuck at aa:31:0e:4a:0f:1d.
Why is that? How can I make the client choosing 6a:4b:93:de:00:84?

Thanks in advance,
Keep smiling
yanosz

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

[NicoEchániz]

On 12/30/2012 10:16 PM, Jan Lühr wrote:
> Hello,
> 
> I started using batman-adv's gateway mode. Sadly, I ran into some trouble - A client is connected to two gateways via vpn (fastd):
> # batctl gw_mode
> client (selection class: 1)
> 
> # batctl gwl
>       Gateway      (#/255)           Nexthop [outgoingIF]: gw_class ... [B.A.T.M.A.N. adv 2012.4.0, MainIF/MAC: wlan0-1/f6:ec:38:e9:72:35 (bat0)]
>    6a:4b:93:de:00:84 (255) 6a:4b:93:de:00:84 [  mesh-vpn]: 207 - 48MBit/48MBit
> => aa:31:0e:4a:0f:1d (254) aa:31:0e:4a:0f:1d [  mesh-vpn]:  39 - 1024KBit/1024KBit
> 
> # batctl o
> [B.A.T.M.A.N. adv 2012.4.0, MainIF/MAC: wlan0-1/f6:ec:38:e9:72:35 (bat0)]
>   Originator      last-seen (#/255)           Nexthop [outgoingIF]:   Potential nexthops ...
> aa:31:0e:4a:0f:1d    0.500s   (255) aa:31:0e:4a:0f:1d [  mesh-vpn]: aa:31:0e:4a:0f:1d (255)
> 6a:4b:93:de:00:84    0.940s   (255) 6a:4b:93:de:00:84 [  mesh-vpn]: 6a:4b:93:de:00:84 (255)
> 
> The client should use 6a:4b:93:de:00:84 as a gatway, since it provides much higher data rates - however, it is stuck at aa:31:0e:4a:0f:1d.


I have observed the same behavior.

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

[Jan Lühr]

Hello,

Am 01.01.2013 um 18:25 schrieb NicoEchániz:

> On 12/30/2012 10:16 PM, Jan Lühr wrote:
>> Hello,
>> 
>> I started using batman-adv's gateway mode. Sadly, I ran into some trouble - A client is connected to two gateways via vpn (fastd):
>> # batctl gw_mode
>> client (selection class: 1)
>> 
>> # batctl gwl
>>      Gateway      (#/255)           Nexthop [outgoingIF]: gw_class ... [B.A.T.M.A.N. adv 2012.4.0, MainIF/MAC: wlan0-1/f6:ec:38:e9:72:35 (bat0)]
>>   6a:4b:93:de:00:84 (255) 6a:4b:93:de:00:84 [  mesh-vpn]: 207 - 48MBit/48MBit
>> => aa:31:0e:4a:0f:1d (254) aa:31:0e:4a:0f:1d [  mesh-vpn]:  39 - 1024KBit/1024KBit
>> 
>> # batctl o
>> [B.A.T.M.A.N. adv 2012.4.0, MainIF/MAC: wlan0-1/f6:ec:38:e9:72:35 (bat0)]
>>  Originator      last-seen (#/255)           Nexthop [outgoingIF]:   Potential nexthops ...
>> aa:31:0e:4a:0f:1d    0.500s   (255) aa:31:0e:4a:0f:1d [  mesh-vpn]: aa:31:0e:4a:0f:1d (255)
>> 6a:4b:93:de:00:84    0.940s   (255) 6a:4b:93:de:00:84 [  mesh-vpn]: 6a:4b:93:de:00:84 (255)
>> 
>> The client should use 6a:4b:93:de:00:84 as a gatway, since it provides much higher data rates - however, it is stuck at aa:31:0e:4a:0f:1d.
> 
> 
> I have observed the same behavior.


That's quite frustrating. Can I debug, when and why batman-adv actually chooses as specific gateway?

Thanks,
Keep smiling
yanosz

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

[Marek Lindner]

On Thursday, January 03, 2013 07:28:02 Jan Lühr wrote:
> >> The client should use 6a:4b:93:de:00:84 as a gatway, since it provides
> >> much higher data rates - however, it is stuck at aa:31:0e:4a:0f:1d.
> > 
> > I have observed the same behavior.
> 
> That's quite frustrating. Can I debug, when and why batman-adv actually
> chooses as specific gateway?

Yes, you can. Enable the batman-adv debug log at compile and runtime. While 
retrieving the 'batman' log messages you should see something like:
Adding route to gateway ..
Changing route to gateway ..
Found new gateway ..
etc

Maybe you can post the result here ?

Cheers,
Marek

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

[Jan Lühr]

Hello,

Am 03.01.2013 um 02:57 schrieb Marek Lindner:

> On Thursday, January 03, 2013 07:28:02 Jan Lühr wrote:
>>>> The client should use 6a:4b:93:de:00:84 as a gatway, since it provides
>>>> much higher data rates - however, it is stuck at aa:31:0e:4a:0f:1d.
>>> 
>>> I have observed the same behavior.
>> 
>> That's quite frustrating. Can I debug, when and why batman-adv actually
>> chooses as specific gateway?
> 
> Yes, you can. Enable the batman-adv debug log at compile and runtime. While 
> retrieving the 'batman' log messages you should see something like:
> Adding route to gateway ..
> Changing route to gateway ..
> Found new gateway ..
> etc
> 
> Maybe you can post the result here ?
> 

Ok, Let's give it a try:

=== Command Log 
a) Situation on node at beginng - just one gateway, the right one.
Freifunk-b0487acb2d58:~# batctl gwl
      Gateway      (#/255)           Nexthop [outgoingIF]: gw_class ... [B.A.T.M.A.N. adv 2012.4.0, MainIF/MAC: wlan0-1/b2:48:7a:cb:2d:59 (bat0)]
=> 72:8b:06:40:61:2e (248) 72:8b:06:40:61:2e [  mesh-vpn]: 215 - 96MBit/96MBit

b) Enable gateway mode on the backup gateway
root@fastd3:~# /usr/local/sbin/batctl gw server 1Mbit/1Mbit

Gateway-List is:
Freifunk-b0487acb2d58:~# batctl gwl
      Gateway      (#/255)           Nexthop [outgoingIF]: gw_class ... [B.A.T.M.A.N. adv 2012.4.0, MainIF/MAC: wlan0-1/b2:48:7a:cb:2d:59 (bat0)]
=> 72:8b:06:40:61:2e (255) 72:8b:06:40:61:2e [  mesh-vpn]: 215 - 96MBit/96MBit
   aa:31:0e:4a:0f:1d (255) aa:31:0e:4a:0f:1d [  mesh-vpn]:  39 - 1024KBit/1024KBit

c) Disable regular gateway, force node to switch to backup
kif:~# batctl gw_mode client

Gateway-List is:
reifunk-b0487acb2d58:~# batctl gwl
      Gateway      (#/255)           Nexthop [outgoingIF]: gw_class ... [B.A.T.M.A.N. adv 2012.4.0, MainIF/MAC: wlan0-1/b2:48:7a:cb:2d:59 (bat0)]
=> aa:31:0e:4a:0f:1d (255) aa:31:0e:4a:0f:1d [  mesh-vpn]:  39 - 1024KBit/1024KBit

d) Re-enable regular gateway
root@kif:~# /usr/local/sbin/batctl gw server 100Mbit/100Mbit

Gateway-List is 
Freifunk-b0487acb2d58:~# batctl gwl
      Gateway      (#/255)           Nexthop [outgoingIF]: gw_class ... [B.A.T.M.A.N. adv 2012.4.0, MainIF/MAC: wlan0-1/b2:48:7a:cb:2d:59 (bat0)]
   72:8b:06:40:61:2e (254) 72:8b:06:40:61:2e [  mesh-vpn]: 215 - 96MBit/96MBit
=> aa:31:0e:4a:0f:1d (255) aa:31:0e:4a:0f:1d [  mesh-vpn]:  39 - 1024KBit/1024KBit

e) Wait some time

f) Stop Logging

=== End of command Log

=== Node log of that hour
http://jluehr.de/batman-adv.log.gz

zgrep -i gateway batman-adv.log.gz
[   1022240] Gateway class of originator aa:31:0e:4a:0f:1d changed from 0 to 39
[   1035100] Gateway class of originator 72:8b:06:40:61:2e changed from 215 to 0
[   1035100] Gateway 72:8b:06:40:61:2e removed from gateway list
[   1035830] Changing route to gateway aa:31:0e:4a:0f:1d (gw_flags: 39, tq: 255)
[   1046020] Gateway class of originator 72:8b:06:40:61:2e changed from 0 to 215

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

[Marek Lindner]

On Thursday, January 03, 2013 19:03:11 Jan Lühr wrote:
> c) Disable regular gateway, force node to switch to backup
> kif:~# batctl gw_mode client
> 
> Gateway-List is:
> reifunk-b0487acb2d58:~# batctl gwl
>       Gateway      (#/255)           Nexthop [outgoingIF]: gw_class ...
> [B.A.T.M.A.N. adv 2012.4.0, MainIF/MAC: wlan0-1/b2:48:7a:cb:2d:59 (bat0)]
> => aa:31:0e:4a:0f:1d (255) aa:31:0e:4a:0f:1d [  mesh-vpn]:  39 -
> 1024KBit/1024KBit
> 
> d) Re-enable regular gateway
> root@kif:~# /usr/local/sbin/batctl gw server 100Mbit/100Mbit

Ah! You failed to mention this part in your initial email.

The behavior is easily explained: batman-adv does not switch gateway whenever 
a new gateway is found (even if it is a better gateway) unless the selection 
class is on fast or late switching.

Cheers,
Marek

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

[Jan Lühr]

Hello,

Am 03.01.2013 um 15:58 schrieb Marek Lindner:

> On Thursday, January 03, 2013 19:03:11 Jan Lühr wrote:
>> c) Disable regular gateway, force node to switch to backup
>> kif:~# batctl gw_mode client
>> 
>> Gateway-List is:
>> reifunk-b0487acb2d58:~# batctl gwl
>>      Gateway      (#/255)           Nexthop [outgoingIF]: gw_class ...
>> [B.A.T.M.A.N. adv 2012.4.0, MainIF/MAC: wlan0-1/b2:48:7a:cb:2d:59 (bat0)]
>> => aa:31:0e:4a:0f:1d (255) aa:31:0e:4a:0f:1d [  mesh-vpn]:  39 -
>> 1024KBit/1024KBit
>> 
>> d) Re-enable regular gateway
>> root@kif:~# /usr/local/sbin/batctl gw server 100Mbit/100Mbit
> 
> Ah! You failed to mention this part in your initial email.
> 
> The behavior is easily explained: batman-adv does not switch gateway whenever 
> a new gateway is found (even if it is a better gateway) unless the selection 
> class is on fast or late switching.
> 

It is. - Sorry, forgot to mention:
Freifunk-b0487acb2d58:~# batctl gw_mode
client (selection class: 1)

=> 1 -> fast connection consider the gateway's advertised  throughput as well as the link quality towards the gateway

Keep smiling
yanosz

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

[Marek Lindner]

On Thursday, January 03, 2013 23:01:07 Jan Lühr wrote:
> > Ah! You failed to mention this part in your initial email.
> > 
> > The behavior is easily explained: batman-adv does not switch gateway
> > whenever a new gateway is found (even if it is a better gateway) unless
> > the selection class is on fast or late switching.
> 
> It is. - Sorry, forgot to mention:
> Freifunk-b0487acb2d58:~# batctl gw_mode
> client (selection class: 1)
> 
> => 1 -> fast connection consider the gateway's advertised  throughput as
> well as the link quality towards the gateway

You did mention you were using selection class 1. I was referring to your test 
in which you turn on/off your best gateway. As I explained in my previous 
mail: batman-adv does not switch the gateway once it has chosen a gateway 
unless you select fast or late switching as selection class. Selection class 1 
does not fall into this category which means a gateway reselection only 
happens if the currently selected gateway disappears.

Run the foloowing test: enable both gateways before setting the gateway client 
to selection class 1. The gateway announcing the higher bandwidth should be 
selected.

Cheers,
Marek

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

[NicoEchániz]

On 01/03/2013 12:14 PM, Marek Lindner wrote:
> On Thursday, January 03, 2013 23:01:07 Jan Lühr wrote:
>>> Ah! You failed to mention this part in your initial email.
>>>
>>> The behavior is easily explained: batman-adv does not switch gateway
>>> whenever a new gateway is found (even if it is a better gateway) unless
>>> the selection class is on fast or late switching.
>>
>> It is. - Sorry, forgot to mention:
>> Freifunk-b0487acb2d58:~# batctl gw_mode
>> client (selection class: 1)
>>
>> => 1 -> fast connection consider the gateway's advertised  throughput as
>> well as the link quality towards the gateway
> 
> You did mention you were using selection class 1. I was referring to your test 
> in which you turn on/off your best gateway. As I explained in my previous 
> mail: batman-adv does not switch the gateway once it has chosen a gateway 
> unless you select fast or late switching as selection class. Selection class 1 
> does not fall into this category which means a gateway reselection only 
> happens if the currently selected gateway disappears.


Marek, could you please clarify this?

From the man page I don't see an option that would behave as Jan (and I) seem to be expecting it to work. That is: switch to a better gateway - with more bandwidth and comparable link quality - when it's available.


gw_mode|gw [off|client|server] [sel_class|bandwidth]
[...]
              If the node is a gateway client the parameter will decide which
              criterias to consider when the batman-adv module has to choose
              between different internet connections announced by the afore-
              mentioned servers.
                        default: 20 -> late switch (TQ 20)
                       examples:  1 -> fast connection
                                       consider the gateway's advertised
                                       throughput as well as the link quality
                                       towards the gateway
                                 2  -> stable connection
                                       chooses the gateway with the best link
                                       quality and stick with it (ignore the
                                       advertised throughput)
                                 3  -> fast switch connection
                                       chooses the gateway with the best link
                                       quality but switches to another gateway
                                       as soon as a better one is found
                                 XX -> late switch connection
                                       chooses the gateway with the best link
                                       quality but switches to another gateway
                                       as soon as a better one is found which
                                       is at least XX TQ better than the cur-
                                       rently selected gateway (XX has to be a
                                       number between 3 and 256).


Would mode 3 accomplish this fast switching? It doesn't mention if this mode will consider advertised throughput or not; only selection class 1 mentions throughput.


--
NicoEchániz

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

[Marek Lindner]

On Friday, January 04, 2013 08:06:17 NicoEchániz wrote:
> > You did mention you were using selection class 1. I was referring to your
> > test in which you turn on/off your best gateway. As I explained in my
> > previous mail: batman-adv does not switch the gateway once it has chosen
> > a gateway unless you select fast or late switching as selection class.
> > Selection class 1 does not fall into this category which means a gateway
> > reselection only happens if the currently selected gateway disappears.
> 
> Marek, could you please clarify this?
> 
> From the man page I don't see an option that would behave as Jan (and I)
> seem to be expecting it to work. That is: switch to a better gateway -
> with more bandwidth and comparable link quality - when it's available.
> 
> [..]
> 
> Would mode 3 accomplish this fast switching? It doesn't mention if this
> mode will consider advertised throughput or not; only selection class 1
> mentions throughput.

Selection class 3 and beyond do change the gateway when a better one becomes 
available. But as you correctly pointed out these selection classes don't 
consider the announced bandwidth for the simple reason that nobody cared. In 
most wireless scenarios (the main playground for batman-adv) the path towards 
the gateway turned out to be more critical than the gateway's pipe to the 
internet.

Feel free to propose something if you care about having this option. The 
necessary code shouldn't be too hard to add. Backward compatibility will be 
more difficult to achieve.

By the way, I posted a patch to improve the man page explanation a couple of 
hours ago.

Cheers,
Marek

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

[NicoEchániz]

On 01/03/2013 09:39 PM, Marek Lindner wrote:
> On Friday, January 04, 2013 08:06:17 NicoEchániz wrote:

>> Would mode 3 accomplish this fast switching? It doesn't mention if this
>> mode will consider advertised throughput or not; only selection class 1
>> mentions throughput.
> 
> Selection class 3 and beyond do change the gateway when a better one becomes 
> available. But as you correctly pointed out these selection classes don't 
> consider the announced bandwidth for the simple reason that nobody cared. In 
> most wireless scenarios (the main playground for batman-adv) the path towards 
> the gateway turned out to be more critical than the gateway's pipe to the 
> internet.
> 
> Feel free to propose something if you care about having this option. The 
> necessary code shouldn't be too hard to add. Backward compatibility will be 
> more difficult to achieve.

I believe that those of us who chose to use selection class 1 would
prefer if it were "dynamic". So if a new gateway appears, then the
client would evaluate with the same previous criteria if it is better or
not (considering "the gateway's advertised throughput as well as the
link quality") and switch accordingly. I see no reason why when someone
chooses selection class 1 she would be expecting to choose the best
available gw once and not ever check again.

If a network is stable, when a new better gw appears in some area it
won't be selected until nodes are restarted, and that might be a long time.

In my town, where partial energy outages are frequent, I've had to
manually switch off gw_mode and play around with this from time to time
because clients would be stuck with the wrong gw after an energy
shortage in the main gw.

One other change that might be interesting would be the addition of a
setting for how much the advertised throughput affects gw selection.
I've seen Jan uses 96/96Mbit as advertised throughput on one router; I
do the same on our "main gateway", but maybe it would be better if we
could actually advertise the real throughput and have a setting to
control how much the bandwidth difference affects the selection.


> By the way, I posted a patch to improve the man page explanation a couple of 
> hours ago.

good, it reads better now :)

Cheers,
NicoEchániz

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

[Marek Lindner]

On Friday, January 04, 2013 23:12:59 NicoEchániz wrote:
> > Selection class 3 and beyond do change the gateway when a better one
> > becomes available. But as you correctly pointed out these selection
> > classes don't consider the announced bandwidth for the simple reason
> > that nobody cared. In most wireless scenarios (the main playground for
> > batman-adv) the path towards the gateway turned out to be more critical
> > than the gateway's pipe to the internet.
> > 
> > Feel free to propose something if you care about having this option. The
> > necessary code shouldn't be too hard to add. Backward compatibility will
> > be more difficult to achieve.
> 
> I believe that those of us who chose to use selection class 1 would
> prefer if it were "dynamic". So if a new gateway appears, then the
> client would evaluate with the same previous criteria if it is better or
> not (considering "the gateway's advertised throughput as well as the
> link quality") and switch accordingly. I see no reason why when someone
> chooses selection class 1 she would be expecting to choose the best
> available gw once and not ever check again.
> 
> If a network is stable, when a new better gw appears in some area it
> won't be selected until nodes are restarted, and that might be a long time.

You misread my statement. Nobody needs to be convinced of the usefulness of 
such a feature (at least for what concerns myself). Somebody needs to come up 
with a solid proposal which then needs to be implemented. That is what I meant 
by saying "Feel free to propose something [..]".

Note that switching immediately as soon as a better gateway comes around isn't 
the best solution. Imagine a case in which a gateway announcing the highest 
bandwidth in your network barely is visible for your gateway client. It will 
keep switching between gateways, thereby breaking all your stateful 
connections such as: ssh, vpns, video & music streams, etc


> One other change that might be interesting would be the addition of a
> setting for how much the advertised throughput affects gw selection.
> I've seen Jan uses 96/96Mbit as advertised throughput on one router; I
> do the same on our "main gateway", but maybe it would be better if we
> could actually advertise the real throughput and have a setting to
> control how much the bandwidth difference affects the selection.

Again, feel free to propose something which can be discussed.

Cheers,
Marek

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

[Jan Lühr]

Hello,


Am 04.01.2013 um 18:41 schrieb Marek Lindner:

> On Friday, January 04, 2013 23:12:59 NicoEchániz wrote:
>>> Selection class 3 and beyond do change the gateway when a better one
>>> becomes available. But as you correctly pointed out these selection
>>> classes don't consider the announced bandwidth for the simple reason
>>> that nobody cared. In most wireless scenarios (the main playground for
>>> batman-adv) the path towards the gateway turned out to be more critical
>>> than the gateway's pipe to the internet.
>>> 
>>> Feel free to propose something if you care about having this option. The
>>> necessary code shouldn't be too hard to add. Backward compatibility will
>>> be more difficult to achieve.
>> 
>> I believe that those of us who chose to use selection class 1 would
>> prefer if it were "dynamic". So if a new gateway appears, then the
>> client would evaluate with the same previous criteria if it is better or
>> not (considering "the gateway's advertised throughput as well as the
>> link quality") and switch accordingly. I see no reason why when someone
>> chooses selection class 1 she would be expecting to choose the best
>> available gw once and not ever check again.
>> 
>> If a network is stable, when a new better gw appears in some area it
>> won't be selected until nodes are restarted, and that might be a long time.
> 
> You misread my statement. Nobody needs to be convinced of the usefulness of 
> such a feature (at least for what concerns myself). Somebody needs to come up 
> with a solid proposal which then needs to be implemented. That is what I meant 
> by saying "Feel free to propose something [..]".
> 
> Note that switching immediately as soon as a better gateway comes around isn't 
> the best solution. Imagine a case in which a gateway announcing the highest 
> bandwidth in your network barely is visible for your gateway client. It will 
> keep switching between gateways, thereby breaking all your stateful 
> connections such as: ssh, vpns, video & music streams, etc


Thanks for being open minded. Imho there are a few "tweaks" for doing so.

For our networks, it's not important, that all clients choose the gateway with the highest data rate. Basically, we have 3 gateway-types
-> Regular Gateways, that should be used if they are reachable (above a certain TQ threshold)
-> Backup Gateways - Gateways, that should be used if no regular Gateway is available.
-> Test Gateways - Just for testing purpose - should be used if no Backup-Gateway is available.

Imho others may have more / or less classes. basically what is needed here is a positive gateway ("route priority") - imho the already existing gateway-class may be used for doing so.

In order to prevent "switching immediately as soon as a better gateway comes around", we may can go this way:
gw_mode client may have three parameters:
1st: Switching threshold based on TQ (Like today, eg 20: late switching)
2nd: Switching threshold based on Gateway Class). GC-Thresh
3rd: LQ-Threshold for GW-class-switch GC-TQ-Thresh

Meaning:
Switch gateway to same / better class, if  there is a Gateway having TQ xx-Times bigger (traditional late switching with xx)
Switch gateway to a better class, if a Class is GC-Thresh times better, and LQ is above TQ-GC-Thresh
Switch gateway to a worse class, if all existing gateway of same or better class have LQ < GC-TQ-Thresh

However, this is quite complex and I don't know if everybody will be happy with this - However, I'll be so.

For backwards compatibility, old configurations can be detected by counting the number of parameters and react according old defaults.

If you like thinks to be more complex - Different thresholds for blocking DHCPDISCOVER / DHCPREQUEST ;-)

Thanks,
Keep smiling
yanosz

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

[Jan Lühr]

Hello,

Am 04.01.2013 um 19:25 schrieb Jan Lühr:
> Am 04.01.2013 um 18:41 schrieb Marek Lindner:
> 
>> On Friday, January 04, 2013 23:12:59 NicoEchániz wrote:
>>>> Selection class 3 and beyond do change the gateway when a better one
>>>> becomes available. But as you correctly pointed out these selection
>>>> classes don't consider the announced bandwidth for the simple reason
>>>> that nobody cared. In most wireless scenarios (the main playground for
>>>> batman-adv) the path towards the gateway turned out to be more critical
>>>> than the gateway's pipe to the internet.
>>>> 
>>>> Feel free to propose something if you care about having this option. The
>>>> necessary code shouldn't be too hard to add. Backward compatibility will
>>>> be more difficult to achieve.
>>> 
>>> I believe that those of us who chose to use selection class 1 would
>>> prefer if it were "dynamic". So if a new gateway appears, then the
>>> client would evaluate with the same previous criteria if it is better or
>>> not (considering "the gateway's advertised throughput as well as the
>>> link quality") and switch accordingly. I see no reason why when someone
>>> chooses selection class 1 she would be expecting to choose the best
>>> available gw once and not ever check again.
>>> 
>>> If a network is stable, when a new better gw appears in some area it
>>> won't be selected until nodes are restarted, and that might be a long time.
>> 
>> You misread my statement. Nobody needs to be convinced of the usefulness of 
>> such a feature (at least for what concerns myself). Somebody needs to come up 
>> with a solid proposal which then needs to be implemented. That is what I meant 
>> by saying "Feel free to propose something [..]".
>> 
>> Note that switching immediately as soon as a better gateway comes around isn't 
>> the best solution. Imagine a case in which a gateway announcing the highest 
>> bandwidth in your network barely is visible for your gateway client. It will 
>> keep switching between gateways, thereby breaking all your stateful 
>> connections such as: ssh, vpns, video & music streams, etc
> 
> 
> Thanks for being open minded. Imho there are a few "tweaks" for doing so.
> 
> For our networks, it's not important, that all clients choose the gateway with the highest data rate. Basically, we have 3 gateway-types
> -> Regular Gateways, that should be used if they are reachable (above a certain TQ threshold)
> -> Backup Gateways - Gateways, that should be used if no regular Gateway is available.
> -> Test Gateways - Just for testing purpose - should be used if no Backup-Gateway is available.
> 
> Imho others may have more / or less classes. basically what is needed here is a positive gateway ("route priority") - imho the already existing gateway-class may be used for doing so.
> 
> In order to prevent "switching immediately as soon as a better gateway comes around", we may can go this way:
> gw_mode client may have three parameters:
> 1st: Switching threshold based on TQ (Like today, eg 20: late switching)
> 2nd: Switching threshold based on Gateway Class). GC-Thresh
> 3rd: LQ-Threshold for GW-class-switch GC-TQ-Thresh
> 
> Meaning:
> Switch gateway to same / better class, if  there is a Gateway having TQ xx-Times bigger (traditional late switching with xx)
> Switch gateway to a better class, if a Class is GC-Thresh times better, and TQ is above TQ-GC-Thresh
> Switch gateway to a worse class, if all existing gateway of same or better class have TQ < GC-TQ-Thresh

Switch gateway to a worse class, if TQ is xx times better - imho there is no reason to stick at a unreachable but fast gateway. TC-GC-Thresh just prevents using big gateway with worse TQ.
But we can argue about that.

Keep smiling
yanosz

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

[NicoEchániz]

On 01/04/2013 02:41 PM, Marek Lindner wrote:
> On Friday, January 04, 2013 23:12:59 NicoEchániz wrote:
>>> Selection class 3 and beyond do change the gateway when a better one
>>> becomes available. But as you correctly pointed out these selection
>>> classes don't consider the announced bandwidth for the simple reason
>>> that nobody cared. In most wireless scenarios (the main playground for
>>> batman-adv) the path towards the gateway turned out to be more critical
>>> than the gateway's pipe to the internet.
>>>
>>> Feel free to propose something if you care about having this option. The
>>> necessary code shouldn't be too hard to add. Backward compatibility will
>>> be more difficult to achieve.
>>
>> I believe that those of us who chose to use selection class 1 would
>> prefer if it were "dynamic". So if a new gateway appears, then the
>> client would evaluate with the same previous criteria if it is better or
>> not (considering "the gateway's advertised throughput as well as the
>> link quality") and switch accordingly. I see no reason why when someone
>> chooses selection class 1 she would be expecting to choose the best
>> available gw once and not ever check again.
>>
>> If a network is stable, when a new better gw appears in some area it
>> won't be selected until nodes are restarted, and that might be a long time.
> 
> You misread my statement. Nobody needs to be convinced of the usefulness of 
> such a feature (at least for what concerns myself). Somebody needs to come up 
> with a solid proposal which then needs to be implemented. That is what I meant 
> by saying "Feel free to propose something [..]".
> 
> Note that switching immediately as soon as a better gateway comes around isn't 
> the best solution. Imagine a case in which a gateway announcing the highest 
> bandwidth in your network barely is visible for your gateway client. It will 
> keep switching between gateways, thereby breaking all your stateful 
> connections such as: ssh, vpns, video & music streams, etc

Yeah, I agree. The gateway switching should be regulated by a threshold,
so that it won't be switching like crazy when a client has similar
ranking values from more than one gw. See the proposal below...


>> One other change that might be interesting would be the addition of a
>> setting for how much the advertised throughput affects gw selection.
>> I've seen Jan uses 96/96Mbit as advertised throughput on one router; I
>> do the same on our "main gateway", but maybe it would be better if we
>> could actually advertise the real throughput and have a setting to
>> control how much the bandwidth difference affects the selection.
> 
> Again, feel free to propose something which can be discussed.

It could just be implemented as a new setting like: gw_bw_weight

which would regulate how much gw bandwidth/throughput affects best gw
calculation.

I don't know what's the current algorithm but I guess there would be no
problem with backwards compatibility here; if the value is not set, the
default should produce the same result we get now.


So to make the proposal clear:

I'd change options for gw_mode client to something like this:

gw_sel_class [1|2] (1 considers TQ and bw, 2 only considers TQ)

gw_tq_threshold [3...256]
the minimum TQ delta to switch to a better gw, defaults to 20.

gw_bw_weight [value from 0 to 1]
how much does advertised gw bandwidth affect the selection. 0 does not
affect selection, 1 has most effect. Defaults to 1 but has no effect if
gw_sel_class is 2.

For backwards compatibility, if gw_sel_class > 2, it should behave as
the proposed option 2 with gw_tq_threshold set to the actual value. So,
for example gw_sel_class 20 would be "translated" to: gw_sel_class 2,
gw_tq_threshold 20, al least until it's deprecated.


The advantage of this proposal is that we can have a tq_threshold that
can still be used in the mode that considers gw throughput.


I like this better than gateway classes that Jan proposed, as it is less
implementation specific.


Please let me know if anything in this proposal is not sufficiently clear.



cheers,
NicoEchániz


PS: Marek, there are mismatched parenthesis in the new man page text in
this paragraph:

The second (optional) argument specifies the selection class (if
'client' was the first argument) or the gateway bandwidth (if this
node's internet connection bandwidth. Just enter any number (optionally
followed by "kbit" or "mbit") and the batman-adv module will guess your
appropriate gateway class.

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

[Marek Lindner]

On Saturday, January 05, 2013 07:28:20 NicoEchániz wrote:
> >> One other change that might be interesting would be the addition of a
> >> setting for how much the advertised throughput affects gw selection.
> >> I've seen Jan uses 96/96Mbit as advertised throughput on one router; I
> >> do the same on our "main gateway", but maybe it would be better if we
> >> could actually advertise the real throughput and have a setting to
> >> control how much the bandwidth difference affects the selection.
> > 
> > Again, feel free to propose something which can be discussed.
> 
> It could just be implemented as a new setting like: gw_bw_weight
> 
> which would regulate how much gw bandwidth/throughput affects best gw
> calculation.
> 
> I don't know what's the current algorithm but I guess there would be no
> problem with backwards compatibility here; if the value is not set, the
> default should produce the same result we get now.
>
> [..]
> 
> I like this better than gateway classes that Jan proposed, as it is less
> implementation specific.

How about you and Jan discuss the matter to come up with a combined proposal 
which solves both your problems ?


> PS: Marek, there are mismatched parenthesis in the new man page text in
> this paragraph:

The parenthesis is ok but groff has problems compiling that section. I re-
posted a cleaned up version of Pau's proposed fix. In the future don't 
hesitate to post a patch for such trivial things otherwise you will have to 
wait until somebody comes around and does the work for you.

Cheers,
Marek

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

[Jan Lühr]

Hello,

Am 05.01.2013 um 00:28 schrieb NicoEchániz:

> On 01/04/2013 02:41 PM, Marek Lindner wrote:
>> On Friday, January 04, 2013 23:12:59 NicoEchániz wrote:
>>>> Selection class 3 and beyond do change the gateway when a better one
>>>> becomes available. But as you correctly pointed out these selection
>>>> classes don't consider the announced bandwidth for the simple reason
>>>> that nobody cared. In most wireless scenarios (the main playground for
>>>> batman-adv) the path towards the gateway turned out to be more critical
>>>> than the gateway's pipe to the internet.
>>>> 
>>>> Feel free to propose something if you care about having this option. The
>>>> necessary code shouldn't be too hard to add. Backward compatibility will
>>>> be more difficult to achieve.
>>> 
>>> I believe that those of us who chose to use selection class 1 would
>>> prefer if it were "dynamic". So if a new gateway appears, then the
>>> client would evaluate with the same previous criteria if it is better or
>>> not (considering "the gateway's advertised throughput as well as the
>>> link quality") and switch accordingly. I see no reason why when someone
>>> chooses selection class 1 she would be expecting to choose the best
>>> available gw once and not ever check again.
>>> 
>>> If a network is stable, when a new better gw appears in some area it
>>> won't be selected until nodes are restarted, and that might be a long time.
>> 
>> You misread my statement. Nobody needs to be convinced of the usefulness of 
>> such a feature (at least for what concerns myself). Somebody needs to come up 
>> with a solid proposal which then needs to be implemented. That is what I meant 
>> by saying "Feel free to propose something [..]".
> 
>>> One other change that might be interesting would be the addition of a
>>> setting for how much the advertised throughput affects gw selection.
>>> I've seen Jan uses 96/96Mbit as advertised throughput on one router; I
>>> do the same on our "main gateway", but maybe it would be better if we
>>> could actually advertise the real throughput and have a setting to
>>> control how much the bandwidth difference affects the selection.
>> 
>> Again, feel free to propose something which can be discussed.
> 
> It could just be implemented as a new setting like: gw_bw_weight
> 
> which would regulate how much gw bandwidth/throughput affects best gw
> calculation.
> 
> I don't know what's the current algorithm but I guess there would be no
> problem with backwards compatibility here; if the value is not set, the
> default should produce the same result we get now.
> 
> 
> So to make the proposal clear:
> 
> I'd change options for gw_mode client to something like this:
> 
> gw_sel_class [1|2] (1 considers TQ and bw, 2 only considers TQ)
> 
> gw_tq_threshold [3...256]
> the minimum TQ delta to switch to a better gw, defaults to 20.
> 
> gw_bw_weight [value from 0 to 1]
> how much does advertised gw bandwidth affect the selection. 0 does not
> affect selection, 1 has most effect. Defaults to 1 but has no effect if
> gw_sel_class is 2.
> 
> For backwards compatibility, if gw_sel_class > 2, it should behave as
> the proposed option 2 with gw_tq_threshold set to the actual value. So,
> for example gw_sel_class 20 would be "translated" to: gw_sel_class 2,
> gw_tq_threshold 20, al least until it's deprecated.


I guess, we'll be fine with this. However, it's not clear to me, in what way (formula) gw_bw_weight will actually influence the selection process.
Do you have any proposals?

Thanks
Keep smiling
yanosz

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

[Jan Lühr]

Hello,

Am 05.01.2013 um 10:47 schrieb Jan Lühr:

> Am 05.01.2013 um 00:28 schrieb NicoEchániz:
>> On 01/04/2013 02:41 PM, Marek Lindner wrote:
>>> On Friday, January 04, 2013 23:12:59 NicoEchániz wrote:
>>>>> Selection class 3 and beyond do change the gateway when a better one
>>>>> becomes available. But as you correctly pointed out these selection
>>>>> classes don't consider the announced bandwidth for the simple reason
>>>>> that nobody cared. In most wireless scenarios (the main playground for
>>>>> batman-adv) the path towards the gateway turned out to be more critical
>>>>> than the gateway's pipe to the internet.
>>>>> 
>>>>> Feel free to propose something if you care about having this option. The
>>>>> necessary code shouldn't be too hard to add. Backward compatibility will
>>>>> be more difficult to achieve.
>>>> 
>>>> I believe that those of us who chose to use selection class 1 would
>>>> prefer if it were "dynamic". So if a new gateway appears, then the
>>>> client would evaluate with the same previous criteria if it is better or
>>>> not (considering "the gateway's advertised throughput as well as the
>>>> link quality") and switch accordingly. I see no reason why when someone
>>>> chooses selection class 1 she would be expecting to choose the best
>>>> available gw once and not ever check again.
>>>> 
>>>> If a network is stable, when a new better gw appears in some area it
>>>> won't be selected until nodes are restarted, and that might be a long time.
>>> 
>>> You misread my statement. Nobody needs to be convinced of the usefulness of 
>>> such a feature (at least for what concerns myself). Somebody needs to come up 
>>> with a solid proposal which then needs to be implemented. That is what I meant 
>>> by saying "Feel free to propose something [..]".
>> 
>>>> One other change that might be interesting would be the addition of a
>>>> setting for how much the advertised throughput affects gw selection.
>>>> I've seen Jan uses 96/96Mbit as advertised throughput on one router; I
>>>> do the same on our "main gateway", but maybe it would be better if we
>>>> could actually advertise the real throughput and have a setting to
>>>> control how much the bandwidth difference affects the selection.
>>> 
>>> Again, feel free to propose something which can be discussed.
>> 
>> It could just be implemented as a new setting like: gw_bw_weight
>> 
>> which would regulate how much gw bandwidth/throughput affects best gw
>> calculation.
>> 
>> I don't know what's the current algorithm but I guess there would be no
>> problem with backwards compatibility here; if the value is not set, the
>> default should produce the same result we get now.
>> 
>> 
>> So to make the proposal clear:
>> 
>> I'd change options for gw_mode client to something like this:
>> 
>> gw_sel_class [1|2] (1 considers TQ and bw, 2 only considers TQ)
>> 
>> gw_tq_threshold [3...256]
>> the minimum TQ delta to switch to a better gw, defaults to 20.
>> 
>> gw_bw_weight [value from 0 to 1]
>> how much does advertised gw bandwidth affect the selection. 0 does not
>> affect selection, 1 has most effect. Defaults to 1 but has no effect if
>> gw_sel_class is 2.
>> 
>> For backwards compatibility, if gw_sel_class > 2, it should behave as
>> the proposed option 2 with gw_tq_threshold set to the actual value. So,
>> for example gw_sel_class 20 would be "translated" to: gw_sel_class 2,
>> gw_tq_threshold 20, al least until it's deprecated.
> 
> 
> I guess, we'll be fine with this. However, it's not clear to me, in what way (formula) gw_bw_weight will actually influence the selection process.
> Do you have any proposals?

Ok, I make one - for Link-Usability (or attractiveness, or whatever you like)  LU, Gateway-Class GC and TQ:
LU = (1 - gw_bw_weight) * TQ  +  gw_bw_weight * GC

gw_tq_threshold should then be renamed to gw_lu_threshold.

However, that implies, that TQ and GC should are linear in LU and that min( TQ ) = min ( GC ) as well as max ( TQ ) = max( GC ).
I'll be fine with the assuming that TQ and GC should be linear in LU - GC can be scaled such that the min / max condition holds
LU = (1 - gw_bw_weight) * TQ  +  gw_bw_weight * ( c1 * GC + c2)
(for contants c1, c2) 

@Marek, Nico : What Do you think?

Keep smiling
yanosz

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

[Marek Lindner]

On Monday, January 07, 2013 23:26:10 Jan Lühr wrote:
> Ok, I make one - for Link-Usability (or attractiveness, or whatever you
> like)  LU, Gateway-Class GC and TQ: LU = (1 - gw_bw_weight) *
> TQ  +  gw_bw_weight * GC
> 
> gw_tq_threshold should then be renamed to gw_lu_threshold.
> 
> However, that implies, that TQ and GC should are linear in LU and that min(
> TQ ) = min ( GC ) as well as max ( TQ ) = max( GC ). I'll be fine with the
> assuming that TQ and GC should be linear in LU - GC can be scaled such
> that the min / max condition holds LU = (1 - gw_bw_weight) *
> TQ  +  gw_bw_weight * ( c1 * GC + c2)
> (for contants c1, c2) 
> 
> @Marek, Nico : What Do you think?

May I propose that we schedule an IRC discussion for this topic ? I lost track 
of what you are actually trying to achieve and I see things getting more and 
more complicated. 
Whatever idea you come up with keep in mind that somebody has to do the 
following before this solution can be merged:

 * batman-adv code has to be written, tested & debugged
 * batman-adv kernel doc has to be written
 * batctl code has to be written, tested & debugged
 * man page has to be updated
 * user documentation for $your_new_mechanism has to be written

Unless you manage to convince somebody else to do the work for you that 
somebody who has to do all work will be you. In other words: It is in your 
best interest to keep things as simple as possible.  :-)

Cheers,
Marek

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

[NicoEchániz]

On 01/08/2013 03:15 AM, Marek Lindner wrote:

> May I propose that we schedule an IRC discussion for this topic ? I lost track 
> of what you are actually trying to achieve and I see things getting more and 
> more complicated. 
> Whatever idea you come up with keep in mind that somebody has to do the 
> following before this solution can be merged:
> 
>  * batman-adv code has to be written, tested & debugged
>  * batman-adv kernel doc has to be written
>  * batctl code has to be written, tested & debugged
>  * man page has to be updated
>  * user documentation for $your_new_mechanism has to be written
> 
> Unless you manage to convince somebody else to do the work for you that 
> somebody who has to do all work will be you. In other words: It is in your 
> best interest to keep things as simple as possible.  :-)

agreed. When would it be a good time for an IRC discussion on this matter?

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

[Marek Lindner]

On Wednesday, January 09, 2013 00:35:17 NicoEchániz wrote:
> On 01/08/2013 03:15 AM, Marek Lindner wrote:
> > May I propose that we schedule an IRC discussion for this topic ? I lost
> > track of what you are actually trying to achieve and I see things
> > getting more and more complicated.
> > Whatever idea you come up with keep in mind that somebody has to do the
> > 
> > following before this solution can be merged:
> >  * batman-adv code has to be written, tested & debugged
> >  * batman-adv kernel doc has to be written
> >  * batctl code has to be written, tested & debugged
> >  * man page has to be updated
> >  * user documentation for $your_new_mechanism has to be written
> > 
> > Unless you manage to convince somebody else to do the work for you that
> > somebody who has to do all work will be you. In other words: It is in
> > your best interest to keep things as simple as possible.  :-)
> 
> agreed. When would it be a good time for an IRC discussion on this matter?

I am idling on IRC most of the time. Depends on you guys.

Cheers,
Marek

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

[Jan Lühr]

Hello,

Am 09.01.2013 um 07:30 schrieb Marek Lindner:

> On Wednesday, January 09, 2013 00:35:17 NicoEchániz wrote:
>> On 01/08/2013 03:15 AM, Marek Lindner wrote:
>>> May I propose that we schedule an IRC discussion for this topic ? I lost
>>> track of what you are actually trying to achieve and I see things
>>> getting more and more complicated.
>>> Whatever idea you come up with keep in mind that somebody has to do the
>>> 
>>> following before this solution can be merged:
>>> * batman-adv code has to be written, tested & debugged
>>> * batman-adv kernel doc has to be written
>>> * batctl code has to be written, tested & debugged
>>> * man page has to be updated
>>> * user documentation for $your_new_mechanism has to be written
>>> 
>>> Unless you manage to convince somebody else to do the work for you that
>>> somebody who has to do all work will be you. In other words: It is in
>>> your best interest to keep things as simple as possible.  :-)
>> 
>> agreed. When would it be a good time for an IRC discussion on this matter?
> 
> I am idling on IRC most of the time. Depends on you guys.

Sorry for answering late. We'll have our freifunk community-meeting tomorrow evening and we're going to talk about that.
For our IRC-meeting, I'd prefer some day next week - If it's ok for you.

Thanks,
Keep smiling
yanosz

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

[NicoEchániz]

On 01/09/2013 08:49 AM, Jan Lühr wrote:
> Hello,
> 
> Am 09.01.2013 um 07:30 schrieb Marek Lindner:
> 
>> On Wednesday, January 09, 2013 00:35:17 NicoEchániz wrote:
>>> On 01/08/2013 03:15 AM, Marek Lindner wrote:
>>>> May I propose that we schedule an IRC discussion for this topic ? I lost
>>>> track of what you are actually trying to achieve and I see things
>>>> getting more and more complicated.
>>>> Whatever idea you come up with keep in mind that somebody has to do the
>>>>
>>>> following before this solution can be merged:
>>>> * batman-adv code has to be written, tested & debugged
>>>> * batman-adv kernel doc has to be written
>>>> * batctl code has to be written, tested & debugged
>>>> * man page has to be updated
>>>> * user documentation for $your_new_mechanism has to be written
>>>>
>>>> Unless you manage to convince somebody else to do the work for you that
>>>> somebody who has to do all work will be you. In other words: It is in
>>>> your best interest to keep things as simple as possible.  :-)
>>>
>>> agreed. When would it be a good time for an IRC discussion on this matter?
>>
>> I am idling on IRC most of the time. Depends on you guys.
> 
> Sorry for answering late. We'll have our freifunk community-meeting tomorrow evening and we're going to talk about that.
> For our IRC-meeting, I'd prefer some day next week - If it's ok for you.


I'm also idling on IRC usually; next week is ok; Jan what about monday
or twesday?.

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

[Jan Lühr]

Hello,

Am 09.01.2013 um 18:39 schrieb NicoEchániz:

> On 01/09/2013 08:49 AM, Jan Lühr wrote:
>> Hello,
>> 
>> Am 09.01.2013 um 07:30 schrieb Marek Lindner:
>> 
>>> On Wednesday, January 09, 2013 00:35:17 NicoEchániz wrote:
>>>> On 01/08/2013 03:15 AM, Marek Lindner wrote:
>>>>> May I propose that we schedule an IRC discussion for this topic ? I lost
>>>>> track of what you are actually trying to achieve and I see things
>>>>> getting more and more complicated.
>>>>> Whatever idea you come up with keep in mind that somebody has to do the
>>>>> 
>>>>> following before this solution can be merged:
>>>>> * batman-adv code has to be written, tested & debugged
>>>>> * batman-adv kernel doc has to be written
>>>>> * batctl code has to be written, tested & debugged
>>>>> * man page has to be updated
>>>>> * user documentation for $your_new_mechanism has to be written
>>>>> 
>>>>> Unless you manage to convince somebody else to do the work for you that
>>>>> somebody who has to do all work will be you. In other words: It is in
>>>>> your best interest to keep things as simple as possible.  :-)
>>>> 
>>>> agreed. When would it be a good time for an IRC discussion on this matter?
>>> 
>>> I am idling on IRC most of the time. Depends on you guys.
>> 
>> Sorry for answering late. We'll have our freifunk community-meeting tomorrow evening and we're going to talk about that.
>> For our IRC-meeting, I'd prefer some day next week - If it's ok for you.
> 
> 
> I'm also idling on IRC usually; next week is ok; Jan what about monday
> or twesday?.

thanks for your reply - I'll propose a day as soon as I know might be joining us.

Keep smiling
yanosz

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

[NicoEchániz]

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.

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

[Jan Lühr]

Hello world!

I'm back:

Am 16.01.2013 um 02:42 schrieb NicoEchániz:

> 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:

I'll be available on IRC this evening (20:00 CET) - sadly, I'ven't found any other contributers in our freifunk-community?

> 
> 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.

Well - I still think, that having a fixed gw_tq_floor may cause unstable gateway-selections if tq oscillates around gw_tq_floor.
Perhaps we can discuss this in detail.

Thanks,
Keep smiling
yanosz