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

Mark Smith <markzzzsmith@gmail.com> Tue, 24 March 2020 21:40 UTC

Return-Path: <markzzzsmith@gmail.com>
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 0B9623A0EAC; Tue, 24 Mar 2020 14:40:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.599
X-Spam-Level:
X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.998, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 dtP6j9MtcVhr; Tue, 24 Mar 2020 14:40:36 -0700 (PDT)
Received: from mail-oi1-x242.google.com (mail-oi1-x242.google.com [IPv6:2607:f8b0:4864:20::242]) (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 AB7D93A058F; Tue, 24 Mar 2020 14:40:36 -0700 (PDT)
Received: by mail-oi1-x242.google.com with SMTP id v134so98872oie.11; Tue, 24 Mar 2020 14:40:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=HQ/jcZA0c9yg9LqiTr2vwRjS8xqVLkTZN5fGOGZXUEM=; b=BjqiLpJVg/lOSPcZzd2DbeXJh3Mk4VVZhHrknWJ5Mss5VPwkRzg0UN1rRGBw9Tter0 leaAyxIfvhx/yjv91R39tcOo3qohGt+O3+G/2oiv2Jy+talygSNnIgctaEuf2cxxzAOJ n2ePRPTAdTM7aJF6eXI5cE6+GQq9seEgaskR8S4QL+cJX9ajMXdUtHErlGJ4enbqYEoE 6UleEOl//f3SvNXRp8LNC3WHmkBjmEaMDlDlbRwEoruwfYmBkUwj4lNNCO24epHIb2Xg +L+rU7BmKO5jPRtmsArjyK4vfFeF9BIfekUhw6e1rB0dwe9NTTPloGxD6wUF5SiMEVIa V8Aw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=HQ/jcZA0c9yg9LqiTr2vwRjS8xqVLkTZN5fGOGZXUEM=; b=Z4SS08xNZhhm1PV+Q1nMkMKgmF0slrn7ku5Y7aAKT5C1yys82Br7cBbP4DFf3XN6Be omZkRje70b4Q7TIr/IjH0LBNSSLu6SALXb8bk4zD/YAXg69VoNxjjxAfejfN9aiiGHiS CKShwiv7umvH614rDv/TUzmV41oZI8bkWyZqy3KD0RJpkiYGQdoBcy0O8nv/UjAMBxp+ 4FUBAJ2uByzqp4DtvFCwdeLyBdIh0e8Nbah9cg3QtDHMzEWJyuXmv/cYkWDYTsemIUj2 k0+RYaG2IoZMs/X9FcaK2PMHD4jwZnBi/76a5XVPt6VSJn8CxR1G8iVH9hTLuYqFD3i9 KdNg==
X-Gm-Message-State: ANhLgQ3KK7+SVkTtpLisCvMvuZiZBjrukg1EzUlBipxGt4J8D2HZQuHT /83cS0KYIAI4HsszT9SuDsuzUr+XNSbSeVix/kO3jQ==
X-Google-Smtp-Source: ADFU+vvx/G2tcH5PggZKkNz9GZCySRuF9lVRCbghIagtUxsuOE4H4vchh+XtnS/9auGe9n7EHa2AJfuIFU5GOjtL6kM=
X-Received: by 2002:aca:d78a:: with SMTP id o132mr282908oig.60.1585086035610; Tue, 24 Mar 2020 14:40:35 -0700 (PDT)
MIME-Version: 1.0
References: <20200324205402.GD2357@otheros>
In-Reply-To: <20200324205402.GD2357@otheros>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Wed, 25 Mar 2020 08:40:09 +1100
Message-ID: <CAO42Z2zKxbJU85y9GT6tyF93MwbsXKWeFWRPAYXP6KHkn+L+8g@mail.gmail.com>
To: Linus Lüssing <linus.luessing@c0d3.blue>
Cc: mcast-wifi@ietf.org, pim@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/mcast-wifi/DnHGezjJy43_8stYjd-x1VpacSU>
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: Tue, 24 Mar 2020 21:40:38 -0000

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.



>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.

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