Re: [Mcast-wifi] Issues with MLD and Android powersaving / sleep mode...

[Linus Lüssing <[e-mail]>]

Hi Ole,

On Sat, Mar 28, 2020 at 04:50:08PM +0100, [e-mail] wrote:
> Hi Linus,
> 
> The purpose of using MLD as a part of the IPv6 address resolution protocol (ND) was to help MLD snooping switches for the solicited node multicast addresses.
> My understanding is that most switches don't do that for the solicited node multicast address anyway, because of scale.
> This to the extent that I was unsure if we should bother having MLD on by default for solicited node multicast at all.

The IGMP/MLD snooping in the Linux bridge treats ICMPv6-NS with
its solicited node multicast address no different than any other
multicast traffic. And ICMPv6-NS is actually the main reason I'd
like to enable MLD snooping in our mesh networks.

Currently about 50% of the management overhead is caused by the
layer 2 mesh routing protcol itself (batman-adv). The other
50% is currently ICMPv6-NS between all these phones, laptops and
gateways which so far are flooded through the mesh. (after
filtering mDNS, LLMNR, etc., these protocols just don't scale right
now)

Since ICMPv6-NS commonly has zero recipients for
duplicate-address-detection and just one recipient for address
resolution, we would greatly benefit from full MLD snooping support
as we could just drop them on the first node or forward them via
unicast to its specific destination. Which would significantly
reduce our overhead and improve our scalability.


The second, but lower priority for MLD support is of course
allowing new applications like multicast streaming between
any hosts. Serverless multicasting would fit nicely with
a decentral mesh network.


> Interesting to hear there are platforms that find MLD snooping useful.
> Do you have a pointer or would you mind explaining how it is used in Freifunk?

Sure. I can't speak for all Freifunk communities. But about 40k of
the 50k nodes in Germany are using the OpenWrt based mesh
framework "Gluon" with the layer 2 mesh routing protocol
"B.A.T.M.A.N. Advanced" right now:

https://github.com/freifunk-gluon/gluon/
https://www.open-mesh.org/projects/batman-adv/wiki
https://freifunk.net/en/how-to-join/find-your-nearest-community/


So far MLD snooping is only used on the "last mile". So the Wifi AP knows
about the multicast listeners of its local Wifi clients. And this
allows us to safe quite some Wifi airtime already. Unfortunately
MLD is still too noisy in a layer 2 mesh network with a some hundred nodes
and a thousand or more client devices and not reliable enough in a frequently,
dynamically changing mesh topology. So we are mirroring the MLD state into the
mesh network, into batman-adv. batman-adv has a more robust
and less bandwidth hungry method optimized for mesh networks
(it sums the state with hashes and counters and then once a node notices
that it is not up to date anymore requests and usually receives just a
small diff from its neighbor node).

Anyway, before I get into too many details, here is the
documentation of what we have implemented and are currently using:

https://gluon.readthedocs.io/en/v2020.1.1/package/gluon-mesh-batman-adv.html#multicast-architecture
https://www.open-mesh.org/projects/batman-adv/wiki/Multicast-optimizations


And now we are about to enable the multicast optimizations in
batman-adv to have multicast listener awareness through the
whole mesh. After we hopefully solve the current issue with the
sleeping Android devices, that is...


There were also some initial patches and tests with IPv6
link-local multicast streaming, using the simple
multicast-to-multi-unicast frames conversion in batman-adv:

https://github.com/freifunk-gluon/gluon/pull/1357

Regards, Linus