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

Hitoshi Asaeda <> Sun, 29 March 2020 03:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0917A3A0EF6 for <>; Sat, 28 Mar 2020 20:08:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.2
X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GcSfuTypVhBg for <>; Sat, 28 Mar 2020 20:08:38 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::62a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B2DE13A0EF4 for <>; Sat, 28 Mar 2020 20:08:38 -0700 (PDT)
Received: by with SMTP id s23so5205517plq.13 for <>; Sat, 28 Mar 2020 20:08:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rIGYQc0jnKEjAWqSVJH5kZdQB+Vfo5+HUtwG0TKQeGI=; b=M1Ui4susea/h23Z1ss925vrVt5+/izx0QgtPnwagPORB9lxMy8vhJ3d/wXJSvGxOYE Nvpr05hsDpClajIRRVw/LEvM05qj7GRq9v00ODDYRB6e6hmTXXI878tBOzqBf881a7UF BXj9rMLtfrgYWJ0VgWux9hZuD0IlYO31o1M/Q=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rIGYQc0jnKEjAWqSVJH5kZdQB+Vfo5+HUtwG0TKQeGI=; b=Z9LmnWhtLnrx/LqeeJo3a7VUutJD9XNzxBDV4WHc5VAy8JSrfueyxRlvJ0gmXqCTvs ArRhOOVyrkIrJ9776hkfIukGxkuZpiDUK5vAInGlC4SoqJTmoU5uU+VveZGtmoXBLc5h UuX/yJcknobkYxQyV+5E6paam6S2IEbqlBiCpusQiD7Im9g1o3CFkTPDiolCyi8jjgAp 0xqrw60ArMs+eUTSQVAST5VrVeklKiDXUfG8o7hhCtmmb9zkmFgTaarWALZ86g2ZPPYq xJi3zNNbTOwxO59sY77eYYt3D9Pz9MDhA3j8/lFob5inMi8irIGT0/1aVKwuZ/1Z8kkE 7d/Q==
X-Gm-Message-State: ANhLgQ0l56npvfT+YNL+Crus1D3G4pT7H9rWSlGF08rpFGLx07y9N6FH aQNduBXkVbL6X6ICqTJ9qf5phw==
X-Google-Smtp-Source: ADFU+vtssZytFPfi5OKzP1x4mQDrhij6mBjYFwafmhdodjLizJcD6wyxEzIkuIPjJkbS/03OXJssHg==
X-Received: by 2002:a17:90a:14f:: with SMTP id z15mr7998169pje.137.1585451317922; Sat, 28 Mar 2020 20:08:37 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id g7sm122073pfo.85.2020. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 28 Mar 2020 20:08:37 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.\))
From: Hitoshi Asaeda <>
In-Reply-To: <20200328193311.GL2357@otheros>
Date: Sun, 29 Mar 2020 12:08:33 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <20200324205402.GD2357@otheros> <> <20200325113540.GF2357@otheros> <> <> <20200328193311.GL2357@otheros>
To: Linus Lüssing <>
X-Mailer: Apple Mail (2.3608.
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: Sun, 29 Mar 2020 03:08:40 -0000


> On Mar 29, 2020, at 4:33, Linus Lüssing <> wrote:
> On Fri, Mar 27, 2020 at 07:19:34PM +0900, Hitoshi Asaeda wrote:
>> 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.
> Oh, thanks! I didn't know about this RFC before. It's an interesting
> read.
> It's maybe not 100% what you were thinking of with "Explicit
> Tracking of Membership Status", but it makes me wonder if the
> following approach could help:
> (1) We already track host and not just port based listener state
>    for the Linux bridge "multicast-to-unicast" conversion feature
> (2) We could avoid timing out host based multicast listener
>    entries. And only remove such an entry in the following two
>    cases:
>    (i): The host vanishes in the Linux bridge FDB or
>         even only if it vanishes on the 802.11 layer
>    (ii): If an MLDv2 Report was received, but did
>          not contain the specific multicast group anymore
>    (iii): An MLDv1 Done was received for the specific group

Interesting discussions.

It might be a different topic, but in fact, there is an explicit tracking draft (*) expired about a few years ago. It failed IESG review because they said the specific experiments were not explicitly described in the draft even though its intended status was experimental.
It'd be great to resume the activity if someone who has the experiments of the explicit tracking function could give some inputs for this function from implementors'/operators' points of views (or even better work together for this document).



> Regards, Linus