Re: [Mcast-wifi] [pim] Volunteers needed for work on progressing IGMP/MLD on the standards track

Linus Lüssing <> Wed, 12 December 2018 07:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D25C7126CB6; Tue, 11 Dec 2018 23:13:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.999
X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham 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 4llhbZ5HUfJV; Tue, 11 Dec 2018 23:13:51 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 83079131115; Tue, 11 Dec 2018 23:13:50 -0800 (PST)
Date: Wed, 12 Dec 2018 08:13:43 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=2018; t=1544598826; h=from:from:sender: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: in-reply-to:in-reply-to:references:references; bh=WNHeu5w8vyCHxMBxHUYxJk+rGaE73f4Z+5SKw+3Uz54=; b=CN7sPiEcCLL49YMQLtT65TukUbJtUEtIBkLpZyMIuzfoEZxr5f2G0yReeftnGeXfX3WwIh IJ4AYiQNqKy7eoF5U7oLzebQvyuQzdE6CKhiwMWVKjGF/DrtyZniza//V7SPqUR+Urozbk cytFAogcNEjgHNVbGCwOmAOeSAU6giP30IriGPHLzMe3Gixwp5d9ztWwRdeLuHixhZVgJE zeXYNZnpARQEYvKinMe0Pt/58lUtbSACmKhFIxt3hqf8roL7SAPVpWZwy6YMA2Fip3Nkep M4kB5yEEBzrMsJ2QVPZf8R1nD4lrfHvDjNVecoqYeQmtRvMwluck93vx/NPd2w==
From: Linus =?utf-8?Q?L=C3=BCssing?= <>
To: Stig Venaas <>
Message-ID: <20181212071343.GC9328@otheros>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <>
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=2018; t=1544598826; h=from:from:sender: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: in-reply-to:in-reply-to:references:references; bh=WNHeu5w8vyCHxMBxHUYxJk+rGaE73f4Z+5SKw+3Uz54=; b=icGgoRSUmWQta5c58wHH2044wImhf+dHOcO0Z3u8YIvO/BGnt9QbBBthqMj6l833aC1My4 YG8rE4ZYMlAvMrC/Ql8ZYZTSyVYAjcrG5AO9kIDS2fCMS+bxS5UFXI3jIPBhZcHsHUHTN5 1HOoL/DsFEOVR6az/Zfp05D6au/m+AC62p/BYX/zSwCvLXwetCwYU0zSpMfFtGBnuwEauo k/LigWjhNQSUpKtP9sk536z1wU6XZoe1K1yIad0sNC0LIZCn22h9JtAP3kskq8tUJQvUKP 32tyQNWGqPRCd2m+c8a2ubkNGr5rH01UhRd+bZz4hyxgBYnV17B7j0MDtAETVA==
ARC-Seal: i=1; s=2018;; t=1544598826; a=rsa-sha256; cv=none; b=g9mfJdOKL0Ym1Oh2wMa6LRbBoW0jFI7DfXHt5llWRztcTp8cQfN5x/V43ALyzDuVwlmQo2 0WMZ2Kr1Az4fFZtr+3qvV9lfxBZnzUm0xwDfDd1KwPNvrcEjtWuMSITFKzX2MG3K7u+TUG +LZrao6cHCwZAW7GkDLAWERXRvs+fCmGRi4xh+ItRwfG65iXcBfrinOQFWpavq+VH0yyJ9 ZE6aLJA+4andOOEQ53AMONe1PSwe8sKzpdTqFSPmkks2IngeeGd9UXVl8wZfZKrjFKbx13 +0G97tCmnQA7iUgguwJnP2uWCVkIQlQoy05AxDVESoNmpG9nD9a4JIRv/zAEWg==
ARC-Authentication-Results: i=1; ORIGINATING; auth=pass
Authentication-Results: ORIGINATING; auth=pass
Archived-At: <>
Subject: Re: [Mcast-wifi] [pim] Volunteers needed for work on progressing IGMP/MLD on the standards track
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 12 Dec 2018 07:13:54 -0000


Just wanted to share three annoyances with IGMP/MLD we have been
experiencing in the development of the layer 2 mesh routing
protocol "B.A.T.M.A.N. Advanced" [0]. It is an Open-Source
implementation in the Linux kernel and is currently in use by
various commercial and non-commercial (for instance Wireless
Community Networks like Freifunk [1]) networks.

