draft-ietf-mboned-ieee802-mcast-problems-05.txt   draft-ietf-mboned-ieee802-mcast-problems-06.txt 
Internet Area C. Perkins Internet Area C. Perkins
Internet-Draft M. McBride Internet-Draft M. McBride
Intended status: Informational Futurewei Intended status: Informational Futurewei
Expires: October 17, 2019 D. Stanley Expires: January 9, 2020 D. Stanley
HPE HPE
W. Kumari W. Kumari
Google Google
JC. Zuniga JC. Zuniga
SIGFOX SIGFOX
April 15, 2019 July 8, 2019
Multicast Considerations over IEEE 802 Wireless Media Multicast Considerations over IEEE 802 Wireless Media
draft-ietf-mboned-ieee802-mcast-problems-05 draft-ietf-mboned-ieee802-mcast-problems-06
Abstract Abstract
Well-known issues with multicast have prevented the deployment of Well-known issues with multicast have prevented the deployment of
multicast in 802.11 and other local-area wireless environments. This multicast in 802.11 and other local-area wireless environments. This
document offers guidance on known limitations and problems with document offers guidance on known limitations and problems with
wireless multicast. Also described are certain multicast enhancement wireless multicast. Also described are certain multicast enhancement
features that have been specified by the IETF and by IEEE 802 for 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 wireless media, as well as some operational choices that can be taken
to improve the performace of the network. Finally, some to improve the performace of the network. Finally, some
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 17, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 28 skipping to change at page 2, line 28
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Identified multicast issues . . . . . . . . . . . . . . . . . 5 3. Identified multicast issues . . . . . . . . . . . . . . . . . 5
3.1. Issues at Layer 2 and Below . . . . . . . . . . . . . . . 5 3.1. Issues at Layer 2 and Below . . . . . . . . . . . . . . . 5
3.1.1. Multicast reliability . . . . . . . . . . . . . . . . 5 3.1.1. Multicast reliability . . . . . . . . . . . . . . . . 5
3.1.2. Lower and Variable Data Rate . . . . . . . . . . . . 6 3.1.2. Lower and Variable Data Rate . . . . . . . . . . . . 6
3.1.3. High Interference . . . . . . . . . . . . . . . . . . 6 3.1.3. High Interference . . . . . . . . . . . . . . . . . . 7
3.1.4. Power-save Effects on Multicast . . . . . . . . . . . 7 3.1.4. Power-save Effects on Multicast . . . . . . . . . . . 7
3.2. Issues at Layer 3 and Above . . . . . . . . . . . . . . . 7 3.2. Issues at Layer 3 and Above . . . . . . . . . . . . . . . 7
3.2.1. IPv4 issues . . . . . . . . . . . . . . . . . . . . . 8 3.2.1. IPv4 issues . . . . . . . . . . . . . . . . . . . . . 8
3.2.2. IPv6 issues . . . . . . . . . . . . . . . . . . . . . 8 3.2.2. IPv6 issues . . . . . . . . . . . . . . . . . . . . . 8
3.2.3. MLD issues . . . . . . . . . . . . . . . . . . . . . 8 3.2.3. MLD issues . . . . . . . . . . . . . . . . . . . . . 9
3.2.4. Spurious Neighbor Discovery . . . . . . . . . . . . . 9 3.2.4. Spurious Neighbor Discovery . . . . . . . . . . . . . 9
4. Multicast protocol optimizations . . . . . . . . . . . . . . 10 4. Multicast protocol optimizations . . . . . . . . . . . . . . 10
4.1. Proxy ARP in 802.11-2012 . . . . . . . . . . . . . . . . 10 4.1. Proxy ARP in 802.11-2012 . . . . . . . . . . . . . . . . 10
4.2. IPv6 Address Registration and Proxy Neighbor Discovery . 10 4.2. IPv6 Address Registration and Proxy Neighbor Discovery . 10
4.3. Buffering to Improve Battery Life . . . . . . . . . . . . 12 4.3. Buffering to Improve Battery Life . . . . . . . . . . . . 12
4.4. IPv6 support in 802.11-2012 . . . . . . . . . . . . . . . 12 4.4. IPv6 support in 802.11-2012 . . . . . . . . . . . . . . . 12
4.5. Using Unicast Instead of Multicast . . . . . . . . . . . 13 4.5. Using Unicast Instead of Multicast . . . . . . . . . . . 13
4.5.1. Overview . . . . . . . . . . . . . . . . . . . . . . 13 4.5.1. Overview . . . . . . . . . . . . . . . . . . . . . . 13
4.5.2. Layer 2 Conversion to Unicast . . . . . . . . . . . . 13 4.5.2. Layer 2 Conversion to Unicast . . . . . . . . . . . . 13
4.5.3. Directed Multicast Service (DMS) . . . . . . . . . . 13 4.5.3. Directed Multicast Service (DMS) . . . . . . . . . . 14
4.5.4. Automatic Multicast Tunneling (AMT) . . . . . . . . . 14 4.5.4. Automatic Multicast Tunneling (AMT) . . . . . . . . . 14
4.6. GroupCast with Retries (GCR) . . . . . . . . . . . . . . 14 4.6. GroupCast with Retries (GCR) . . . . . . . . . . . . . . 14
5. Operational optimizations . . . . . . . . . . . . . . . . . . 15 5. Operational optimizations . . . . . . . . . . . . . . . . . . 15
5.1. Mitigating Problems from Spurious Neighbor Discovery . . 15 5.1. Mitigating Problems from Spurious Neighbor Discovery . . 15
5.2. Mitigating Spurious Service Discovery Messages . . . . . 17 5.2. Mitigating Spurious Service Discovery Messages . . . . . 17
6. Multicast Considerations for Other Wireless Media . . . . . . 17 6. Multicast Considerations for Other Wireless Media . . . . . . 17
7. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 18 7. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 18
8. Discussion Items . . . . . . . . . . . . . . . . . . . . . . 18 8. Discussion Items . . . . . . . . . . . . . . . . . . . . . . 18
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
12. Informative References . . . . . . . . . . . . . . . . . . . 19 12. Informative References . . . . . . . . . . . . . . . . . . . 19
Appendix A. Changes in this draft between revisions 04 versus 05 22 Appendix A. Changes in this draft between revisions 05 versus 06 23
Appendix B. Changes in this draft between revisions 03 versus 04 23 Appendix B. Changes in this draft between revisions 04 versus 05 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Appendix C. Changes in this draft between revisions 03 versus 04 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
Well-known issues with multicast have prevented the deployment of Well-known issues with multicast have prevented the deployment of
multicast in 802.11 [dot11], [mc-props], [mc-prob-stmt], and other multicast in 802.11 [dot11], [mc-props], [mc-prob-stmt], and other
local-area wireless environments. Performance issues have been local-area wireless environments. Performance issues have been
observed when multicast packet transmissions of IETF protocols are observed when multicast packet transmissions of IETF protocols are
used over IEEE 802 wireless media. Even though enhancements for used over IEEE 802 wireless media. Even though enhancements for
multicast transmissions have been designed at both IETF and IEEE 802, multicast transmissions have been designed at both IETF and IEEE 802,
incompatibilities still exist between specifications, implementations incompatibilities still exist between specifications, implementations
and configuration choices. and configuration choices.
Many IETF protocols depend on multicast/broadcast for delivery of Many IETF protocols depend on multicast/broadcast for delivery of
control messages to multiple receivers. Multicast is used for control messages to multiple receivers. Multicast is used for
various purposes such as neighbor discovery, network flooding, various purposes such as neighbor discovery, network flooding,
address resolution, as well minimizing media occupancy for the address resolution, as well minimizing media occupancy for the
transmission of data that is intended for multiple receivers. In transmission of data that is intended for multiple receivers. In
addition to protocol use of broadcast/multicast for control messages, addition to protocol use of broadcast/multicast for control messages,
more applications, such as push to talk in hospitals, or video in more applications, such as push to talk in hospitals, or video in
enterprises, universities, and homes, are sending multicast IP to end enterprises, universities, and homes, are sending multicast IP to end
user devices, which are increasingly using wifi for their user devices, which are increasingly using Wi-Fi for their
connectivity. connectivity.
IETF protocols typically rely on network protocol layering in order IETF protocols typically rely on network protocol layering in order
to reduce or eliminate any dependence of higher level protocols on to reduce or eliminate any dependence of higher level protocols on
the specific nature of the MAC layer protocols or the physical media. the specific nature of the MAC layer protocols or the physical media.
In the case of multicast transmissions, higher level protocols have In the case of multicast transmissions, higher level protocols have
traditionally been designed as if transmitting a packet to an IP traditionally been designed as if transmitting a packet to an IP
address had the same cost in interference and network media access, address had the same cost in interference and network media access,
regardless of whether the destination IP address is a unicast address regardless of whether the destination IP address is a unicast address
or a multicast or broadcast address. This model was reasonable for or a multicast or broadcast address. This model was reasonable for
skipping to change at page 5, line 31 skipping to change at page 5, line 33
TIM TIM
Traffic Indication Map (TIM): An information element that Traffic Indication Map (TIM): An information element that
advertises whether or not any associated stations have buffered advertises whether or not any associated stations have buffered
unicast frames unicast frames
3. Identified multicast issues 3. Identified multicast issues
3.1. Issues at Layer 2 and Below 3.1. Issues at Layer 2 and Below
In this section we describe some of the issues related to the use of In this section some of the issues related to the use of multicast
multicast transmissions over IEEE 802 wireless technologies. transmissions over IEEE 802 wireless technologies are described.
3.1.1. Multicast reliability 3.1.1. Multicast reliability
Multicast traffic is typically much less reliable than unicast Multicast traffic is typically much less reliable than unicast
traffic. Since multicast makes point-to-multipoint communications, traffic. Since multicast makes point-to-multipoint communications,
multiple acknowledgements would be needed to guarantee reception at multiple acknowledgements would be needed to guarantee reception at
all recipients. Since typically there are no ACKs for multicast all recipients. Since typically there are no ACKs for multicast
packets, it is not possible for the Access Point (AP) to know whether packets, it is not possible for the Access Point (AP) to know whether
or not a retransmission is needed. Even in the wired Internet, this or not a retransmission is needed. Even in the wired Internet, this
characteristic often causes undesirably high error rates. This has characteristic often causes undesirably high error rates. This has
skipping to change at page 6, line 9 skipping to change at page 6, line 12
packet error rate (PER) due to lack of retransmission, and because packet error rate (PER) due to lack of retransmission, and because
the sender never backs off. It is not uncommon for there to be a the sender never backs off. It is not uncommon for there to be a
packet loss rate of 5% or more, which is particularly troublesome for packet loss rate of 5% or more, which is particularly troublesome for
video and other environments where high data rates and high video and other environments where high data rates and high
reliability are required. reliability are required.
3.1.2. Lower and Variable Data Rate 3.1.2. Lower and Variable Data Rate
Multicast over wired differs from multicast over wireless because Multicast over wired differs from multicast over wireless because
transmission over wired links often occurs at a fixed rate. Wi-Fi, transmission over wired links often occurs at a fixed rate. Wi-Fi,
on the other hand, has a transmission rate which varies depending on the other hand, has a transmission rate that varies depending upon
upon the STA's proximity to the AP. The throughput of video flows, the STA's proximity to the AP. The throughput of video flows, and
and the capacity of the broader Wi-Fi network, will change and will the capacity of the broader Wi-Fi network, will change and will
impact the ability for QoS solutions to effectively reserve bandwidth impact the ability for QoS solutions to effectively reserve bandwidth
and provide admission control. and provide admission control.
For wireless stations associated with an Access Point, the power For wireless stations associated with an Access Point, the power
necessary for good reception can vary from station to station. For necessary for good reception can vary from station to station. For
unicast, the goal is to minimize power requirements while maximizing unicast, the goal is to minimize power requirements while maximizing
the data rate to the destination. For multicast, the goal is simply the data rate to the destination. For multicast, the goal is simply
to maximize the number of receivers that will correctly receive the to maximize the number of receivers that will correctly receive the
multicast packet; generally the Access Point has to use a much lower multicast packet; generally the Access Point has to use a much lower
data rate at a power level high enough for even the farthest station data rate at a power level high enough for even the farthest station
skipping to change at page 7, line 23 skipping to change at page 7, line 29
process can have a large effect on the power consumption by the process can have a large effect on the power consumption by the
multicast receiver station. multicast receiver station.
Multicast can work poorly with the power-save mechanisms defined in Multicast can work poorly with the power-save mechanisms defined in
IEEE 802.11e, for the following reasons. IEEE 802.11e, for the following reasons.
o Clients may be unable to stay in sleep mode due to multicast o Clients may be unable to stay in sleep mode due to multicast
control packets frequently waking them up. control packets frequently waking them up.
o Both unicast and multicast traffic can be delayed by power-saving o Both unicast and multicast traffic can be delayed by power-saving
mechanisms. mechanisms.
o A unicast packet is delayed until a STA wakes up and requests it. o A unicast packet is delayed until an STA wakes up and requests it.
Unicast traffic may also be delayed to improve power save, Unicast traffic may also be delayed to improve power save,
efficiency and increase probability of aggregation. efficiency and increase probability of aggregation.
o Multicast traffic is delayed in a wireless network if any of the o Multicast traffic is delayed in a wireless network if any of the
STAs in that network are power savers. All STAs associated to 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. 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 o Packets can also be discarded due to buffer limitations in the AP
and non-AP STA. and non-AP STA.
3.2. Issues at Layer 3 and Above 3.2. Issues at Layer 3 and Above
skipping to change at page 9, line 15 skipping to change at page 9, line 23
possibly many multicast solicited-node addresses. Multicast possibly many multicast solicited-node addresses. Multicast
addresses that do not have forwarding state installed (perhaps due to addresses that do not have forwarding state installed (perhaps due to
hardware memory limitations on the switch) cause frames to be flooded hardware memory limitations on the switch) cause frames to be flooded
on all ports of the switch. on all ports of the switch.
3.2.4. Spurious Neighbor Discovery 3.2.4. Spurious Neighbor Discovery
On the Internet there is a "background radiation" of scanning traffic On the Internet there is a "background radiation" of scanning traffic
(people scanning for vulnerable machines) and backscatter (responses (people scanning for vulnerable machines) and backscatter (responses
from spoofed traffic, etc). This means that routers very often from spoofed traffic, etc). This means that routers very often
receive packets destined for IP addresses regardless of whether they receive packets destined for IP addresses regardless of whether those
are in use. In the cases where the IP is assigned to a host, the IP addresses are in use. In the cases where the IP is assigned to a
router broadcasts an ARP request, gets back an ARP reply, and caches host, the router broadcasts an ARP request, gets back an ARP reply,
it; then traffic can be delivered to the host. When the IP address and caches it; then traffic can be delivered to the host. When the
is not in use, the router broadcasts one (or more) ARP requests, and IP address is not in use, the router broadcasts one (or more) ARP
never gets a reply. This means that it does not populate the ARP requests, and never gets a reply. This means that it does not
cache, and the next time there is traffic for that IP address the populate the ARP cache, and the next time there is traffic for that
router will rebroadcast the ARP requests. IP address the router will rebroadcast the ARP requests.
The rate of these ARP requests is proportional to the size of the The rate of these ARP requests is proportional to the size of the
subnets, the rate of scanning and backscatter, and how long the subnets, the rate of scanning and backscatter, and how long the
router keeps state on non-responding ARPs. As it turns out, this router keeps state on non-responding ARPs. As it turns out, this
rate is inversely proportional to how occupied the subnet is (valid rate is inversely proportional to how occupied the subnet is (valid
ARPs end up in a cache, stopping the broadcasting; unused IPs never ARPs end up in a cache, stopping the broadcasting; unused IPs never
respond, and so cause more broadcasts). Depending on the address respond, and so cause more broadcasts). Depending on the address
space in use, the time of day, how occupied the subnet is, and other space in use, the time of day, how occupied the subnet is, and other
unknown factors, on the order of 2000 broadcasts per second have been unknown factors, on the order of 2000 broadcasts per second have been
observed, for instance at the NOCs during IETF face-to-face meetings. observed, for instance at the NOCs during IETF face-to-face meetings.
On a wired network, there is not a huge difference between unicast, On a wired network, there is not a huge difference between unicast,
multicast and broadcast traffic. Due to hardware filtering (see, multicast and broadcast traffic. Due to hardware filtering (see,
e.g., [Deri-2010]), inadvertently flooded traffic (or high amounts of e.g., [Deri-2010]), inadvertently flooded traffic (or excessive
ethernet multicast) on wired networks can be quite a bit less costly, ethernet multicast) on wired networks can be quite a bit less costly,
compared to wireless cases where sleeping devices have to wake up to compared to wireless cases where sleeping devices have to wake up to
process packets. Wired Ethernets tend to be switched networks, process packets. Wired Ethernets tend to be switched networks,
further reducing interference from multicast. There is effectively further reducing interference from multicast. There is effectively
no collision / scheduling problem except at extremely high port no collision / scheduling problem except at extremely high port
utilizations. utilizations.
This is not true in the wireless realm; wireless equipment is often This is not true in the wireless realm; wireless equipment is often
unable to send high volumes of broadcast and multicast traffic. unable to send high volumes of broadcast and multicast traffic.
Consequently, on the wireless networks, we observe a significant Consequently, on the wireless networks, a significant number of
amount of dropped broadcast and multicast packets. This, in turn, dropped broadcast and multicast packets are observed. This, in turn,
means that when a host connects it is often not able to complete means that when a host connects it is often not able to complete
DHCP, and IPv6 RAs get dropped, leading to users being unable to use DHCP, and IPv6 RAs get dropped, leading to users being unable to use
the network. the network.
4. Multicast protocol optimizations 4. Multicast protocol optimizations
This section lists some optimizations that have been specified in This section lists some optimizations that have been specified in
IEEE 802 and IETF that are aimed at reducing or eliminating the IEEE 802 and IETF that are aimed at reducing or eliminating the
issues discussed in Section 3. issues discussed in Section 3.
skipping to change at page 13, line 45 skipping to change at page 14, line 8
least one widely available implementation exists in the Linux least one widely available implementation exists in the Linux
bridging code [bridge-mc-2-uc]. Other proprietary implementations bridging code [bridge-mc-2-uc]. Other proprietary implementations
are available from various vendors. In general, these are available from various vendors. In general, these
implementations perform a straightforward mapping for groups or implementations perform a straightforward mapping for groups or
channels, discovered by IGMP or MLD snooping, to the corresponding channels, discovered by IGMP or MLD snooping, to the corresponding
unicast MAC addresses. unicast MAC addresses.
4.5.3. Directed Multicast Service (DMS) 4.5.3. Directed Multicast Service (DMS)
There are situations where more is needed than simply converting There are situations where more is needed than simply converting
multicast to unicast. For these purposes, DMS enables a STA to multicast to unicast. For these purposes, DMS enables an STA to
request that the AP transmit multicast group addressed frames request that the AP transmit multicast group addressed frames
destined to the requesting STAs as individually addressed frames destined to the requesting STAs as individually addressed frames
[i.e., convert multicast to unicast]. Here are some characteristics [i.e., convert multicast to unicast]. Here are some characteristics
of DMS: of DMS:
o Requires 802.11n A-MSDUs o Requires 802.11n A-MSDUs
o Individually addressed frames are acknowledged and are buffered o Individually addressed frames are acknowledged and are buffered
for power save STAs for power save STAs
o The requesting STA may specify traffic characteristics for DMS o The requesting STA may specify traffic characteristics for DMS
traffic traffic
o DMS was defined in IEEE Std 802.11v-2011 o DMS was defined in IEEE Std 802.11v-2011
o DMS requires changes to both AP and STA implementation. o DMS requires changes to both AP and STA implementation.
DMS is not currently implemented in products. See [Tramarin2017] and DMS is not currently implemented in products. See [Tramarin2017] and
[Oliva2013] for more information. [Oliva2013] for more information.
4.5.4. Automatic Multicast Tunneling (AMT) 4.5.4. Automatic Multicast Tunneling (AMT)
AMT[RFC7450] provides a method to tunnel multicast IP packets inside AMT[RFC7450] provides a method to tunnel multicast IP packets inside
unicast IP packets over network links that only support unicast. unicast IP packets over network links that only support unicast.
When an operating system or application running on a STA has an AMT When an operating system or application running on an STA has an AMT
gateway capability integrated, it's possible to use unicast to 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 traverse the Wi-Fi link by deploying an AMT relay in the non-Wi-Fi
portion of the network connected to the AP. portion of the network connected to the AP.
It is RECOMMENDED that multicast-enabled networks deploying AMT It is RECOMMENDED that multicast-enabled networks deploying AMT
relays for this purpose make the relays discoverable with both of relays for this purpose make the relays discoverable with the
these methods: following methods:
o DNS-SD [RFC6763]
o the well-known IP addresses from Section 7 of [RFC7450], and o the well-known IP addresses from Section 7 of [RFC7450], and
o with DNS-SD [RFC6763] o DRIAD [I-D.ietf-mboned-driad-amt-discovery]
Providing the multiple standard discovery methods makes it more Providing the multiple standard discovery methods makes it more
likely that AMT gateway implementations will discover the local likely that AMT gateway implementations will discover the local
multicast-capable network, rather than forming a connection to an AMT multicast-capable network, rather than forming a connection to an AMT
relay further upstream. relay further upstream.
4.6. GroupCast with Retries (GCR) 4.6. GroupCast with Retries (GCR)
GCR (defined in [dot11aa]) provides greater reliability by using GCR (defined in [dot11aa]) provides greater reliability by using
either unsolicited retries or a block acknowledgement mechanism. GCR either unsolicited retries or a block acknowledgement mechanism. GCR
skipping to change at page 15, line 13 skipping to change at page 15, line 23
As the number of devices in the group increases, GCR can send block As the number of devices in the group increases, GCR can send block
acknowledgement requests to only a small subset of the group. GCR acknowledgement requests to only a small subset of the group. GCR
does require changes to both AP and STA implementation. does require changes to both AP and STA implementation.
GCR may introduce unacceptable latency. After sending a group of GCR may introduce unacceptable latency. After sending a group of
data frames to the group, the AP has do the following: data frames to the group, the AP has do the following:
o unicast a Block Ack Request (BAR) to a subset of members. o unicast a Block Ack Request (BAR) to a subset of members.
o wait for the corresponding Block Ack (BA). o wait for the corresponding Block Ack (BA).
o retransmit any missed frames. o retransmit any missed frames.
o resume other operations which may have been delayed. o resume other operations that may have been delayed.
This latency may not be acceptable for some traffic. This latency may not be acceptable for some traffic.
There are ongoing extensions in 802.11 to improve GCR performance. 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 o BAR is sent using downlink MU-MIMO (note that downlink MU-MIMO is
already specified in 802.11-REVmc 4.3). already specified in 802.11-REVmc 4.3).
o BA is sent using uplink MU-MIMO (which is a .11ax feature). o BA is sent using uplink MU-MIMO (which is a .11ax feature).
o Additional 802.11ax extensions are under consideration; see o Additional 802.11ax extensions are under consideration; see
[mc-ack-mux] [mc-ack-mux]
skipping to change at page 15, line 37 skipping to change at page 15, line 47
5. Operational optimizations 5. Operational optimizations
This section lists some operational optimizations that can be This section lists some operational optimizations that can be
implemented when deploying wireless IEEE 802 networks to mitigate the implemented when deploying wireless IEEE 802 networks to mitigate the
issues discussed in Section 3. issues discussed in Section 3.
5.1. Mitigating Problems from Spurious Neighbor Discovery 5.1. Mitigating Problems from Spurious Neighbor Discovery
ARP Sponges ARP Sponges
An ARP Sponge sits on a network and learn which IPs addresses An ARP Sponge sits on a network and learn which IP addresses
are actually in use. It also listen for ARP requests, and, if are actually in use. It also listen for ARP requests, and, if
it sees an ARP for an IP address which it believes is not used, it sees an ARP for an IP address that it believes is not used,
it will reply with its own MAC address. This means that the it will reply with its own MAC address. This means that the
router now has an IP to MAC mapping, which it caches. If that router now has an IP to MAC mapping, which it caches. If that
IP is later assigned to an machine (e.g using DHCP), the ARP IP is later assigned to an machine (e.g using DHCP), the ARP
sponge will see this, and will stop replying for that address. sponge will see this, and will stop replying for that address.
Gratuitous ARPs (or the machine ARPing for its gateway) will Gratuitous ARPs (or the machine ARPing for its gateway) will
replace the sponged address in the router ARP table. This replace the sponged address in the router ARP table. This
technique is quite effective; but, unfortunately, the ARP technique is quite effective; but, unfortunately, the ARP
sponge daemons were not really designed for this use (the sponge daemons were not really designed for this use (the
standard one [arpsponge], was designed to deal with the standard one [arpsponge], was designed to deal with the
disappearance of participants from an IXP) and so are not disappearance of participants from an IXP) and so are not
optimized for this purpose. We have to run one daemon per optimized for this purpose. One daemon is needed per subnet,
subnet, the tuning is tricky (the scanning rate versus the the tuning is tricky (the scanning rate versus the population
population rate versus retires, etc.) and sometimes the daemons rate versus retires, etc.) and sometimes the daemons just seem
just seem to stop, requiring a restart of the daemon and to stop, requiring a restart of the daemon and causing
causing disruption. disruption.
Router mitigations Router mitigations
Some routers (often those based on Linux) implement a "negative Some routers (often those based on Linux) implement a "negative
ARP cache" daemon. Simply put, if the router does not see a ARP cache" daemon. Simply put, if the router does not see a
reply to an ARP it can be configured to cache this information reply to an ARP it can be configured to cache this information
for some interval. Unfortunately, the core routers which we for some interval. Unfortunately, the core routers in use
are using do not support this. When a host connects to network often do not support this. When a host connects to network and
and gets an IP address, it will ARP for its default gateway gets an IP address, it will ARP for its default gateway (the
(the router). The router will update its cache with the IP to router). The router will update its cache with the IP to host
host MAC mapping learnt from the request (passive ARP MAC mapping learnt from the request (passive ARP learning).
learning).
Firewall unused space Firewall unused space
The distribution of users on wireless networks / subnets The distribution of users on wireless networks / subnets
changes from meeting to meeting (e.g SSIDs are renamed, some changes from IETF meeting to the next (e.g SSIDs are renamed,
SSIDs lose favor, etc). This makes utilization for particular some SSIDs lose favor, etc). This makes utilization for
SSIDs difficult to predict ahead of time, but usage can be particular SSIDs difficult to predict ahead of time, but usage
monitored as attendees use the different networks. Configuring can be monitored as attendees use the different networks.
multiple DHCP pools per subnet, and enabling them sequentially, Configuring multiple DHCP pools per subnet, and enabling them
can create a large subnet, from which only addresses in the sequentially, can create a large subnet, from which only
lower portions are assigned. Therefore input IP access lists addresses in the lower portions are assigned. Therefore input
can be applied, which deny traffic to the upper, unused IP access lists can be applied, which deny traffic to the
portions. Then the router does not attempt to forward packets upper, unused portions. Then the router does not attempt to
to the unused portions of the subnets, and so does not ARP for forward packets to the unused portions of the subnets, and so
it. This method has proven to be very effective, but is does not ARP for it. This method has proven to be very
somewhat of a blunt axe, is fairly labor intensive, and effective, but is somewhat of a blunt axe, is fairly labor
requires coordination. intensive, and requires coordination.
Disabling/filtering ARP requests Disabling/filtering ARP requests
In general, the router does not need to ARP for hosts; when a In general, the router does not need to ARP for hosts; when a
host connects, the router can learn the IP to MAC mapping from host connects, the router can learn the IP to MAC mapping from
the ARP request sent by that host. This means that we should the ARP request sent by that host. Consequently it should be
be able to disable and / or filter ARP requests from the possible to disable and / or filter ARP requests from the
router. Unfortunately, ARP is a very low level / fundamental router. Unfortunately, ARP is a very low level / fundamental
part of the IP stack, and is often offloaded from the normal part of the IP stack, and is often offloaded from the normal
control plane. While many routers can filter layer-2 traffic, control plane. While many routers can filter layer-2 traffic,
this is usually implemented as an input filter and / or has this is usually implemented as an input filter and / or has
limited ability to filter output broadcast traffic. This means limited ability to filter output broadcast traffic. This means
that the simple "just disable ARP or filter it outbound" seems that the simple "just disable ARP or filter it outbound" seems
like a really simple (and obvious) solution, but like a really simple (and obvious) solution, but
implementations / architectural issues make this difficult or implementations / architectural issues make this difficult or
awkward in practice. awkward in practice.
NAT NAT
The broadcasts are overwhelmingly being caused by outside The broadcasts are overwhelmingly being caused by outside
scanning / backscatter traffic. This means that, if we were to scanning / backscatter traffic. To NAT the entire (or a large
NAT the entire (or a large portion) of the attendee networks, portion) of the attendee networks would eliminate NAT
there would be no NAT translation entries for unused addresses, translation entries for unused addresses, and so the router
and so the router would never ARP for them. However, there are would never ARP for them. However, there are many reasons to
many reasons to avoid using NAT in such a blanket fashion. avoid using NAT in such a blanket fashion.
Stateful firewalls Stateful firewalls
Another obvious solution would be to put a stateful firewall Another obvious solution would be to put a stateful firewall
between the wireless network and the Internet. This firewall between the wireless network and the Internet. This firewall
would block incoming traffic not associated with an outbound would block incoming traffic not associated with an outbound
request. But this conflicts with the need and desire to have request. But this conflicts with the need and desire of the
the network as open as possible and to honor the end-to-end IETF and other organizations to have the network as open as
principle. An attendee on the meeting network should be an possible and to honor the end-to-end principle. An attendee on
Internet host, and should be able to receive unsolicited the meeting network should be an Internet host, and should be
requests. Unfortunately, keeping the network working and able to receive unsolicited requests. Unfortunately, keeping
stable is the first priority and a stateful firewall may be the network working and stable is the first priority and a
required in order to achieve this. stateful firewall may be required in order to achieve this.
5.2. Mitigating Spurious Service Discovery Messages 5.2. Mitigating Spurious Service Discovery Messages
In networks that must support hundreds of STAs, operators have In networks that must support hundreds of STAs, operators have
observed network degradation due to many devices simultaneously observed network degradation due to many devices simultaneously
registering with mDNS. In a network with many clients, it is registering with mDNS. In a network with many clients, it is
recommended to ensure that mDNS packets designed to discover recommended to ensure that mDNS packets designed to discover
services in smaller home networks be constrained to avoid services in smaller home networks be constrained to avoid
disrupting other traffic. disrupting other traffic.
skipping to change at page 18, line 48 skipping to change at page 19, line 10
802.1Q-2011. 802.1Q-2014 can be found here: 802.1Q-2011. 802.1Q-2014 can be found here:
http://www.ieee802.org/1/pages/802.1Q-2014.html. If a generic http://www.ieee802.org/1/pages/802.1Q-2014.html. If a generic
solution is not found, guidelines for multicast over Wi-Fi should be solution is not found, guidelines for multicast over Wi-Fi should be
established. established.
Reliable registration to Layer-2 multicast groups and a reliable Reliable registration to Layer-2 multicast groups and a reliable
multicast operation at Layer-2 might provide a generic solution. multicast operation at Layer-2 might provide a generic solution.
There is no need to support 2^24 groups to get solicited node There is no need to support 2^24 groups to get solicited node
multicast working: it is possible to simply select a number of multicast working: it is possible to simply select a number of
trailing bits that make sense for a given network size to limit the trailing bits that make sense for a given network size to limit the
amount of unwanted deliveries to reasonable levels. IEEE 802.1, number of unwanted deliveries to reasonable levels. IEEE 802.1,
802.11, and 802.15 should be encouraged to revisit L2 multicast 802.11, and 802.15 should be encouraged to revisit L2 multicast
issues. In reality, Wi-Fi provides a broadcast service, not a issues. In reality, Wi-Fi provides a broadcast service, not a
multicast service. On the physical medium, all frames are broadcast multicast service. On the physical medium, all frames are broadcast
except in very unusual cases in which special beamforming except in very unusual cases in which special beamforming
transmitters are used. Unicast offers the advantage of being much transmitters are used. Unicast offers the advantage of being much
faster (2 orders of magnitude) and much more reliable (L2 ARQ). faster (2 orders of magnitude) and much more reliable (L2 ARQ).
9. Security Considerations 9. Security Considerations
This document neither introduces nor modifies any security This document does not introduce or modify any security mechanisms.
mechanisms.
As noted in [group_key], the unreliable nature of multicast
transmission over wireless media can cause subtle problems with
multicast group key management and updates. Quoting from that
website, "... most clients are able to get connected and surf the
web, check email, etc. even when FromDS multicasts are broken. So a
lot of people don't realize they have multicast problems on their
network..."
10. IANA Considerations 10. IANA Considerations
This document does not request any IANA actions. This document does not request any IANA actions.
11. Acknowledgements 11. Acknowledgements
This document has benefitted from discussions with the following This document has benefitted from discussions with the following
people, in alphabetical order: Mikael Abrahamsson, Stuart Cheshire, people, in alphabetical order: Mikael Abrahamsson, Bill Atwood,
Donald Eastlake, Toerless Eckert, Jake Holland, Joel Jaeggli, Jan Stuart Cheshire, Donald Eastlake, Toerless Eckert, Jake Holland, Joel
Komissar, David Lamparter, Pascal Thubert Jaeggli, Jan Komissar, David Lamparter, Pascal Thubert, Jeffrey
(Zhaohui) Zhang
12. Informative References 12. Informative References
[arpsponge] [arpsponge]
Vijn, A. and S. Bakker, "Arp Sponge", March 2015, Vijn, A. and S. Bakker, "Arp Sponge", March 2015,
<https://ams-ix.net/downloads/arpsponge/3.12.2/arpsponge- <https://ams-ix.net/downloads/arpsponge/3.12.2/arpsponge-
3.12.2/arpsponge.txt>. 3.12.2/arpsponge.txt>.
[bridge-mc-2-uc] [bridge-mc-2-uc]
Torvalds, L., "bridge: multicast to unicast", Jan 2017, Torvalds, L., "bridge: multicast to unicast", Jan 2017,
skipping to change at page 20, line 18 skipping to change at page 20, line 33
September 2015, <https://mentor.ieee.org/802.11/ September 2015, <https://mentor.ieee.org/802.11/
dcn/15/11-15-1015-01-00ax-proxy-arp-in-802-11ax.pptx>. dcn/15/11-15-1015-01-00ax-proxy-arp-in-802-11ax.pptx>.
[dot11aa] "IEEE 802 Wireless", "Part 11: Wireless LAN Medium Access [dot11aa] "IEEE 802 Wireless", "Part 11: Wireless LAN Medium Access
Control (MAC) and Physical Layer (PHY) Specifications Control (MAC) and Physical Layer (PHY) Specifications
Amendment 2: MAC Enhancements for Robust Audio Video Amendment 2: MAC Enhancements for Robust Audio Video
Streaming", March 2012, Streaming", March 2012,
<http://standards.ieee.org/getieee802/ <http://standards.ieee.org/getieee802/
download/802.11aa-2012.pdf>. download/802.11aa-2012.pdf>.
[group_key]
Spiff, ""Why do some WiFi routers block multicast packets
going from wired to wireless?"", Jan 2017,
<https://superuser.com/questions/730288/why-do-some-wifi-
routers-block-multicast-packets-going-from-wired-to-
wireless>.
[I-D.ietf-6lo-backbone-router] [I-D.ietf-6lo-backbone-router]
Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6 Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6
Backbone Router", draft-ietf-6lo-backbone-router-11 (work Backbone Router", draft-ietf-6lo-backbone-router-11 (work
in progress), February 2019. in progress), February 2019.
[I-D.ietf-6tisch-architecture] [I-D.ietf-6tisch-architecture]
Thubert, P., "An Architecture for IPv6 over the TSCH mode Thubert, P., "An Architecture for IPv6 over the TSCH mode
of IEEE 802.15.4", draft-ietf-6tisch-architecture-20 (work of IEEE 802.15.4", draft-ietf-6tisch-architecture-24 (work
in progress), March 2019. in progress), July 2019.
[I-D.ietf-mboned-driad-amt-discovery]
Holland, J., "DNS Reverse IP AMT Discovery", draft-ietf-
mboned-driad-amt-discovery-08 (work in progress), June
2019.
[ietf_802-11] [ietf_802-11]
Stanley, D., "IEEE 802.11 multicast capabilities", Nov Stanley, D., "IEEE 802.11 multicast capabilities", Nov
2015, <https://mentor.ieee.org/802.11/ 2015, <https://mentor.ieee.org/802.11/
dcn/15/11-15-1261-03-0arc-multicast-performance- dcn/15/11-15-1261-03-0arc-multicast-performance-
optimization-features-overview-for-ietf-nov-2015.ppt>. optimization-features-overview-for-ietf-nov-2015.ppt>.
[mc-ack-mux] [mc-ack-mux]
Tanaka, Y., Sakai, E., Morioka, Y., Mori, M., Hiertz, G., Tanaka, Y., Sakai, E., Morioka, Y., Mori, M., Hiertz, G.,
and S. Coffey, "Multiplexing of Acknowledgements for and S. Coffey, "Multiplexing of Acknowledgements for
skipping to change at page 22, line 31 skipping to change at page 23, line 15
[Tramarin2017] [Tramarin2017]
Tramarin, F., Vitturi, S., and M. Luvisotto, "IEEE 802.11n Tramarin, F., Vitturi, S., and M. Luvisotto, "IEEE 802.11n
for Distributed Measurement Systems", 2017 IEEE for Distributed Measurement Systems", 2017 IEEE
International Instrumentation and Measurement Technology International Instrumentation and Measurement Technology
Conference (I2MTC) pp. 1-6, May 2017. 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", Nov 2015,
<https://mentor.ieee.org/802.15/ <https://mentor.ieee.org/802.15/
dcn/15/15-15-0521-01-wng0-llc-proposal-for-802-15-4.pptx>. dcn/15/15-15-0521-01-wng0-llc-proposal-for-802-15-4.pptx>.
Appendix A. Changes in this draft between revisions 04 versus 05 Appendix A. Changes in this draft between revisions 05 versus 06
This section lists the changes between revisions ...-05.txt and
...-06.txt of draft-ietf-mboned-ieee802-mcast-problems.
o Included new text in Security Considerations to alert about
problems regarding Group Key management caused by multicast
unreliability and implementation bugs.
o Included DRIAD as a discovery mechanism for multicast relays.
o Corrected occurrences of "which" versus "that" and "amount" versus
"number".
o Updated bibliographic citations, included URLs as needed.
o More editorial improvements and grammatical corrections.
Appendix B. Changes in this draft between revisions 04 versus 05
This section lists the changes between revisions ...-04.txt and This section lists the changes between revisions ...-04.txt and
...-05.txt of draft-ietf-mboned-ieee802-mcast-problems. ...-05.txt of draft-ietf-mboned-ieee802-mcast-problems.
o Incorporated text from Jake Holland for a new section about o Incorporated text from Jake Holland for a new section about
conversion of multicast to unicast and included AMT as an existing conversion of multicast to unicast and included AMT as an existing
solution. solution.
o Included some text about likely future multicast applications that o Included some text about likely future multicast applications that
will emphasize the need for attention to the technical matters will emphasize the need for attention to the technical matters
collected in this document. collected in this document.
o Further modified text to be more generic instead of referring o Further modified text to be more generic instead of referring
specifically to IETF conference situations. specifically to IETF conference situations.
o Modified text to be more generic instead of referring specifically o Modified text to be more generic instead of referring specifically
to Bonjour. to Bonjour.
o Added uPnP as a representative multicast protocol in IP networks. o Added uPnP as a representative multicast protocol in IP networks.
o Referred to Linux bridging code for multicast to unicast. o Referred to Linux bridging code for multicast to unicast.
o Updated bibliographic citations, included URLs as needed. o Updated bibliographic citations, included URLs as needed.
o More editorial improvements and grammatical corrections. o More editorial improvements and grammatical corrections.
Appendix B. Changes in this draft between revisions 03 versus 04 Appendix C. Changes in this draft between revisions 03 versus 04
This section lists the changes between revisions ...-03.txt and This section lists the changes between revisions ...-03.txt and
...-04.txt of draft-ietf-mboned-ieee802-mcast-problems. ...-04.txt of draft-ietf-mboned-ieee802-mcast-problems.
o Replaced "client" by "STA". o Replaced "client" by "STA".
o Used terminology "Wi-Fi" throughout. o Used terminology "Wi-Fi" throughout.
o Many editorial improvements and grammatical corrections. o Many editorial improvements and grammatical corrections.
o Modified text to be more generic instead of referring specifically o Modified text to be more generic instead of referring specifically
to IETF conference situations. to IETF conference situations.
o Cited [RFC5757] for introduction to other wireless media. o Cited [RFC5757] for introduction to other wireless media.
skipping to change at page 23, line 35 skipping to change at page 24, line 35
Phone: +1-408-330-4586 Phone: +1-408-330-4586
Email: charliep@computer.org Email: charliep@computer.org
Mike McBride Mike McBride
Futurewei Inc. Futurewei Inc.
2330 Central Expressway 2330 Central Expressway
Santa Clara, CA 95055 Santa Clara, CA 95055
USA USA
Email: michael.mcbride@huawei.com Email: michael.mcbride@futurewei.com
Dorothy Stanley Dorothy Stanley
Hewlett Packard Enterprise Hewlett Packard Enterprise
2000 North Naperville Rd. 2000 North Naperville Rd.
Naperville, IL 60566 Naperville, IL 60566
USA USA
Phone: +1 630 979 1572 Phone: +1 630 979 1572
Email: dstanley@arubanetworks.com Email: dstanley@arubanetworks.com
Warren Kumari Warren Kumari
 End of changes. 37 change blocks. 
85 lines changed or deleted 120 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/