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

Hitoshi Asaeda <asaeda@ieee.org> Fri, 27 March 2020 10:19 UTC

Return-Path: <asaeda@ieee.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 7C7CA3A093A for <mcast-wifi@ietfa.amsl.com>; Fri, 27 Mar 2020 03:19:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ieee.org
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 xVO93vRflam7 for <mcast-wifi@ietfa.amsl.com>; Fri, 27 Mar 2020 03:19:39 -0700 (PDT)
Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) (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 6EE9A3A044E for <mcast-wifi@ietf.org>; Fri, 27 Mar 2020 03:19:39 -0700 (PDT)
Received: by mail-pj1-x102e.google.com with SMTP id nu11so3593010pjb.1 for <mcast-wifi@ietf.org>; Fri, 27 Mar 2020 03:19:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee.org; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MUbYaumpyuROoBbIBeyyQdcVjfCCsqsgTvEYQ8vUpcE=; b=IOuXTg3oBsR4xcToWP3aGsplWADgffJLZMdlwiURfFvOfMN+UHMIPlN55ff65GFADF tkX50FtTDohXWd5MejjFk49K3mDlpLPTbxjqfVrU8/UqXS+9eWRWcISxgALk8dcNna5J deASGDfWHJKFxACmWGKgfjV2OBJDOLQsWTs6w=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MUbYaumpyuROoBbIBeyyQdcVjfCCsqsgTvEYQ8vUpcE=; b=nTpSmIArCiouH5F511EhfViTABOBaMwafQbW3ku5Qy4eaV6hWP2SqaAmaQ3HiDKAQO xSGOZch8m/VNxAkquXGGAFDaYxuBRO/llGt7dILtFK39+bs5iXEVXu3jgDMkL9l0rLHW 84o9FKbzlCZyydPGyDjF/2CQ+//qfvGF/jqOk8ZT8IyAdq6z4rnQyS3ODHL2wrH+R+4i iiXVw3w1sGZwOzO6qMZDDLMqMtHs70kILjWW0r3FSE1r0h7jmvr8bolc9uIdru6Ys4Rr UeXpnPCdfXQlLQp77hRK3DPQdauAFwaP3fDoVYjYHS+8Pq1o4wp6pUZoIiMMab+ROgUk xksw==
X-Gm-Message-State: ANhLgQ0FhVvV25RkyUYewRPGgKnDyNMNC6FHO7OG+FQ+CgjTFdSt7Wt5 I4MVZ6+xddCIOXVZOAStPw6NJw==
X-Google-Smtp-Source: ADFU+vszmWAk1UB+GWVJ7AydNZ+3Y8LHUJ/VGGAs6xDWv//jV5i92wPsmOUcGsBQ642jeqAIWGDDuQ==
X-Received: by 2002:a17:902:d712:: with SMTP id w18mr12966014ply.238.1585304378668; Fri, 27 Mar 2020 03:19:38 -0700 (PDT)
Received: from [192.168.11.5] (zz20164245726F66C1A1.userreverse.dion.ne.jp. [111.102.193.161]) by smtp.gmail.com with ESMTPSA id s4sm3738347pgm.18.2020.03.27.03.19.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Mar 2020 03:19:38 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Hitoshi Asaeda <asaeda@ieee.org>
In-Reply-To: <F20FA68B-ED13-4459-8DE7-83AD970D3BFD@gmail.com>
Date: Fri, 27 Mar 2020 19:19:34 +0900
Cc: Linus Lüssing <linus.luessing@c0d3.blue>, mcast-wifi@ietf.org, Mark Smith <markzzzsmith@gmail.com>, pim@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <203AAA04-E7BA-4A21-8E66-D754A7CB823F@ieee.org>
References: <20200324205402.GD2357@otheros> <CAO42Z2zKxbJU85y9GT6tyF93MwbsXKWeFWRPAYXP6KHkn+L+8g@mail.gmail.com> <20200325113540.GF2357@otheros> <F20FA68B-ED13-4459-8DE7-83AD970D3BFD@gmail.com>
To: Dino Farinacci <farinacci@gmail.com>
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mcast-wifi/FQVYcTtFdWHwXn-kwO4KWAAbMcQ>
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: Fri, 27 Mar 2020 10:19:42 -0000

RFC6636 (Tuning the Behavior of the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) for Routers in Mobile and Wireless Networks) gives some guideline to tune IGMP/MLD.
Android and iOS implement some specific mechanisms to save battery power, hence I don't know if they work what we expect, though.

Regards,

Hitoshi


> On Mar 26, 2020, at 5:40, Dino Farinacci <farinacci@gmail.com> wrote:
> 
> Another way to solve the problem on the head-end side could use this algorithm:
> 
> (1) Queries (using this term “query" to apply to both IGMP and MLD) are sent periodically to the well-known group. That means queries get to phones that are not sleeping. This is what is done today.
> 
> (2) If the querier sees reports (using this term “report" to apply to both IGMP and MLD) it obviously knows the phone is up and what groups it is interested in. That sets a keep-alive timer for the phone.
> 
> (3) When keep-alive timer expires, the querier doesn’t know if the phone is down, asleep, or not joined to any groups. But (this is a new addition) it sends a unicast query to the phone.
> 
> (4) If a report is received from the phone, you know the phone is not down and is interested in at least one group. Do normal report processing.
> 
> (5) Note the query wakes up the phone when asleep.
> 
> This is a simple solution which can be made more robust with complexity, but does get the job done.
> 
> Comments?
> 
> Dino
> 
>> On Mar 25, 2020, at 4:35 AM, Linus Lüssing <linus.luessing@c0d3.blue> wrote:
>> 
>> 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
>> 
>> _______________________________________________
>> 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