Multicast WiFi Problem Statement
Huawei
2330 Central Expressway
Santa Clara
CA 95055
USA
michael.mcbride@huawei.com
Huawei
2330 Central Expressway
Santa Clara
CA 95055
USA
charlie.perkins@huawei.com
OPS
MBONED WG
There have been known issues with multicast, in an 802.11 environment, which have prevented the deployment of multicast in these wifi
environments. IETF multicast experts have been meeting together to discuss these issues and provide IEEE updates. The mboned working
group is chartered to receive regular reports on the current state of the deployment of multicast technology, create "practice and experience"
documents that capture the experience of those who have deployed and are deploying various multicast technologies, and provide feedback
to other relevant working groups. As such, this document will gather the problems of wifi multicast into one problem statement document so
as to offer the community guidance on current limitations.
Multicast over wifi has been used to low levels of success, usually to a point of being so negative that multicast over wifi is not allowed.
In addition to protocol use of broadcast/multicast for control messages, more applications, such as push to talk in hospitals, video in
enterprises and lectures in Universities, are streaming over wifi. And many end devices are increasingly using wifi for their connectivity.
One of the primary problems multicast over wifi faces is that link local 802.11 doesn't necessarily support multicast, it supports broadcast. To make make
multicast over wifi work successfully we often need to modify the multicast to instead be sent as unicast in order for it to successfully transmit
with useable quality. Multicast over wifi experiences high packet error rates, no acknowledgements, and low data rate. This draft reviews these
problems found with multicast over wifi. While this is not a solutions draft, common workarounds to some of the problems will be listed, along
with the impact of the workarounds.
802.11 is a wireless broadcast medium which works well for unicast and has
become ubiquitous in its use. With multicast, however, problems arise
over wifi. There are no ACKs for multicast packets, for instance, so there can
be a high level of 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 packet loss rate of 5% which is particularly troublesome for video and other
environments where high data rates and high reliability are required.
Multicast, over wifi, is typically sent on a low date rate which makes
video negatively impacted. Wifi loses many more packets then wired
due to collisions and signal loss. There are also problems because
clients are unable to stay in sleep mode due to the multicast control
packets continuing to unnecessarily wake up those clients which
subsequently reduces energy savings. Video is becoming the dominant
content for end device applications, with multicast being the
most natural method for applications to transmit video. Unfortunately,
multicast, even though it is a very natural choice for video,
incurs a large penalty over wifi.
One big difference between multicast over wired versus multicast over
wired is that wired links are a fixed transmission rate. Wifi, on the
other hand, has a transmission rate which varies over time depending
upon the clients proximity to the AP. Throughput of video flows, and
the capacity of the broader wifi network, will change and will impact
the ability for QoS solutions to effectively reserve bandwidth and
provide admission control.
The main problems associated with multicast over WiFi are as follows:
Low Reliability
Lower Data Rate
High interference
High Power Consumption
These points will be elaborated separately in the following subsections.
Because of the lack of acknowledgement for packets from Access Point to
the receivers, it is not possible for the Access Point to know whether
or not a retransmission is needed. Even in the wired Internet,
this characteristic commonly causes undesirably high error rates,
contributing to the relatively slow uptake of multicast applications
even though the protocols have been available for decades. The
situation for wireless links is much worse, and is quite sensitive
to the presence of background traffic.
For wireless stations associated with an Access Points, the necessary
power 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.
For this purpose, generally the Access Point has to use a much lower
data rate at a power level high enough for even the farthest station to
receive the packet. 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 Access Point.
As mentioned in the previous subsection, multicast transmission to the
stations associated to an Access Point typically proceeds at a much
higher power level than is required for unicat to many of the receivers.
High power levels directly contribute to stronger interference. The
interference due to multicast may extend to effects inhibiting packet
reception at more distant stations that might even be associated with
other Access Points. Moreover, the use of lower data rates implies that
the physical medium will be occupied for a longer time to transmit a
packet than would be required at high data rates. Thus, the level
of interference due to multicast will be not only higher, but longer
in duration.
Depending on the choice of 802.11 technology, and the configured choice
for the base data rate for multicast transmission from the Access Point,
the amount of additional interference can range from a factor of ten,
to a factor thousands for 802.11ac.
One of the characteristics of multicast transmission is that every
station has to be configured to wake up to receive the multicast,
even though the received packet may ultimately be discarded. This
process has a relatively large impact on the power consumption by the
multicast receiver station.
One common solution to the multicast over wifi problem is to convert the
multicast traffic into unicast. This is often referred to as multicast
to unicast (MC2UC). Converting the packets to unicast is beneficial
because unicast packets are acknowledged and retransmitted as needed
to prevent as much loss. The Access Points (AP) is also able to provide
rate limiting as needed. The drawback with this approach is that the
benefit of using multicast is defeated.
Using 802.11n helps provide a more reliable and higher level of
signal-to-noise ratio in a wifi environment over which multicast (broadcast)
packets can be sent. This can provide higher throughput and reliability but
the broadcast limitations remain.
In discussing these issues over email and, most recently, in a side meeting at IETF 99, it is generally agreed that these problems will not be fixed
anytime soon primarily because it's expensive to do so and multicast is unreliable. The problem of v6 neighbor discovery saturating the wifi link is
only part of the problem. A big problem is that the 802.11 multicast channel is an afterthought and only given 100th of the bandwidth. Multicast is
basically a second class citizen, to unicast, over wifi. Unicast may have allocated 10mb while Multicast will be allocated 1mb. There are many protocols
using multicast and there needs to be something provided in order to make them more reliable. Wifi traffic classes may help. We need to determine what
problem should be solved by the IETF and what problem should be solved by the IEEE.
Apple's Bonjour protocol, for instance, provides service
discovery (for printing) that utilizes multicast. It's the first thing operators drop. Even if multicast snooping is utilized, everyone registers at once using Bonjour
and the network has serious degradation. There is also a lot of work being developed to help save battery life such as the devices not waking up when
receiving a multicast packet. If an AP, for instance, expresses a DTIM of 3 then it will send a multicast packet every 3 packets. But the reality is that most AP's will
send a multicast every 30 packets. For unicast there's a TIM. But because multicast is going to everyone, the AP sends a broadcast to everyone. DTIM does
power management but clients can choose to wake up or not and whether to drop the packet or not. Then they don't know why their bonjour doesn't work.
The IETF may just need to decide that broadcast is more expensive so multicast needs to be sent wired. 802.1ak works on ethernet and wifi. 802.1ak has been
pulled into 802.1Q as of 802.1Q-2011. 802.1Q-2014 can be looked at here: http://www.ieee802.org/1/pages/802.1Q-2014.html . If we don't find a generic solution
we need to establish guidelines for multicast over wifi within the mboned wg. A multicast over wifi IETF mailing list is formed (mcast-wifi@ietf.org) and more
discussion to be had there. This draft will serve as the current state of affairs.
This is not a solutions draft, but to provide an idea going forward, a reliable registration to Layer-2 multicast groups and a reliable multicast operation at Layer-2
could provide a generic solution. There is no need to support 2^24 groups to get solicited node multicast working: it is possible to simply select a number of trailing
bits that make sense for a given network size to limit the amount of unwanted deliveries to reasonable levels. We need to encourage IEEE 802.1 and 802.11 to revisit
L2 multicast issues. In particular, Wi-Fi provides a broadcast service, not a multicast one. In fact all frames are broadcast at the PHY level unless we beamform. What
comes with unicast is the property of being much faster (2 orders of magnitude) and much more reliable (L2 ARQ).
The following people have contributed information and discussion in the meetings and on the list which proved helpful for the
development of the latest version this Internet Draft:
Dave Taht, Donald Eastlake, Pascal Thubert, Juan Carlos Zuniga, Mikael Abrahamsson, Diego Dujovne,
David Schinazi, Stig Venaas, Stuart Cheshire, Lorenzo, Greg Shephard, Mark Hamilton