Re: [B.A.T.M.A.N.] Multiple connections / prioritiy

[Axel Neumann <axel@open-mesh.net>]

Hello,

On Dienstag 24 Juli 2007, Daniel Poelzleithner wrote:
> Freifunk Dresden wrote:
> > If I have multiple connections between two nodes, is there a way to
> > setup the quality or
> > priority of those connection?

you can experiment with that using batman-experimental  rv555. Try

--send-clones ( /c <value> ) which can be used to increase or decrease the 
quality of a link by specifying a probability how often a received OGM should 
be rebroadcasted. The default value for this parameter is 100, saying each 
OGM will be (re-)broadcasted with a probability of 100%. Applying a value 
less than 100 will let the links to a node appear worse than they actually 
are. A value larger than 100 will clone packets and send them multiple times 
(retending better connectivity to the node than there actually is).
For example:
180 results in 80 % of the OGM to be (re-)broadcasted twice.
30 results in 70% of the OGMs not being (re-)broadcasted at all.
Since --send-clones will change the default value (affecting all interfaces of 
a node) there is also an interface-specific variant of this feature: "/c 
<value>", which must be applied after the interface name and will only affect 
the broadcast-probability  for a specific interface.

Another thing is the problem with the bidirectional link check. This check by 
default allows a maximum of one OGM from my neighboring link peer to be lost 
before the link is temporary considered non-bidirectional or invalid. So, if 
70% of the to-be-broadcasted OGMs are intentional not send at all (because 
of /c 30) the bidirectinal link check will fail very often. This has the 
side-effect that many OGMs from distant nodes will be ignored even more.  
This problem can be resolved by also applying the /b <value> (the 
interface-specific variant of the --bi-link-timeout) switch to the dropping 
interface and giving it a higher value that the default value of two.

So if you have a dsl-vpn-fallback-link (which you only want to use in case of 
terrible wireless connectivity) called dsl0. And you have the wireless 
interface wlan0, then try: $batmand wlan0 dsl0 /c 40 /b 6
This will suspend 60% of the OGMs from being broadcasted via interface dsl0 
and relieves the bidirectional link check at this interface from two to five.

greetings,
axel









and
--bi-link-timeout <value> ( /b <value> )

There are interface-specific switches called /c and /b which must be applied 
behind an interface name

>
> Same goes for Leipzig, we have our vpn[1,2].leipzig.freifunk.net nodes.
> I thought about this problem a lot and the simplest solution would be to
> simply drop like 9 of 10 batman packets on the outgoing vpn interface.
> this is like a olsr multiplicator of 10 with the advantage that it saves
> bandwith.
>
> short anecdote about dropping olsr packets:
> so, we now have this huge vpn that connects most edges of the mesh to
> central olsr nodes. because this are just backup routes, we have to
> increase the etx value, no problem with the olsr multiplier option. on
> the vpn a packetloss of 0% ist relative normal, so you pump out 5kb/s of
> olsr traffic just to say: mmhh, ok, very good connection but i think its
> bad anyway. so, if olsr messures the packet loss rate, i could simply
> drop 9 of 10 packets and with 0.5kb/s i would have the same effect. if
> that is what olsr is supposed to do.
>
> by the way, we have arround 400 GB per month olsr overhead alone, which
> is just creazy for a routing protocol overhead.
>
> i ran a couple of tests.
> there is a iptables match called nth, so i tested to allow only every
> tenth packet. i got a etx of 0.0
> strange: i allowed 50% -> etx 0.0
> stranger: i allowed 90% -> etx 0.0
> there is a percent match. i combined them, i tried percent alone, etc.
> olsr depends a lot about which packets get dropped.
> you simply can't just drop packets without getting etx 0.0 for at least
> periods of 20-30 seconds, which drives you nuts.
>
> batman should work very well with that approach.
>
> kindly regards
>  Daniel
> _______________________________________________
> B.A.T.M.A.N mailing list
> B.A.T.M.A.N@open-mesh.net
> https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n