--- 1/draft-ietf-mboned-ieee802-mcast-problems-07.txt 2019-08-13 16:13:32.302449483 -0700 +++ 2/draft-ietf-mboned-ieee802-mcast-problems-08.txt 2019-08-13 16:13:32.358450913 -0700 @@ -1,24 +1,25 @@ Internet Area C. Perkins -Internet-Draft M. McBride -Intended status: Informational Futurewei -Expires: January 27, 2020 D. Stanley +Internet-Draft +Intended status: Informational M. McBride +Expires: February 14, 2020 Futurewei + D. Stanley HPE W. Kumari Google JC. Zuniga SIGFOX - July 26, 2019 + August 13, 2019 Multicast Considerations over IEEE 802 Wireless Media - draft-ietf-mboned-ieee802-mcast-problems-07 + draft-ietf-mboned-ieee802-mcast-problems-08 Abstract Well-known issues with multicast have prevented the deployment of multicast in 802.11 and other local-area wireless environments. This document offers guidance on known limitations and problems with wireless 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 performace of the network. Finally, some @@ -33,21 +34,21 @@ 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 January 27, 2020. + This Internet-Draft will expire on February 14, 2020. Copyright Notice Copyright (c) 2019 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 @@ -69,40 +70,41 @@ 3.1.4. Power-save Effects on Multicast . . . . . . . . . . . 7 3.2. Issues at Layer 3 and Above . . . . . . . . . . . . . . . 7 3.2.1. IPv4 issues . . . . . . . . . . . . . . . . . . . . . 8 3.2.2. IPv6 issues . . . . . . . . . . . . . . . . . . . . . 8 3.2.3. MLD issues . . . . . . . . . . . . . . . . . . . . . 9 3.2.4. Spurious Neighbor Discovery . . . . . . . . . . . . . 9 4. Multicast protocol optimizations . . . . . . . . . . . . . . 10 4.1. Proxy ARP in 802.11-2012 . . . . . . . . . . . . . . . . 10 4.2. IPv6 Address Registration and Proxy Neighbor Discovery . 10 4.3. Buffering to Improve Battery Life . . . . . . . . . . . . 12 - 4.4. IPv6 support in 802.11-2012 . . . . . . . . . . . . . . . 12 - 4.5. Using Unicast Instead of Multicast . . . . . . . . . . . 13 - 4.5.1. Overview . . . . . . . . . . . . . . . . . . . . . . 13 - 4.5.2. Layer 2 Conversion to Unicast . . . . . . . . . . . . 13 - 4.5.3. Directed Multicast Service (DMS) . . . . . . . . . . 14 - 4.5.4. Automatic Multicast Tunneling (AMT) . . . . . . . . . 14 - 4.6. GroupCast with Retries (GCR) . . . . . . . . . . . . . . 14 + 4.4. Limiting multicast buffer hardware queue depth . . . . . 12 + 4.5. IPv6 support in 802.11-2012 . . . . . . . . . . . . . . . 12 + 4.6. Using Unicast Instead of Multicast . . . . . . . . . . . 13 + 4.6.1. Overview . . . . . . . . . . . . . . . . . . . . . . 13 + 4.6.2. Layer 2 Conversion to Unicast . . . . . . . . . . . . 13 + 4.6.3. Directed Multicast Service (DMS) . . . . . . . . . . 14 + 4.6.4. Automatic Multicast Tunneling (AMT) . . . . . . . . . 14 + 4.7. GroupCast with Retries (GCR) . . . . . . . . . . . . . . 15 5. Operational optimizations . . . . . . . . . . . . . . . . . . 15 - 5.1. Mitigating Problems from Spurious Neighbor Discovery . . 15 + 5.1. Mitigating Problems from Spurious Neighbor Discovery . . 16 5.2. Mitigating Spurious Service Discovery Messages . . . . . 17 - 6. Multicast Considerations for Other Wireless Media . . . . . . 17 + 6. Multicast Considerations for Other Wireless Media . . . . . . 18 7. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 18 - 8. Discussion Items . . . . . . . . . . . . . . . . . . . . . . 18 + 8. Discussion Items . . . . . . . . . . . . . . . . . . . . . . 19 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 - 12. Informative References . . . . . . . . . . . . . . . . . . . 19 + 12. Informative References . . . . . . . . . . . . . . . . . . . 20 Appendix A. Changes in this draft between revisions 06 versus 07 23 Appendix B. Changes in this draft between revisions 05 versus 06 23 - Appendix C. Changes in this draft between revisions 04 versus 05 23 + Appendix C. Changes in this draft between revisions 04 versus 05 24 Appendix D. Changes in this draft between revisions 03 versus 04 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 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 @@ -538,21 +540,30 @@ after the next DTIM beacon. In practice, most AP's will send a multicast every 30 packets. For unicast the AP could send a TIM (Traffic Indication Message), but for multicast the AP sends a broadcast to everyone. DTIM does power management but STAs can choose whether or not to wake up or not and whether or not to drop the packet. Unfortunately, without proper administrative control, such STAs may be unable to determine why their multicast operations do not work. -4.4. IPv6 support in 802.11-2012 +4.4. Limiting multicast buffer hardware queue depth + + The CAB (Content after Beacon) queue is used for beacon-triggered + transmission of buffered multicast frames. If lots of multicast + frames were buffered, and this queue fills up, it drowns out all + regular traffic. To limit the damage that buffered traffic can do, + some drivers limit the amount of queued multicast data to a fraction + of the beacon_interval. An example of this is [CAB]. + +4.5. IPv6 support in 802.11-2012 IPv6 uses Neighbor Discovery Protocol (NDP) instead of ARP. Every IPv6 node subscribes to a special multicast address for this purpose. Here is the specification language from clause 10.23.13 of [dot11-proxyarp]: "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] @@ -563,99 +574,99 @@ NDP may be used to request additional information o Maximum Transmission Unit o Router Solicitation o 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.5. Using Unicast Instead of Multicast +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. -4.5.1. Overview +4.6.1. Overview In many situations, it's a good choice to use unicast instead of multicast over the Wi-Fi link. This avoids most of the problems specific to multicast over Wi-Fi, since the individual frames are then acknowledged and buffered for power save clients, in the way that unicast traffic normally operates. This approach comes with the tradeoff of sometimes sending the same packet multiple times over the Wi-Fi link. However, in many cases, such as video into a residential home network, this can be a good tradeoff, since the Wi-Fi link may have enough capacity for the unicast traffic to be transmitted to each subscribed STA, even though multicast addressing may have been necessary for the upstream access network. Several technologies exist that can be used to arrange unicast transport over the Wi-Fi link, outlined in the subsections below. -4.5.2. Layer 2 Conversion to Unicast +4.6.2. Layer 2 Conversion to Unicast It is often possible to transmit multicast control and data messages by using unicast transmissions to each station individually. Although there is not yet a standardized method of conversion, at least one widely available implementation exists in the Linux bridging code [bridge-mc-2-uc]. Other proprietary implementations are available from various vendors. In general, these implementations perform a straightforward mapping for groups or channels, discovered by IGMP or MLD snooping, to the corresponding unicast MAC addresses. -4.5.3. Directed Multicast Service (DMS) +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 for power save STAs o 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 is not currently implemented in products. See [Tramarin2017] and [Oliva2013] for more information. -4.5.4. Automatic Multicast Tunneling (AMT) +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] 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 an AMT relay further upstream. -4.6. GroupCast with Retries (GCR) +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 does not guarantee success. For the block acknowledgement mechanism, the AP transmits each group addressed frame as conventional group addressed transmission. Retransmissions are group addressed, but hidden from non-11aa STAs. A directed block acknowledgement scheme is used to harvest reception @@ -873,36 +884,40 @@ 10. IANA Considerations 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, Pascal Thubert, Jeffrey - (Zhaohui) Zhang + Jaeggli, Jan Komissar, David Lamparter, Morten Pedersen, Pascal + Thubert, Jeffrey (Zhaohui) Zhang 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, . + [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, 2010, . [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 @@ -1098,35 +1113,31 @@ o Used terminology "Wi-Fi" throughout. o Many editorial improvements and grammatical corrections. o Modified text to be more generic instead of referring specifically to IETF conference situations. o Cited [RFC5757] for introduction to other wireless media. o Updated bibliographic citations. Authors' Addresses Charles E. Perkins - Futurewei Inc. - 2330 Central Expressway - Santa Clara, CA 95050 - USA Phone: +1-408-330-4586 Email: charliep@computer.org - Mike McBride Futurewei Inc. 2330 Central Expressway Santa Clara, CA 95055 USA Email: michael.mcbride@futurewei.com + Dorothy Stanley Hewlett Packard Enterprise 2000 North Naperville Rd. Naperville, IL 60566 USA Phone: +1 630 979 1572 Email: dstanley@arubanetworks.com Warren Kumari