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

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

[Freifunk Dresden]

Hi Axel,

this is great and I will try it, but I can not promise to give you  
results soon because
the lack of time.
If I have multiple connections between two nodes, is there a way to  
setup the quality or
priority of those connection?
Assume I have tree or more nodes connected in a line (A,B,C,D) and  
node A and Node D are
connected via backbone tunnel over Internet, the wireless connection  
should be used until
the quality falls below a certain level or the number of nodes
exceeded a maximum value. setting up a hysteresis should be possible  
to avoid to much
switching of the route.


eth1:   A ------- B ------- C ------- D
bbs:    A ============================D

Regards
  Stephan

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

[Daniel Poelzleithner]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Freifunk Dresden wrote:

> If I have multiple connections between two nodes, is there a way to
> setup the quality or
> priority of those connection?

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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: GnuPT 2.7.2
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGpZG/y/mkIQp7AD0RAtcUAKDPP/rKGgMt5doPyLdgxcDPm1cO/QCgsQ09
kXCustGVyorDABZKxXlutWk=
=BXOc
-----END PGP SIGNATURE-----

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

[Axel Neumann]

Hi

On Tuesday 24 July 2007 07:44, 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?
>
> 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.
on a specific interface
a) you man drop received originator messages (OGMs) which does not really 
reducing the traffic or
b) suspend the sending of OGMs 

However, dropping or suspending should only be applied to OGMs from 
non-neighboring nodes, otherwise it also affects the bidirectional link check 
which would result in a confusing side-effect, marking even more packets as 
invalid.

In parallel it might be beneficial to configure different originator intervals 
for particular interfaces. For example for a vpn connection a very large 
originator interval (with a small TTL would be sufficient) since its 
link-quality is not supposed to change anyway (and causing less traffic to 
the vpn).

/axel

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

[Axel Neumann]

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