Re: [B.A.T.M.A.N.] No rebroadcast on mesh links

[Simon Wunderlich <sw@simonwunderlich.de>]

[-- Attachment #1: Type: text/plain, Size: 4000 bytes --]

Hi Adrian,

On Tuesday 29 March 2016 10:37:17 Adrian Reyer wrote:
> Hi,
> 
> On Tue, Mar 29, 2016 at 01:52:47AM +0200, Linus Lüssing wrote:
> > At least this approach would cover everything we care about for
> > current Freifunk setups for now and many more. Without the user
> > being able to misconfigure something that easily. (usually a user
> > would not set a TRANSITIVE flag on the interface, but e.g. drivers
> > and applications creating the interface would)
> 
> The interface doesn't have the information needed, so the (assumed) huge
> effort of bringing in a new flag for all types of network interfaces is
> somewhat useless.
> In my eyes we have two types to consider here:
> 1. lossy links, this is what can be 'fixed' be repeatedly sending a
> broadcast out
> 2. different listeners, e.g. due to wifi range. If we have the same
> listeners for everyone on an interface we don't need a re-broadcast at
> all.
> There are many different possibilities to generate the different
> combinations of 1 and 2 with common hardware.
> - wifi AP-mode: lossy, same listener
> - wifi adhoc mode: lossy, different listeners
> - ethernet cable on a switch with the listeners on: non-lossy, same
>   listeners
> - ethernet cable towards a wifi-bridge in adhoc mode
> - ethernet cable towards a wifi-bridge in ap mode
> - various types of vpn with and without meshing
> - SoC with wifi attached via vlan in adhoc, station or ap mode
> - network technologies stacked on others, e.g. tagged vlan a into
>   openvSwitch and the lossy wifi link is the untagged vlan a, while
>   tagged vlan b is plugged into a solid vpn.
> - add bridges to the game, old style or ovs
> - add other stuff like ppp, slip, atm, ...

I don't think we have to pull out every possible case here. People will always 
be creative in designing their networks, even if their would be some easier or 
better approaches[tm]. Not supporting everything is not a flaw in my opinion, 
at least as long as we support sound alternatives.

For example, I don't see why we would need to support not-forwarding/not-full 
mesh VPNs. We could just require every mesh participant to run batman-adv, and 
not supporting setups where, for example, the "master" node doesn't speak 
batman-adv, since that could be easily enabled. If there are multiple 
independent VPN links, those could be done in seperate interfaces. Is that 
assumption correct? (Maybe Freifunk people could tell a little bit more).

So far, I see the following scenarios:

Broadcast needed:
 * WiFi Ad-Hoc
 * WiFi AP
 * Ethernet to WiFi Ad-Hoc bridges (is that even used?)

Broadcast not needed
 * WiFi Point to Point links
 * Ethernet
 * VPNs (at least common setups)

As a very easy rule of thumb, we could say that rebroadcasts on the same 
interface should always be enabled on WiFi and disabled on everything else. 
Even if we still agree to introduce a flag to change that, that could still be 
a sound default. Would you agree?

> I advocate an admin-settable flag for batman, defaulting to the current
> behaviour. Nothing breaks that way, only batman needs to be adjusted and
> the patch already exists and is tested. Admins can set the flag if they
> think they have use for it and they do it knowingly. If they do it 'by
> accident' it is as little batmans fault as if they earased their disk
> with some dd-command. Default is sane, just more traffic than necessary
> in some common szenarios.

We try to minimize flags and settings in general as a design goal. Other 
implementations we looked at have too many "tunable" parameters, people 
writing in forums/mailing lists how and why these settings should be set 
without really understanding it ... This is why we try to not expose 
everything, even if we would leave a little bit of room for improvement.

I'm not against the flags, but its good to have a discussion to find out what 
is really needed ...

Cheers,
     Simon

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]