On Sat, Oct 05, 2024 at 05:37:19PM +0200, Sven Eckelmann wrote:
On Saturday, 31 August 2024 21:45:28 CEST Linus Lüssing wrote:
In most setups it is sufficient for us to only send MLD reports to nodes which have a multicast router attached. Which reduces overall overhead, especially in large batman-adv mesh networks, where broadcasts are particularly undesirable.
What is the situation before.
For Gluon the situation was that IGMP+MLD is filtered via ebtables, because it otherwise would have a significant broadcast overhead.
For batman-adv the situation was that IGMP+MLD got flooded so far.
How does this change try to modify the behavior.
With this option a node would only send it to detected multicast routers instead.
Why is this good?
I would like to enable layer 3 IPv6 multicast routing between Freifunk communities / Gluon domains. But without the broadcast flooding overhead, to stay somewhat scalable.
And the reason why I would want to do layer 3 multicast routing: Right now multicast has a chicken & egg problem: There aren't many transmitters or receivers for it (other than ICMPv6 Neighbor Discovery or mDNS). However one strength of multicast lies in the significantly increased throughput when there are many simultaneous receivers.
So I'm hoping that while at Freifunk Lübeck with its ~200 nodes / ~200 clients domain I'm basically the only one using it that if there were all 40'000 Gluon nodes connected on layer 3 that the chances of a multicast stream being received by multiple people would significantly increase. Also more multicast content should then become available for everyone.
It also doesn't mention anywhere that the old (multicast filter) behavior was just to handle IPv4/IPv6 messages and it is now expanded to IGMP_HOST_MEMBERSHIP_REPORT + ICMPV6_MGM_REPORT.
Ok, maybe I should have written that more directly in the first two sentences.
However there is one specific, known issue / broken scenario with this setting:
If the IGMP/MLD querier is configured directly on the bridge on top of bat0. But there is no multicast router on or behind this node. Then this bridge will be unable to detect multicast listeners on/behind other nodes which have the MLD-RTR-ONLY setting enabled. (A workaround for this can then in turn be to set multicast_router=2 on the bat0 bridge port on the node with the IGMP/MLD querier.)
Therefore MLD report flooding is kept the default and MLD report to multicast routers only forwarding is considered experimental and warned about.
Most of the text here seems to suggest that (whatever reason you want to enable it), you should most likely not do it because it just creates more problems.
Right, in most cases I wouldn't suggest people to enable it. As can be seen in the wiki page examples it is not trivial. I would only suggest enabling it in setups where you have thoroughly checked your use-case against the ones in the wiki. And then only if you care about layer 3 multicast routing in the first place.
The commit message doesn't show me why I should apply this change in the first place - especially when it just causes more headaches in the end.
Another headache I get is the "Warning: MLD-RTR-ONLY is experimental and has known, broken scenarios" part. Which seems to suggest to me that there might be changes in the future which will cause more problems if I just apply this patch now - and in this process create ABI incompatibilities or "no regression" conflicts later.
I don't have any future ABI changes for this in mind. This was more thought as a warning that the list of examples in the wiki might not be exhaustive. I could only find one setup where enabling this option would not work, but despite having spent several days thinking about these scenarios I can't guarantee right now that it's the only one. That's why I wanted to mark it as experimental.
Btw. BATADV_ATTR_MULTICAST_MLD_RTR_ONLY_ENABLED seems to suggest that it is about MLD - but it seems to be also about IGMP. At least I didn't expect this.
Yeah, it's a bit annoying that for IPv4 it was named IGMP and for IPv6 it was then renamed to MLD even though the protocol is 99% the same thing. I'm not sure if it would make sense to make two separate knobs for IGMP and MLD? (I kind of more and more have the stance that where "legacy IP" creates extra hassle to ignore it where possible. And multicast with IPv4 is not as much fun as with IPv6 anyway, where you have things like embedded RP etc.)
Kind regards, Sven