MBONED WG M. McBride
Internet-Draft C. Perkins
Intended status: Standards Track Huawei
Expires: April 29, 2018 October 26, 2017
Multicast Wifi Problem Statement
draft-mcbride-mboned-wifi-mcast-problem-statement-01
Abstract
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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
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 April 29, 2018.
Copyright Notice
Copyright (c) 2017 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
McBride & Perkins Expires April 29, 2018 [Page 1]
Internet-Draft Multicast Wifi Problem Statement October 2017
(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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Multicast over WiFi Problems . . . . . . . . . . . . . . . . 2
2.1. Low Reliability . . . . . . . . . . . . . . . . . . . . . 3
2.2. Low Data Rate . . . . . . . . . . . . . . . . . . . . . . 4
2.3. High Interference . . . . . . . . . . . . . . . . . . . . 4
2.4. High Power Consumption . . . . . . . . . . . . . . . . . 4
3. Common remedies to multicast over wifi problems . . . . . . . 4
4. State of the Union . . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
8. Normative References . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
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.
2. Multicast over WiFi Problems
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,
McBride & Perkins Expires April 29, 2018 [Page 2]
Internet-Draft Multicast Wifi Problem Statement October 2017
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:
o Low Reliability
o Lower Data Rate
o High interference
o High Power Consumption
These points will be elaborated separately in the following
subsections.
2.1. Low Reliability
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.
McBride & Perkins Expires April 29, 2018 [Page 3]
Internet-Draft Multicast Wifi Problem Statement October 2017
2.2. Low Data Rate
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.
2.3. High Interference
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.
2.4. High Power Consumption
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.
3. Common remedies to multicast over wifi problems
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
McBride & Perkins Expires April 29, 2018 [Page 4]
Internet-Draft Multicast Wifi Problem Statement October 2017
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.
4. State of the Union
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.
McBride & Perkins Expires April 29, 2018 [Page 5]
Internet-Draft Multicast Wifi Problem Statement October 2017
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).
5. IANA Considerations
None
6. Security Considerations
None
7. Acknowledgments
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
8. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Authors' Addresses
Mike McBride
Huawei
2330 Central Expressway
Santa Clara CA 95055
USA
Email: michael.mcbride@huawei.com
McBride & Perkins Expires April 29, 2018 [Page 6]
Internet-Draft Multicast Wifi Problem Statement October 2017
Charlie Perkins
Huawei
2330 Central Expressway
Santa Clara CA 95055
USA
Email: charlie.perkins@huawei.com
McBride & Perkins Expires April 29, 2018 [Page 7]