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

Dino Farinacci <> Fri, 27 March 2020 22:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A0AAA3A0C2A; Fri, 27 Mar 2020 15:09:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pVrmIyHMTubV; Fri, 27 Mar 2020 15:09:19 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::102e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 85F143A0BD6; Fri, 27 Mar 2020 15:09:19 -0700 (PDT)
Received: by with SMTP id l36so4426919pjb.3; Fri, 27 Mar 2020 15:09:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mL35V6kFbMIpJfvtm/k/vE4at4+DW9fNUuoNs33oCfo=; b=achC4Qa8KpumN58fuHLNT+HAO3kEBFKWvu/By79qR0tbqS9FpaMlfFV15joTUFbTyW Rq0Q24FGjvttqQX+ArpbC7X+ac1PmQFHwU3PJL0lIlhmWCzU6iGZPLV1Op+pyTS7UkRo UQD+/4ZupTHT9UJN+N2Q2DAlFlqPKqycFf5/92u0+eS6EoXmQWOIHKOFZyADhMX2qaPJ 0hHelTkuMWt+GxQrR/rWXsNJ4prWw0Jjcvj0ZIOYUasKGDEiTDZ0bijLGklZDpIfu1tB tKnSCaxAtR41vHuGy3FoTsDx/bm7CTSsS1zBDJuuNtVrEmWEZ6Q7tgIB2M6TRRXShSaK SlwQ==
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=mL35V6kFbMIpJfvtm/k/vE4at4+DW9fNUuoNs33oCfo=; b=DWZnyBwK61H1uslX94UZL/DTkZ2NtQ4ZKjTYlIYqBGYLapIf7g3TyXYo3uJMdBSqbk mb835SlSUkbWuPM+myZqAcD6kp08DQQgCHNsGylgjAMJF4PmBls8fXRom9e3Yy4JONmQ iOFF8zu9fSQLzvgKSdKN/+go6b2xgFCqd+8vnwWFYA4Unpeb7+V5r1CngQ5ernMUtjaf okiRzvfrDzkyefgWDqiIohw72rZ7H3VLq5+DnyI6N5QL5zJsG17ViJF7w8H84qAZ28IY JEdb8kWv3IqMWanaXJTRLV9QoCVdnKkTVb+JrjxNxLu0wwE8WwZK20TiwoW5Yonle1Lj sc4w==
X-Gm-Message-State: ANhLgQ0u0mijQAtyV+nRxa2NypA7a9MIbfM8z9VCi3izIF90ZmX2uGla HDOeWson0E51caELaGvmGzE=
X-Google-Smtp-Source: ADFU+vsTt4y/j/CteQxS6n9k/0SKI+bEjC+Tva/4vNIupRNnxN0/QxOWUGYuSkO71EMGS1NjARaDDA==
X-Received: by 2002:a17:902:7204:: with SMTP id ba4mr1197182plb.232.1585346958855; Fri, 27 Mar 2020 15:09:18 -0700 (PDT)
Received: from ?IPv6:2601:646:9600:af10:7c8c:d5c7:5b6f:bc0? ([2601:646:9600:af10:7c8c:d5c7:5b6f:bc0]) by with ESMTPSA id s137sm5069104pfs.45.2020. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Mar 2020 15:09:18 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.\))
From: Dino Farinacci <>
In-Reply-To: <>
Date: Fri, 27 Mar 2020 15:09:17 -0700
Cc: Linus Lüssing <>,, Mark Smith <>,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <20200324205402.GD2357@otheros> <> <20200325113540.GF2357@otheros> <> <>
To: Hitoshi Asaeda <>
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: Fri, 27 Mar 2020 22:09:21 -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.

The techniques in this RFC are good but to get bang for the buck, the quering router needs to support Explicit Tracking, as you stated in the document.

But the RFC does not say what to do when a mobile node goes to sleep and how it should, or if it should, be woken up to refresh group membership status.

One important technical questiont that should be asked and answered is: 

Should a mobile host send a Leave message when the app is still joined to the group but the phone wants to go to sleep.