IETF Logo Mail Archive

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

otroan@employees.org Sat, 28 March 2020 15:50 UTC

Return-Path: <otroan@employees.org>
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 D41B53A0A32; Sat, 28 Mar 2020 08:50:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 hq9HQEy0NcKR; Sat, 28 Mar 2020 08:50:14 -0700 (PDT)
Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 297CE3A0A2F; Sat, 28 Mar 2020 08:50:13 -0700 (PDT)
Received: from astfgl.hanazo.no (76.84-234-131.customer.lyse.net [84.234.131.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 819FA4E11B3A; Sat, 28 Mar 2020 15:50:12 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 0A552306A3E7; Sat, 28 Mar 2020 16:50:09 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: otroan@employees.org
In-Reply-To: <20200324205402.GD2357@otheros>
Date: Sat, 28 Mar 2020 16:50:08 +0100
Cc: mcast-wifi@ietf.org, pim@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <F4353336-2AA9-4A51-A9FF-5802060D0626@employees.org>
References: <20200324205402.GD2357@otheros>
To: Linus Lüssing <linus.luessing@c0d3.blue>
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mcast-wifi/7PnrhS09WFX-gQAUH4f17Bjs7Pk>
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 15:50:16 -0000

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.

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?

Best regards,
Ole

> On 24 Mar 2020, at 21:54, Linus Lüssing <linus.luessing@c0d3.blue> wrote:
> 
> Hi,
> 
> With Freifunk [0] we lately came across an annoying issue with Android
> devices... which I'm not really sure how to solve yet...
> 
> It seems that (some?) Android devices do not respond to MLD
> queries when in sleep mode:
> 
> https://github.com/freifunk-gluon/gluon/issues/1832
> https://issuetracker.google.com/issues/149630944
> 
> Which causes severe IPv6 connectivity/usability issues
> when trying to use MLD snooping capabilities.
> 
> 
> As soon as you turn on the screen of the Android device or
> connect a charger MLD Reports arrive just fine. My test results
> were, as noted in the Android ticket:
> 
> Results with phone on battery:
> * 0/8 MLD Reports received
> * 3/8 Neighbor Advertisements received
> * 8/8 Echo Replies received
> 
> Results with phone on charger:
> * 8/8 MLD Reports received
> * 8/8 Neighbor Advertisements received
> * 8/8 Echo Replies received
> 
> 
> Fixing this on the Android devices would need several years to
> propagate, as noted by an Android dev.
> 
> 
> Has anyone on this list experienced similar issues, too? And is
> there maybe even someone who came up with a workaround that they
> implemented on the router/switch side?
> 
> If not and if we can't come up with a solution it looks pretty
> gloomy for (non-flooding) multicast in wifi networks to me for
> the next years...
> 
> Regards, Linus
> 
> 
> [0]: https://freifunk.net/en/
> 
> _______________________________________________
> Mcast-wifi mailing list
> Mcast-wifi@ietf.org
> https://www.ietf.org/mailman/listinfo/mcast-wifi

v2.23.0 | Report a Bug | By Email