Re: [Mcast-wifi] [pim] Volunteers needed for work on progressing IGMP/MLD on the standards track
Linus Lüssing <linus.luessing@c0d3.blue> Wed, 12 December 2018 07:13 UTC
Return-Path: <linus.luessing@c0d3.blue>
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 D25C7126CB6; Tue, 11 Dec 2018 23:13:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.999
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=c0d3.blue
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 4llhbZ5HUfJV; Tue, 11 Dec 2018 23:13:51 -0800 (PST)
Received: from mail.aperture-lab.de (mail.aperture-lab.de [138.201.29.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (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; d=c0d3.blue; 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 Lüssing <linus.luessing@c0d3.blue>
To: Stig Venaas <stig@venaas.com>
Cc: pim@ietf.org, mcast-wifi@ietf.org
Message-ID: <20181212071343.GC9328@otheros>
References: <CAHANBt+AJLxCpzWgF_x0UQAp_1BWMewPjkN_u51xzMPP8WA2oA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CAHANBt+AJLxCpzWgF_x0UQAp_1BWMewPjkN_u51xzMPP8WA2oA@mail.gmail.com>
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=c0d3.blue; 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; d=c0d3.blue; 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 smtp.auth=linus.luessing@c0d3.blue smtp.mailfrom=linus.luessing@c0d3.blue
Authentication-Results: ORIGINATING; auth=pass smtp.auth=linus.luessing@c0d3.blue smtp.mailfrom=linus.luessing@c0d3.blue
Archived-At: <https://mailarchive.ietf.org/arch/msg/mcast-wifi/qlUmAvZUD6I7IedYXL3VKx-vR6k>
Subject: Re: [Mcast-wifi] [pim] Volunteers needed for work on progressing IGMP/MLD on the standards track
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: Wed, 12 Dec 2018 07:13:54 -0000
Hi, 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 other. 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?) Regards, Linus 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 :-). [0]: https://www.open-mesh.org/projects/batman-adv/wiki [1]: https://freifunk.net/en/ [2]: https://www.open-mesh.org/projects/batman-adv/wiki/Multicast-optimizations [3]: https://www.open-mesh.org/projects/batman-adv/wiki/Multicast-optimizations-report-suppresion [4]: https://patchwork.ozlabs.org/patch/723428/ 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 > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim
- Re: [Mcast-wifi] [pim] Volunteers needed for work… Linus Lüssing
- Re: [Mcast-wifi] [pim] Volunteers needed for work… Linus Lüssing
- Re: [Mcast-wifi] [pim] Volunteers needed for work… Linus Lüssing
- Re: [Mcast-wifi] [pim] Volunteers needed for work… Stig Venaas