Re: [Mcast-wifi] Issues with MLD and Android powersaving / sleep mode...
Linus Lüssing <linus.luessing@c0d3.blue> Sat, 28 March 2020 18:55 UTC
Return-Path: <linus.luessing@c0d3.blue>
X-Original-To: mcast-wifi@ietfa.amsl.com
Delivered-To: mcast-wifi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7BED3A0C48; Sat, 28 Mar 2020 11:55:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.697
X-Spam-Level:
X-Spam-Status: No, score=-1.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=c0d3.blue
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Rua0Evwu3VZ; Sat, 28 Mar 2020 11:55:03 -0700 (PDT)
Received: from mail.aperture-lab.de (mail.aperture-lab.de [138.201.29.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E21DB3A0A4F; Sat, 28 Mar 2020 11:54:58 -0700 (PDT)
Date: Sat, 28 Mar 2020 19:54:54 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=c0d3.blue; s=2018; t=1585421696; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=YitgTo4V6FfDQAocqjSfjmW0RVSpJXyt6VL8nidxIKE=; b=l3rE5t0txvO+5AYWt96AR4IerqfcV6dE/hVuki/WUK0raFFa+UOonMX4mi4aP6zgihVaOX KOMN8CZY+no2v8LMG/9ktCEX5HtZtQcNAytaaCL7zBhdp8ER6W5WLgSerVkTp54qRpDpf6 Mlxri3OC8vPTXKMIil9jQnvXcEmIo8/k0nZA9vrCUp0AGD0E9fwpFKne1u0rePjkGlc/sJ KxyinKLAPxzOcDu0MV33Uq/kFDHhA3A7URKr5hXSaiBDBIXD286eUyGz3hgZ0sI3dXYaj7 Gmh+PVxknTfJ4RIosUIzzAAIzXCgRFQU6pot1/1jrXTRM71ZCYU8vOmZ4ZFYSA==
From: Linus Lüssing <linus.luessing@c0d3.blue>
To: otroan@employees.org
Cc: mcast-wifi@ietf.org, pim@ietf.org
Message-ID: <20200328185454.GJ2357@otheros>
References: <20200324205402.GD2357@otheros> <F4353336-2AA9-4A51-A9FF-5802060D0626@employees.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <F4353336-2AA9-4A51-A9FF-5802060D0626@employees.org>
Authentication-Results: ORIGINATING; auth=pass smtp.auth=linus.luessing@c0d3.blue smtp.mailfrom=linus.luessing@c0d3.blue
Archived-At: <https://mailarchive.ietf.org/arch/msg/mcast-wifi/TGmvGzxqedKhyCF9zAeqRC2qaiw>
Subject: Re: [Mcast-wifi] Issues with MLD and Android powersaving / sleep mode...
X-BeenThere: mcast-wifi@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussions related to issues with multicast in 802.11 Wi-Fi networks & solutions/optimizations targeted at resolving these issues." <mcast-wifi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mcast-wifi>, <mailto:mcast-wifi-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mcast-wifi/>
List-Post: <mailto:mcast-wifi@ietf.org>
List-Help: <mailto:mcast-wifi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mcast-wifi>, <mailto:mcast-wifi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 28 Mar 2020 18:55:08 -0000
Hi Ole, On Sat, Mar 28, 2020 at 04:50:08PM +0100, otroan@employees.org 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
- [Mcast-wifi] Issues with MLD and Android powersav… Linus Lüssing
- Re: [Mcast-wifi] Issues with MLD and Android powe… Mark Smith
- Re: [Mcast-wifi] Issues with MLD and Android powe… Dino Farinacci
- Re: [Mcast-wifi] [pim] Issues with MLD and Androi… Linus Lüssing
- Re: [Mcast-wifi] [pim] Issues with MLD and Androi… Dino Farinacci
- Re: [Mcast-wifi] [pim] Issues with MLD and Androi… Hitoshi Asaeda
- Re: [Mcast-wifi] [pim] Issues with MLD and Androi… Dino Farinacci
- Re: [Mcast-wifi] Issues with MLD and Android powe… otroan
- Re: [Mcast-wifi] Issues with MLD and Android powe… Linus Lüssing
- Re: [Mcast-wifi] [pim] Issues with MLD and Androi… Linus Lüssing
- Re: [Mcast-wifi] [pim] Issues with MLD and Androi… Linus Lüssing
- Re: [Mcast-wifi] [pim] Issues with MLD and Androi… Mark Smith
- Re: [Mcast-wifi] [pim] Issues with MLD and Androi… Hitoshi Asaeda