--- 1/draft-ietf-mboned-ieee802-mcast-problems-14.txt 2021-07-28 17:13:10.041190274 -0700 +++ 2/draft-ietf-mboned-ieee802-mcast-problems-15.txt 2021-07-28 17:13:10.097191691 -0700 @@ -1,25 +1,25 @@ -Internet Area C. Perkins +Internet Area C.E. Perkins Internet-Draft Blue Meadow Networks Intended status: Informational M. McBride -Expires: December 31, 2021 Futurewei +Expires: 29 January 2022 Futurewei D. Stanley HPE W. Kumari Google JC. Zuniga SIGFOX - June 29, 2021 + 28 July 2021 Multicast Considerations over IEEE 802 Wireless Media - draft-ietf-mboned-ieee802-mcast-problems-14 + draft-ietf-mboned-ieee802-mcast-problems-15 Abstract Well-known issues with multicast have prevented the deployment of multicast in 802.11 (wifi) and other local-area wireless environments. This document describes the known limitations of wireless (primarily 802.11) Layer-2 multicast. Also described are certain multicast enhancement features that have been specified by the IETF, and by IEEE 802, for wireless media, as well as some operational choices that can be taken to improve the performance of @@ -34,36 +34,35 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on December 31, 2021. + This Internet-Draft will expire on 29 January 2022. Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents - (https://trustee.ietf.org/license-info) in effect on the date of - publication of this document. Please review these documents - carefully, as they describe your rights and restrictions with respect - to this document. Code Components extracted from this document must - include Simplified BSD License text as described in Section 4.e of - the Trust Legal Provisions and are provided without warranty as - described in the Simplified BSD License. + Provisions Relating to IETF Documents (https://trustee.ietf.org/ + license-info) in effect on the date of publication of this document. + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. Code Components + extracted from this document must include Simplified BSD License text + as described in Section 4.e of the Trust Legal Provisions and are + provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Identified multicast issues . . . . . . . . . . . . . . . . . 5 3.1. Issues at Layer 2 and Below . . . . . . . . . . . . . . . 5 3.1.1. Multicast reliability . . . . . . . . . . . . . . . . 5 3.1.2. Lower and Variable Data Rate . . . . . . . . . . . . 6 3.1.3. Capacity and Impact on Interference . . . . . . . . . 7 @@ -87,23 +86,21 @@ 4.7. GroupCast with Retries (GCR) . . . . . . . . . . . . . . 15 5. Operational optimizations . . . . . . . . . . . . . . . . . . 16 5.1. Mitigating Problems from Spurious Neighbor Discovery . . 16 5.2. Mitigating Spurious Service Discovery Messages . . . . . 18 6. Multicast Considerations for Other Wireless Media . . . . . . 18 7. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 19 8. On-going Discussion Items . . . . . . . . . . . . . . . . . . 19 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 - 12.1. Informative References . . . . . . . . . . . . . . . . . 21 - 12.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 25 + 12. Informative References . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 1. Introduction Well-known issues with multicast have prevented the deployment of multicast in 802.11 [dot11] and other local-area wireless environments, as described in [mc-props], [mc-prob-stmt]. Performance issues have been observed when multicast packet transmissions of IETF protocols are used over IEEE 802 wireless media. Even though enhancements for multicast transmissions have @@ -301,80 +298,80 @@ that every station has to be configured to wake up to receive the multicast frame, even though the received packet may ultimately be discarded. This process can have a large effect on the power consumption by the multicast receiver station. For this reason there are workarounds, such as Directed Multicast Service (DMS) described in Section 4, to prevent unnecessarily waking up stations. Multicast (and unicast) can work poorly with the power-save mechanisms defined in IEEE 802.11e, for the following reasons. - o Clients may be unable to stay in sleep mode due to multicast + * Clients may be unable to stay in sleep mode due to multicast control packets frequently waking them up. - o A unicast packet is delayed until an STA wakes up and requests it. + * A unicast packet is delayed until an STA wakes up and requests it. Unicast traffic may also be delayed to improve power save, efficiency and increase probability of aggregation. - o Multicast traffic is delayed in a wireless network if any of the + * Multicast traffic is delayed in a wireless network if any of the STAs in that network are power savers. All STAs associated to the AP have to be awake at a known time to receive multicast traffic. - o Packets can also be discarded due to buffer limitations in the AP + * Packets can also be discarded due to buffer limitations in the AP and non-AP STA. 3.2. Issues at Layer 3 and Above This section identifies some representative IETF protocols, and describes possible negative effects due to performance degradation when using multicast transmissions for control messages. Common uses of multicast include: - o Control plane signaling - o Neighbor Discovery - o Address Resolution - o Service Discovery - o Applications (video delivery, stock data, etc.) - o On-demand routing - o Backbone construction - o Other L3 protocols (non-IP) + * Control plane signaling + * Neighbor Discovery + * Address Resolution + * Service Discovery + * Applications (video delivery, stock data, etc.) + * On-demand routing + * Backbone construction + * Other L3 protocols (non-IP) User Datagram Protocol (UDP) is the most common transport layer protocol for multicast applications. By itself, UDP is not reliable -- messages may be lost or delivered out of order. 3.2.1. IPv4 issues The following list contains some representative discovery protocols, which utilize broadcast/multicast, that are used with IPv4. - o ARP [RFC5424] - o DHCP [RFC2131] - o mDNS [RFC6762] - o uPnP [RFC6970] + * ARP [RFC0826] + * DHCP [RFC2131] + * mDNS [RFC6762] + * uPnP [RFC6970] After initial configuration, ARP (described in more detail later), DHCP and uPnP occur much less commonly, but service discovery can occur at any time. Some widely-deployed service discovery protocols (e.g., for finding a printer) utilize mDNS (i.e., multicast) which is often dropped by operators. Even if multicast snooping [RFC4541] (which provides the benefit of conserving bandwidth on those segments of the network where no node has expressed interest in receiving packets addressed to the group address) is utilized, many devices can register at once and cause serious network degradation. 3.2.2. IPv6 issues IPv6 makes extensive use of multicast, including the following: - o DHCPv6 [RFC8415] - o Protocol Independent Multicast (PIM) [RFC7761] - o IPv6 Neighbor Discovery Protocol (NDP) [RFC4861] - o multicast DNS (mDNS) [RFC6762] - o Router Discovery [RFC4286] + * DHCPv6 [RFC8415] + * Protocol Independent Multicast (PIM) [RFC7761] + * IPv6 Neighbor Discovery Protocol (NDP) [RFC4861] + * multicast DNS (mDNS) [RFC6762] + * Router Discovery [RFC4286] IPv6 NDP Neighbor Solicitation (NS) messages used in Duplicate Address Detection (DAD) and Address Lookup make use of Link-Scope multicast. In contrast to IPv4, an IPv6 node will typically use multiple addresses, and may change them often for privacy reasons. This intensifies the impact of multicast messages that are associated to the mobility of a node. Router advertisement (RA) messages are also periodically multicasted over the Link. Neighbors may be considered lost if several consecutive Neighbor @@ -454,26 +451,26 @@ IEEE 802 and IETF that are aimed at reducing or eliminating the issues discussed in Section 3. 4.1. Proxy ARP in 802.11-2012 The AP knows the MAC address and IP address for all associated STAs. In this way, the AP acts as the central "manager" for all the 802.11 STAs in its basic service set (BSS). Proxy ARP is easy to implement at the AP, and offers the following advantages: - o Reduced broadcast traffic (transmitted at low MCS) on the wireless + * Reduced broadcast traffic (transmitted at low MCS) on the wireless medium - o STA benefits from extended power save in sleep mode, as ARP + * STA benefits from extended power save in sleep mode, as ARP requests for STA's IP address are handled instead by the AP. - o ARP frames are kept off the wireless medium. - o No changes are needed to STA implementation. + * ARP frames are kept off the wireless medium. + * No changes are needed to STA implementation. Here is the specification language as described in clause 10.23.13 of [dot11-proxyarp]: When the AP supports Proxy ARP "[...] the AP shall maintain a Hardware Address to Internet Address mapping for each associated station, and shall update the mapping when the Internet Address of the associated station changes. When the IPv4 address being resolved in the ARP request packet is used by a non-AP STA currently associated to the BSS, the proxy ARP service shall @@ -585,23 +582,23 @@ "When an IPv6 address is being resolved, the Proxy Neighbor Discovery service shall respond with a Neighbor Advertisement message [...] on behalf of an associated STA to an [ICMPv6] Neighbor Solicitation message [...]. When MAC address mappings change, the AP may send unsolicited Neighbor Advertisement Messages on behalf of a STA." NDP may be used to request additional information - o Maximum Transmission Unit - o Router Solicitation - o Router Advertisement, etc. + * Maximum Transmission Unit + * Router Solicitation + * Router Advertisement, etc. NDP messages are sent as group addressed (broadcast) frames in 802.11. Using the proxy operation helps to keep NDP messages off the wireless medium. 4.6. Using Unicast Instead of Multicast It is often possible to transmit multicast control and data messages by using unicast transmissions to each station individually. @@ -639,47 +636,47 @@ 4.6.3. Directed Multicast Service (DMS) There are situations where more is needed than simply converting multicast to unicast. For these purposes, DMS enables an STA to request that the AP transmit multicast group addressed frames destined to the requesting STAs as individually addressed frames [i.e., convert multicast to unicast]. Here are some characteristics of DMS: - o Requires 802.11n A-MSDUs - o Individually addressed frames are acknowledged and are buffered + * Requires 802.11n A-MSDUs + * Individually addressed frames are acknowledged and are buffered for power save STAs - o The requesting STA may specify traffic characteristics for DMS + * The requesting STA may specify traffic characteristics for DMS traffic - o DMS was defined in IEEE Std 802.11v-2011 - o DMS requires changes to both AP and STA implementation. + * DMS was defined in IEEE Std 802.11v-2011 + * DMS requires changes to both AP and STA implementation. DMS is not currently implemented in products. See [Tramarin2017] and [Oliva2013] for more information. 4.6.4. Automatic Multicast Tunneling (AMT) AMT[RFC7450] provides a method to tunnel multicast IP packets inside unicast IP packets over network links that only support unicast. When an operating system or application running on an STA has an AMT gateway capability integrated, it's possible to use unicast to traverse the Wi-Fi link by deploying an AMT relay in the non-Wi-Fi portion of the network connected to the AP. It is recommended that multicast-enabled networks deploying AMT relays for this purpose make the relays locally discoverable with the following methods, as described in [I-D.ietf-mboned-driad-amt-discovery]: - o DNS-SD [RFC6763] - o the well-known IP addresses from Section 7 of [RFC7450] + * DNS-SD [RFC6763] + * the well-known IP addresses from Section 7 of [RFC7450] An AMT gateway that implements multiple standard discovery methods is more likely to discover the local multicast-capable network, instead of forming a connection to a non-local AMT relay further upstream. 4.7. GroupCast with Retries (GCR) GCR (defined in [dot11aa]) provides greater reliability by using either unsolicited retries or a block acknowledgement mechanism. GCR increases probability of broadcast frame reception success, but still @@ -693,35 +690,35 @@ responses. GCR is suitable for all group sizes including medium to large groups. As the number of devices in the group increases, GCR can send block acknowledgement requests to only a small subset of the group. GCR does require changes to both AP and STA implementations. GCR may introduce unacceptable latency. After sending a group of data frames to the group, the AP has to do the following: - o unicast a Block Ack Request (BAR) to a subset of members. - o wait for the corresponding Block Ack (BA). - o retransmit any missed frames. - o resume other operations that may have been delayed. + * unicast a Block Ack Request (BAR) to a subset of members. + * wait for the corresponding Block Ack (BA). + * retransmit any missed frames. + * resume other operations that may have been delayed. This latency may not be acceptable for some traffic. There are ongoing extensions in 802.11 to improve GCR performance. - o BAR is sent using downlink MU-MIMO (note that downlink MU-MIMO is + * BAR is sent using downlink MU-MIMO (note that downlink MU-MIMO is already specified in 802.11-REVmc 4.3). - o BA is sent using uplink MU-MIMO (which is a .11ax feature). - o Additional 802.11ax extensions are under consideration; see + * BA is sent using uplink MU-MIMO (which is a .11ax feature). + * Additional 802.11ax extensions are under consideration; see [mc-ack-mux] - o Latency may also be reduced by simultaneously receiving BA + * Latency may also be reduced by simultaneously receiving BA information from multiple STAs. 5. Operational optimizations This section lists some operational optimizations that can be implemented when deploying wireless IEEE 802 networks to mitigate some of the issues discussed in Section 3. 5.1. Mitigating Problems from Spurious Neighbor Discovery @@ -835,24 +821,24 @@ result that many such functions are relegated to operation within higher layer protocols. This leads to a patchwork of non- interoperable and vendor-specific solutions. See [uli] for some additional discussion, and a proposal for a task group to resolve similar issues, in which the multicast problems might be considered for mitigation. Similar considerations hold for most other wireless media. A brief introduction is provided in [RFC5757] for the following: - o 802.16 WIMAX - o 3GPP/3GPP2 - o DVB-H / DVB-IPDC - o TV Broadcast and Satellite Networks + * 802.16 WIMAX + * 3GPP/3GPP2 + * DVB-H / DVB-IPDC + * TV Broadcast and Satellite Networks 7. Recommendations This section provides some recommendations about the usage and combinations of some of the multicast enhancements described in Section 4 and Section 5. Future protocol documents utilizing multicast signaling should be carefully scrutinized if the protocol is likely to be used over wireless media. @@ -863,40 +849,41 @@ of any needed multicast operations. Multicast signaling for wireless devices should be done in a way compatible with low duty-cycle operation. 8. On-going Discussion Items This section suggests two discussion items for further resolution. First, standards (and private) organizations should develop - guidelines to help clarify when multicast packets should be sent - wired rather than wireless. For example, 802.1ak [1] works on both - ethernet and Wi-Fi and organizations could help decision making by - developing guidelines for multicast over Wi-Fi including options for - when traffic should be sent wired. + guidelines to help clarify when multicast packets would be better + served by being sent wired rather than wireless. For example, + 802.1ak (https://www.ieee802.org/1/pages/802.1ak.html) works on both + ethernet and Wi-Fi and organizations could help with deployment + decision making by developing guidelines for multicast over Wi-Fi + including options for when traffic should be sent wired. Second, reliable registration to Layer-2 multicast groups, and a reliable multicast operation at Layer-2, might provide a good multicast over wifi solution. There shouldn't be a need to support 2^24 groups to get solicited node multicast working: it is possible to simply select a number of bits that make sense for a given network size to limit the number of unwanted deliveries to reasonable levels. IEEE 802.1, 802.11, and 802.15 should be encouraged to revisit L2 multicast issues and provide workable solutions. 9. Security Considerations This document does not introduce or modify any security mechanisms. Multicast deployed on wired or wireless networks as discussed in this - document can be made more secure in a variety of ways. [RFC7761], + document can be made more secure in a variety of ways. [RFC4601], for instance, specifies the use of IPsec to ensure authentication of the link-local messages in the Protocol Independent Multicast - Sparse Mode (PIM-SM) routing protocol. [RFC5796]specifies mechanisms to authenticate the PIM-SM link-local messages using the IP security (IPsec) Encapsulating Security Payload (ESP) or (optionally) the Authentication Header (AH). When using mechanisms that convert multicast traffic to unicast traffic for traversing radio links, the AP (or other entity) is forced to explicitly track which subscribers care about certain @@ -931,32 +918,30 @@ This document does not request any IANA actions. 11. Acknowledgements This document has benefitted from discussions with the following people, in alphabetical order: Mikael Abrahamsson, Bill Atwood, Stuart Cheshire, Donald Eastlake, Toerless Eckert, Jake Holland, Joel Jaeggli, Jan Komissar, David Lamparter, Morten Pedersen, Pascal Thubert, Jeffrey (Zhaohui) Zhang -12. References - -12.1. Informative References +12. Informative References [arpsponge] Wessel, M. and N. Sijm, "Effects of IPv4 and IPv6 address resolution on AMS-IX and the ARP Sponge", July 2009, . [bridge-mc-2-uc] - Fietkau, F., "bridge: multicast to unicast", Jan 2017, + Fietkau, F., "bridge: multicast to unicast", January 2017, . [CAB] Fietkau, F., "Limit multicast buffer hardware queue depth", 2013, . [Deri-2010] Deri, L. and J. Gasparakis, "10 Gbit Hardware Packet Filtering Using Commodity Network Adapters", RIPE 61, @@ -966,99 +951,117 @@ [dot11] "IEEE 802 Wireless", "802.11-2016 - IEEE Standard for Information technology--Telecommunications and information exchange between systems Local and metropolitan area networks--Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specification (includes 802.11v amendment)", March 2016, . [dot11-proxyarp] - Hiertz, G., Mestanov, F., and B. Hart, "Proxy ARP in + Hiertz, G. R., Mestanov, F., and B. Hart, "Proxy ARP in 802.11ax", September 2015, . [dot11aa] "IEEE 802 Wireless", "Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications Amendment 2: MAC Enhancements for Robust Audio Video Streaming", March 2012, . [group_key] Spiff, "Why do some WiFi routers block multicast packets - going from wired to wireless?", Jan 2017, + going from wired to wireless?", January 2017, . [I-D.ietf-6lo-backbone-router] Thubert, P., Perkins, C. E., and E. Levy-Abegnoli, "IPv6 - Backbone Router", draft-ietf-6lo-backbone-router-20 (work - in progress), March 2020. + Backbone Router", Work in Progress, Internet-Draft, draft- + ietf-6lo-backbone-router-20, 23 March 2020, + . [I-D.ietf-6tisch-architecture] - Thubert, P., "An Architecture for IPv6 over the TSCH mode - of IEEE 802.15.4", draft-ietf-6tisch-architecture-30 (work - in progress), November 2020. + Thubert, P., "An Architecture for IPv6 over the Time- + Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)", + Work in Progress, Internet-Draft, draft-ietf-6tisch- + architecture-30, 26 November 2020, + . [I-D.ietf-mboned-driad-amt-discovery] Holland, J., "DNS Reverse IP Automatic Multicast Tunneling - (AMT) Discovery", draft-ietf-mboned-driad-amt-discovery-13 - (work in progress), December 2019. + (AMT) Discovery", Work in Progress, Internet-Draft, draft- + ietf-mboned-driad-amt-discovery-13, 20 December 2019, + . [ietf_802-11] - Stanley, D., "IEEE 802.11 multicast capabilities", Nov - 2015, . [mc-ack-mux] Tanaka, Y., Sakai, E., Morioka, Y., Mori, M., Hiertz, G., and S. Coffey, "Multiplexing of Acknowledgements for Multicast Transmission", July 2015, . [mc-prob-stmt] Abrahamsson, M. and A. Stephens, "Multicast on 802.11", March 2015, . - [mc-props] - Stephens, A., "IEEE 802.11 multicast properties", March + [mc-props] Stephens, A., "IEEE 802.11 multicast properties", March 2015, . [Oliva2013] de la Oliva, A., Serrano, P., Salvador, P., and A. Banchs, "Performance evaluation of the IEEE 802.11aa multicast mechanisms for video streaming", 2013 IEEE 14th International Symposium on "A World of Wireless, Mobile and Multimedia Networks" (WoWMoM) pp. 1-9, June 2013. + [RFC0826] Plummer, D., "An Ethernet Address Resolution Protocol: Or + Converting Network Protocol Addresses to 48.bit Ethernet + Address for Transmission on Ethernet Hardware", STD 37, + RFC 826, DOI 10.17487/RFC0826, November 1982, + . + [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, . [RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery", RFC 4286, DOI 10.17487/RFC4286, December 2005, . [RFC4541] Christensen, M., Kimball, K., and F. Solensky, "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006, . + [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, + "Protocol Independent Multicast - Sparse Mode (PIM-SM): + Protocol Specification (Revised)", RFC 4601, + DOI 10.17487/RFC4601, August 2006, + . + [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, . [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, . @@ -1123,57 +1126,53 @@ Wireless Personal Area Network (6LoWPAN) Neighbor Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, . [Tramarin2017] Tramarin, F., Vitturi, S., and M. Luvisotto, "IEEE 802.11n for Distributed Measurement Systems", 2017 IEEE International Instrumentation and Measurement Technology Conference (I2MTC) pp. 1-6, May 2017. - [uli] Kinney, P., "LLC Proposal for 802.15.4", Nov 2015, + [uli] Kinney, P., "LLC Proposal for 802.15.4", November 2015, . -12.2. URIs - - [1] https://www.ieee802.org/1/pages/802.1ak.html - Authors' Addresses Charles E. Perkins Blue Meadow Networks Phone: +1-408-330-4586 Email: charliep@computer.org Mike McBride Futurewei Technologies Inc. 2330 Central Expressway Santa Clara, CA 95055 - USA + United States of America Email: michael.mcbride@futurewei.com - Dorothy Stanley Hewlett Packard Enterprise 2000 North Naperville Rd. Naperville, IL 60566 - USA + United States of America Phone: +1 630 979 1572 Email: dstanley1389@gmail.com + Warren Kumari Google 1600 Amphitheatre Parkway Mountain View, CA 94043 - USA + United States of America Email: warren@kumari.net Juan Carlos Zuniga SIGFOX 425 rue Jean Rostand - Labege 31670 + 31670 Labege France Email: j.c.zuniga@ieee.org