[Mcast-wifi] my take from the meeting

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Wed, 19 July 2017 17:12 UTC

Return-Path: <pthubert@cisco.com>
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 46E3312EC3F for <mcast-wifi@ietfa.amsl.com>; Wed, 19 Jul 2017 10:12:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level:
X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 FeO6nsg7msGC for <mcast-wifi@ietfa.amsl.com>; Wed, 19 Jul 2017 10:12:57 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C3311270AC for <mcast-wifi@ietf.org>; Wed, 19 Jul 2017 10:12:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11731; q=dns/txt; s=iport; t=1500484377; x=1501693977; h=from:to:subject:date:message-id:mime-version; bh=bEY7B/NTAQnpIdfCait+FSNdIQpFSYDSFEBwjuKjf/s=; b=kwKE0UcgjZXTIyHyiU5x8o/DtZ9clNVUmAYatITWsod/++5YKtSTq/6J 4vgDE6PFZPm+bfsBZ49Ct8dW7JDn2KB/D4HA6PB9ls0TIMTmLqfzZIefv zLjZ/savTl3gGkTWSZxwODJZGMdjBpGu+NqLx/Palc7pCBMFvjRwOij88 g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DKAQCakm9Z/5xdJa1bHAEBBAEBCgEBg?= =?us-ascii?q?m9rZIEbjgSiOYUsghGJKz8YAQIBAQEBAQEBax0LhUxeAYEAHwcBBBsTiTBkt0m?= =?us-ascii?q?LHAEBAQEGAQEBASSDKINNiUyGFwWHI4IzhwGBYI0CAo5chTKSOZVbAR84gQp1F?= =?us-ascii?q?Ydfh1iBMYENAQEB?=
X-IronPort-AV: E=Sophos;i="5.40,381,1496102400"; d="scan'208,217";a="458099135"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Jul 2017 17:12:56 +0000
Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v6JHCuup030319 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for <mcast-wifi@ietf.org>; Wed, 19 Jul 2017 17:12:56 GMT
Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 19 Jul 2017 12:12:55 -0500
Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1210.000; Wed, 19 Jul 2017 12:12:55 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: "mcast-wifi@ietf.org" <mcast-wifi@ietf.org>
Thread-Topic: my take from the meeting
Thread-Index: AdMArJqlUHXnSAniQL+e61nSsC7DQg==
Date: Wed, 19 Jul 2017 17:12:43 +0000
Deferred-Delivery: Wed, 19 Jul 2017 17:11:57 +0000
Message-ID: <2b5f3ef210b84feaae3adcbed8e053fb@XCH-RCD-001.cisco.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.61.230.140]
Content-Type: multipart/alternative; boundary="_000_2b5f3ef210b84feaae3adcbed8e053fbXCHRCD001ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/mcast-wifi/gSXjXCqT26RW71c8fY4FTyLdXMc>
Subject: [Mcast-wifi] my take from the meeting
X-BeenThere: mcast-wifi@ietf.org
X-Mailman-Version: 2.1.22
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, 19 Jul 2017 17:12:59 -0000

Dear all :

For a lot of the meeting time, we discussed a lot on our views of what the problem is, and I'm not reporting on that. At least we agreed that the discussion is NOT IPv4 vs. IPv6, and that we do not expect to see wireless broadcast become cheap and reliable, so we seemed to have consensus that the IETF should contribute to solving the problems that our protocols are experiencing.

I noted that we discussed 2 main directions that we should take in the future:


-         On the one hand, IETF should protect its future and work on reducing the amount of multicast that we are using in our protocols, for protocols that we already have and for the ones we are designing now. Reducing usage of multicast will improve the operation on all networks, in particular when the multicast groups are large (Lorenzo); at some point even Ethernet fabrics end up suffering from excess of broadcast and that has consequences such as to limit the size of subnets (Pascal). A more immediate attention could be given to protocols that are either very chatty or for which reliable delivery of multicast is critical to the protocol operation. Work is already taking place in DNS SD (Stuart) and IPv6 ND (Pascal).

-

-         On the other end, a reliable registration to Layer-2 multicast groups and a reliable mcast operation at Layer-2 would provide a generic solution to many problems (Lorenzo). Current IGMP / MLD snooping is broken (Pascal). There is no need to support 2^24 groups to get solicited node mcast working: it is possible just select a number <<24 of trailing bits that make sense for a given network size to limit the amount of false positive (unwanted deliveries) to reasonable levels (Pascal). IEEE 802.1 has worked on the L2 multicast years ago (Stig). The initial protocol was broken and fixes where provided; with the current status of the IEEE work (paperwork?) and the lack of implementation (is there any?), this work may not have the required maturity yet (Pascal, based on a visit to IEEE802.1). We are unsure of what the state is at IEEE for all these topics and would appreciate a status (Dorothy proposes a name but I failed to remember it). Nevertheless, we need to encourage IEEE 802.1 and 802.11 to reopen L2 multicast, we need to get vendors attention on the functionality and get it working and implemented on wires and wireless. In particular, we remarked that Wi-Fi provides a broadcast service, not a multicast one (Lorenzo). In fact all frames are broadcast at the PHY level unless we beamform (Pascal) but what comes with unicast is the property of being much faster (2 orders of magnitude) and much more reliable (L2 ARQ); multicast to few nodes should certainly be served as multiple unicast.

-


Is this a fair report?