# Report Suppression

The report suppression makes it very challenging to achieve a
decentral layer 2 mesh network. For one thing, as RFC4541 notes,
due to report suppression multicast snooping switches need to forward
all multicast traffic to the querier to avoid potential multicast.
Secondly, according to RFC4541 all reports may only be forwarded to
multicast routers.

While MLDv2, section A.2 claims to not suffer from report suppresion,
it still says in section 8.1.1:

"A host MAY allow its MLDv2 Multicast Listener Report to be
 suppressed by a Version 1 Multicast Listener Report."

(Although this is maybe more a question of deprecating IGMPv1/2
and MLDv1?)

Fyi, these are the hoops we had to jump through thanks to report
suppresion to implement just some degree of multicast optimizations:
[2] and especially [3].

# Querier election

The querier election process is not a feasible option in a dynamic,
wireless layer 2 mesh network. Nodes (= mesh routers) and hosts
(mobile client devices) are constantly joining and leaving the
network, with widely varying degrees of packet loss between each

The workaround that was implemented in the software used by many
Freifunk nodes running batman-adv was to run a querier on each
node, instead of having one querier for the whole layer 2
broadcast domain. And to disable the qurier election
queries are filtered between nodes.

To me, the querier mechanism seems more like a curse than a
blessing. I would prefer if IGMP/MLD would periodically send
unsolicited reports. Instead of explicitly having to trigger
them with periodic queries.

# Roaming

Until not that long ago, the Linux kernel (< v4.10) would only send
unsolicited IGMP/MLD reports when the network interface went UP
and detected a carrier for the link. However, it did not resend
reports when the carrier changes.

This lead to temporary multicast packet loss if a wireless
device was roaming from one access point to another and if there
was a snooping switch between those two. A more detailed description
and the simple, technical solution can be found here: [4]

Unfortunately though, it seems that MLDv2 is rather silent
regarding when unsolicited reports SHOULD or MUST be sent. I could
find that unsolicited reports are sent to "[announce] changes
in receiver listening" (Appendix B). But it does not seem to mention
that they have to be sent on link state changes, too.

Some quick tests with a few other operating systems back then seemed
to further indicate that this could need clarification. With some
Macbook unsolicited reports were sent upon wifi roaming just
fine. Some Windows laptops seemed to not do this, similar to what
Linux did (not) back then.

I think there needs to be a MUST somewhere for sending unsolicited
reports on link changes. (or maybe I'm just missing it?)


PS: Although reading here from time to time, I'm not that experienced
with the IETF process in general. Hope this was not the wrong
thread to jump in with those comments :-).


On Tue, Nov 20, 2018 at 12:58:29PM -0800, Stig Venaas wrote:
> Hi
> Currently IGMPv3 and MLDv2 are Proposed Standard, and we have good
> support in the working group for progressing them to Internet
> Standard. This is similar to the work that was done for PIM-SM (RFC
> 4601) a few years back. In order to do this, we should try to
> determine if there are parts of RFC 3376 and RFC 3810 that have not
> been widely implemented, and also if people have found any
> interoperability issues. For PIM-SM we had a team of volunteers that
> created separate surveys for vendors and operators. These surveys were
> then distributed as widely as possible, and we had someone receive the
> reports by email and anonymizing them. The volunteer team then wrote
> RFC 7063 based on their findings. The team also then worked on
> revising RFC 4601, using these findings as input, and published PIM-SM
> as Internet Standard (RFC 7761). Please see RFC 7063 for more details
> on the methodology, and also the exact surveys that were created.
> In order to progress IGMP/MLD I think we should follow the same
> procedure, but there could be other options. If you believe we should
> do it differently, please respond to this thread.
> We need a team of volunteers that can lead this work. It would be best
> if we have a wide representation from vendors plus people from
> operators or others that have deployment experience. If we agree on
> following the same procedure, the first step would be to create the
> surveys. It would be best that a draft gets published with the
> proposed surveys, and we can then discuss the proposal in the working
> group, and have the draft revised accordingly. Once the working group
> is happy with the proposed surveys we can then conduct the survey. I'm
> also hoping that the same volunteer team can afterwards work on
> revising the RFCs.
> If you are interested in volunteering, please let us know. Also, any
> comments on the process would be welcome.
> Regards,
> Stig
> _______________________________________________
> pim mailing list