In this section, some of the issues related to the use of multicast transmissions over IEEE 802 wireless technologies are described.
Multicast traffic is typically much less reliable than unicast traffic. Since multicast makes point-to-multipoint communications, multiple acknowledgements would be needed to guarantee reception at all recipients. However, since there are no ACKs for multicast packets, it is not possible for the AP to know whether or not a retransmission is needed. Even in the wired Internet, this characteristic often causes undesirably high error rates. This has contributed to the relatively slow uptake of multicast applications even though the protocols have long been available. The situation for wireless links is much worse and is quite sensitive to the presence of background traffic. Consequently, there can be a high packet error rate (PER) due to lack of retransmission and because the sender never backs off. PER is the ratio, in percent, of the number of packets not successfully received by the device. It is not uncommon for there to be a packet loss rate of 5% or more, which is particularly troublesome for video and other environments where high data rates and high reliability are required.
Multicast over wired differs from multicast over wireless because transmission over wired links often occurs at a fixed rate. Wi-Fi, on the other hand, has a transmission rate that varies depending upon the STA's proximity to the AP. The throughput of video flows and the capacity of the broader Wi-Fi network will change with device movement. This impacts the ability for QoS solutions to effectively reserve bandwidth and provide admission control.
For wireless stations authenticated and linked with an AP, the power necessary for good reception can vary from station to station. For unicast, the goal is to minimize power requirements while maximizing the data rate to the destination. For multicast, the goal is simply to maximize the number of receivers that will correctly receive the multicast packet; generally, the AP has to use a much lower data rate at a power level high enough for even the farthest station to receive the packet, for example, as briefly mentioned in Section 4
of RFC 5757
. Consequently, the data rate of a video stream, for instance, would be constrained by the environmental considerations of the least-reliable receiver associated with the AP.
Because more robust modulation and coding schemes (MCSs) have a longer range but also a lower data rate, multicast/broadcast traffic is generally transmitted at the slowest rate of all the connected devices. This is also known as the basic rate. The amount of additional interference depends on the specific wireless technology. In fact, backward compatibility and multi-stream implementations mean that the maximum unicast rates are currently up to a few Gbps, so there can be more than 3 orders of magnitude difference in the transmission rate between multicast/broadcast versus optimal unicast forwarding. Some techniques employed to increase spectral efficiency, such as spatial multiplexing in Multiple Input Multiple Output (MIMO) systems, are not available with more than one intended receiver; it is not the case that backwards compatibility is the only factor responsible for lower multicast transmission rates.
Wired multicast also affects wireless LANs when the AP extends the wired segment; in that case, multicast/broadcast frames on the wired LAN side are copied to the Wireless Local Area Network (WLAN). Since broadcast messages are transmitted at the most robust MCS, many large frames are sent at a slow rate over the air.
Transmissions at a lower rate require longer occupancy of the wireless medium and thus take away from the airtime of other communications and degrade the overall capacity. Furthermore, transmission at higher power, as is required to reach all multicast STAs associated with the AP, proportionately increases the area of interference with other consumers of the radio spectrum.
One of the characteristics of multicast transmission over Wi-Fi is 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.
Clients may be unable to stay in sleep mode due to multicast control packets frequently waking them up.
A unicast packet is delayed until an STA wakes up and requests it. Unicast traffic may also be delayed to improve power save and efficiency and to increase the probability of aggregation.
Multicast traffic is delayed in a wireless network if any of the STAs in that network are power savers. All STAs associated with the AP have to be awake at a known time to receive multicast traffic.
Packets can also be discarded due to buffer limitations in the AP and non-AP STA.
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:
Control plane signaling
Applications (video delivery, stock data, etc.)
Other Layer 3 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.
The following list contains some representative discovery protocols that utilize broadcast/multicast and are used with IPv4.
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 [RFC 4541
] (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.
IPv6 makes extensive use of multicast, including the following:
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 with the mobility of a node. Router advertisement (RA) messages are also periodically multicast over the link.
Neighbors may be considered lost if several consecutive Neighbor Discovery packets fail.
Multicast Listener Discovery (MLD) [RFC 4541
] is used to identify members of a multicast group that are connected to the ports of a switch. Forwarding multicast frames into a Wi-Fi-enabled area can use switch support for hardware forwarding state information. However, since IPv6 makes heavy use of multicast, each STA with an IPv6 address will require state on the switch for several and possibly many solicited-node multicast addresses. A solicited-node multicast address is an IPv6 multicast address used by NDP to verify whether an IPv6 address is already used by the local link. Multicast addresses that do not have forwarding state installed (perhaps due to hardware memory limitations on the switch) cause frames to be flooded on all ports of the switch. Some switch vendors do not support MLD for link-scope multicast due to the increase it can cause in state.
On the Internet, there is a "background radiation" of scanning traffic (people scanning for vulnerable machines) and backscatter (responses from spoofed traffic, etc.). This means that routers very often receive packets destined for IPv4 addresses regardless of whether those IP addresses are in use. In the cases where the IP is assigned to a host, the router broadcasts an ARP request, receives an ARP reply, and caches it; then, traffic can be delivered to the host. When the IP address is not in use, the router broadcasts one (or more) ARP requests and never gets a reply. This means that it does not populate the ARP cache, and the next time there is traffic for that IP address, the router will rebroadcast the ARP requests.
The rate of these ARP requests is proportional to the size of the subnets, the rate of scanning and backscatter, and how long the router keeps state on non-responding ARPs. As it turns out, this rate is inversely proportional to how occupied the subnet is (valid ARPs end up in a cache, stopping the broadcasting; unused IPs never respond, and so cause more broadcasts). Depending on the address space in use, the time of day, how occupied the subnet is, and other unknown factors, thousands of broadcasts per second have been observed. Around 2,000 broadcasts per second have been observed at the IETF NOC during face-to-face meetings.
With Neighbor Discovery for IPv6 [RFC 4861
], nodes accomplish address resolution by multicasting a Neighbor Solicitation that asks the target node to return its link-layer address. Neighbor Solicitation messages are multicast to the solicited-node multicast address of the target address. The target returns its link-layer address in a unicast Neighbor Advertisement message. A single request-response pair of packets is sufficient for both the initiator and the target to resolve each other's link-layer addresses; the initiator includes its link-layer address in the Neighbor Solicitation.
On a wired network, there is not a huge difference between unicast, multicast, and broadcast traffic. Due to hardware filtering (see, e.g., [Deri-2010
]), inadvertently flooded traffic (or excessive Ethernet multicast) on wired networks can be quite a bit less costly compared to wireless cases where sleeping devices have to wake up to process packets. Wired Ethernets tend to be switched networks, further reducing interference from multicast. There is effectively no collision / scheduling problem except at extremely high port utilizations.
This is not true in the wireless realm; wireless equipment is often unable to send high volumes of broadcast and multicast traffic, causing numerous broadcast and multicast packets to be dropped. Consequently, when a host connects, it is often not able to complete DHCP, and IPv6 RAs get dropped, leading to users being unable to use the network.