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

Linus Lüssing <> Sat, 28 March 2020 19:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 49FDE3A0BE4; Sat, 28 Mar 2020 12:48:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.697
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: (amavisd-new); dkim=neutral reason="invalid (public key: not available)"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3VJk9qJEU5xT; Sat, 28 Mar 2020 12:48:12 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F3C0A3A09EC; Sat, 28 Mar 2020 12:48:11 -0700 (PDT)
Date: Sat, 28 Mar 2020 20:48:09 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=2018; t=1585424890; 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=gjnXdAFGGd0SLhmuOv/hcL/Ff07/mOTvqI/IzbCkwW4=; b=Oj8UEfwrDrFG44CKgvyiU/jr+DEzL71H4vDFFge3UTM4RDbYzjQ5YwSkLUA2oUkmBIM6sj lX3k5gWlhXCP+tdNCX0AcMI4/csJhL+Xn4koqLe3OvZ7BBRT2Xwil4aPSShYbgIYM0/P6i DQ6hP6eXI6/0uQZ7//GIGajJw5INgg/USOIA89n1KsiYwXGQbjs4TGUrllQeDYiflZ6xG1 cXrDbt1cIcvztrMyCYBGOgvEVEwgTC26wQOS475aTtwXAjMWX7nAgLstOc1V/6kyeW7HBG RECM8yHMwBtfDFQA5SfWCJ5Bai8EEEOgjO3OluQ1BZ9f61Pecchhhs5Cnl+l6Q==
From: Linus Lüssing <>
To: Dino Farinacci <>
Cc:, Mark Smith <>,
Message-ID: <20200328194808.GM2357@otheros>
References: <20200324205402.GD2357@otheros> <> <20200325113540.GF2357@otheros> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
Authentication-Results: ORIGINATING; auth=pass
Archived-At: <>
Subject: Re: [pim] [Mcast-wifi] Issues with MLD and Android powersaving / sleep mode...
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Protocol Independent Multicast <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 28 Mar 2020 19:48:13 -0000

On Wed, Mar 25, 2020 at 01:40:33PM -0700, Dino Farinacci 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.

Thanks Dino! Seems to go in the right direction. Using MLD queries with a
unicast destination was also one of my first thoughts and tries.
But unfortunately even when using both a unicast MAC destination
and unicast IPv6 destination in the MLD Query I only get MLD Reports in
3 of 8 cases... Better than nothing, but still seems even unicast is
rate-limited. And I don't know yet what else besides MLD is accounted
in the same bucket for this rate-limiting, so in a realistic setup could
be even worse than 3/8 with other traffic flying around.

What I still wanted to try (but didn't do yet) was playing with
the suggestion in the Android ticket. That is sending specific
packets prior MLD which are know to not be filtered which might
hopefully wake up the device for a while. ICMPv6 Echo Requests
might be one candidate as in my tests they were never filtered.
But also not sure if that'd be the case for all Android devices.