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

[Marek Lindner <mareklindner@neomailbox.ch>]

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

On Monday, March 28, 2016 15:43:21 Roland Volkmann wrote:
> > I am also unclear why this old patch is re-hashed once more since we
> > merged a patch 3 years ago achieving the same goal without a manual knob.
> > Can somebody shed some light on this ?
> > 
> > The patch in question:
> > commit cc1fde312b6d3c010784a80aff9e942e3b16d015
> > Author: Matthias Schiffer <mschiffer@universe-factory.net>
> > Date:   Sat Mar 9 23:14:23 2013 +0100
> > Subject: batman-adv: send each broadcast only once on non-wireless
> > interfaces
>
> this patch/commit addresses another issue than the "new" request 4384: 
> it limits the number of broadcasts to be transmitted on an interface, 
> with the limit automatically adjusting depending of type of interface.
> 
> Request 4384 allows to suppress broadcast packets completely on the 
> interface, where the node has received them (no rebroadcast). This is 
> typical behavior of physical switches, where broadcasts are sent out to 
> all ports except the one, where the packet was received.

Thanks for the clarifications. Given the situation at hand it seem fairly 
simple to extend the existing logic to prevent re-broadcasting on links 
without packet loss.

I am fully aware that adding a setting presents itself as the easiest solution 
but it comes with major drawbacks such as:

 * Once exposed interfaces to user space can never be removed. We have to 
carry this around forever. Thus we need a really good reason to do so.
 * When we let the user decide to configure $something there is a high chance 
the setting ends up being misconfigured and causing frustration in the end.

Prevent rebroadcasts when possible to reduce overhead is a good idea. However, 
I'd like to explore all options to auto-detect whether or not rebroadcasts on 
the same interface are needed or not. The only case requiring investigation is 
the 'tinc without forwarding' and 'without meshing' ? Can you provide insights 
as to what that means and whether or not tinc/fastd 'export' their internal 
state via an interface flag or something along those lines ?

Cheers,
Marek


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