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

Linus Lüssing <linus.luessing@c0d3.blue> Wed, 25 March 2020 11:35 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 4A84E3A08EE; Wed, 25 Mar 2020 04:35:47 -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 hXoJ2KhVcdN3; Wed, 25 Mar 2020 04:35:45 -0700 (PDT)
Received: from mail.aperture-lab.de (mail.aperture-lab.de [IPv6:2a01:4f8:171:314c::100:a1]) (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 4A4E53A08B1; Wed, 25 Mar 2020 04:35:45 -0700 (PDT)
Date: Wed, 25 Mar 2020 12:35:40 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=c0d3.blue; s=2018; t=1585136143; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=A3/N6yCeIluIjIGCQA/d+JIfJIFGBHQ/1ycwJVvnbKY=; b=f0+Ar1e0LN3yZaNnr2hX+shqS0wR5haxnRcd9NTlIG/y/KM6OevlHUWKUsU4uRPjkmPwJF cDc5WXdAv+n5j38Zx9eTqshY4idWFEH5j+ActLYatBlnBfmMsL59105xNmHYGaxCa4OTRw L0oUjMahavSU2oz637PMzheX0H/f9HSQD8X/vUvdjs0p4dcF7deMTd6HyAauZCi1N8m+rg P+Qf8jaCH22dMLe6VvCyb0ysSyrBQfdg/n+mfzLi8R/rBrlsvkQDtkiYZM2glfGJ0FOtO9 0bFkNSoVUI8oEQpsxDGdqIxYuAnsLIiWXqXnwgfymKsUR7760GPnWxT2G0ZDQQ==
From: Linus Lüssing <linus.luessing@c0d3.blue>
To: Mark Smith <markzzzsmith@gmail.com>
Cc: mcast-wifi@ietf.org, pim@ietf.org
Message-ID: <20200325113540.GF2357@otheros>
References: <20200324205402.GD2357@otheros> <CAO42Z2zKxbJU85y9GT6tyF93MwbsXKWeFWRPAYXP6KHkn+L+8g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAO42Z2zKxbJU85y9GT6tyF93MwbsXKWeFWRPAYXP6KHkn+L+8g@mail.gmail.com>
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/gCrMJ1r3NoPAsrjudqum-X22lqE>
Subject: Re: [Mcast-wifi] [pim] 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: Wed, 25 Mar 2020 11:35:48 -0000

Hi Mark,

> >From the above github link, it sounds like the real fault is that when
> Android wakes up it isn't immediately issuing MLD joins for its
> existing IPv6 addresses. I'll have to think about which IPv6 RFC
> advice to do that is probably in, however I think it should be - every
> time an interface comes up with existing IPv6 addresses, it should be
> sending MLD Reports to join the Solicited Node Multicast groups for
> its addresses.

Yeah, that'd be one way of solving it. At least that specific issue.
Back then I couldn't find an RFC mandating that though (also
see my mail from last December, section "Roaming" [0]).


I'm not really familiar with either Android or it's powersaving, but
wouldn't that approach still have issues with communications
initiatiated not from but to the the Android device? For instance
someone sends a text message to an app like Signal. You'd want to
receive that timely and get a notification. And not just the next 
time you turn on the screen (and by that wake up the device).

So ICMPv6-NS to the Android device must work and as it uses a
multicast destination, MLD Queries/Reports would need have updated
any MLD snooping bridges/switches before that. Even when the
device is sleeping, right?


Also ICMPv6-NS with its multicast destination is received just
fine (with MLD snooping disabled), so it seems to me more like the
wifi drivers are not setting up their multicast wake up filters
properly.

The Android ticket references the "Android Compatibility Definition
Document" which allows some rate limiting or even filtering [1]. It
mentions ICMPv6-RA, but does not mention MLD. That might be the
reason why some vendors might have missed the necessity of MLD and
are therefore overblocking ICMPv6.


Anyways, as fixing every Android device out there would take
several years or is even impossible due to vendors not providing
updates (as noted by the Android dev in the ticket), pragmatically
speaking I currently don't see any way around implementing a
workaround on the router/switch side for the short term.
But I'd love to be proven wrong.

Regards, Linus


[0]: https://mailarchive.ietf.org/arch/msg/pim/DWWYpnsZsbqHtafwYZ_swhDpbcQ/
[1]: https://source.android.com/compatibility/7.1/android-7.1-cdd#7_4_5_minimum_network_capability


On Wed, Mar 25, 2020 at 08:40:09AM +1100, Mark Smith wrote:
> On Wed, 25 Mar 2020 at 07: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:
> >
> 
> If the device is asleep, effectively offline, why should it respond to
> MLD queries?
> 
> When I'm asleep I have to wake up or be woken up before I respond to
> queries too.
> 
> Times by a billion devices, responding to MLD queries while the device
> is asleep and not in use is going to be wasting a lot of electricity.
> 
> > 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.
> 
> 
> 
> 
> Regards,
> Mark.
> 
> 
> 
> > 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
> 
> _______________________________________________
> pim mailing list
> pim@ietf.org
> https://www.ietf.org/mailman/listinfo/pim