idnits 2.17.1 draft-mcbride-mboned-wifi-mcast-problem-statement-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 26, 2017) is 2346 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2119' is defined on line 273, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MBONED WG M. McBride 3 Internet-Draft C. Perkins 4 Intended status: Standards Track Huawei 5 Expires: April 29, 2018 October 26, 2017 7 Multicast Wifi Problem Statement 8 draft-mcbride-mboned-wifi-mcast-problem-statement-01 10 Abstract 12 There have been known issues with multicast, in an 802.11 13 environment, which have prevented the deployment of multicast in 14 these wifi environments. IETF multicast experts have been meeting 15 together to discuss these issues and provide IEEE updates. The 16 mboned working group is chartered to receive regular reports on the 17 current state of the deployment of multicast technology, create 18 "practice and experience" documents that capture the experience of 19 those who have deployed and are deploying various multicast 20 technologies, and provide feedback to other relevant working groups. 21 As such, this document will gather the problems of wifi multicast 22 into one problem statement document so as to offer the community 23 guidance on current limitations. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 29, 2018. 42 Copyright Notice 44 Copyright (c) 2017 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Multicast over WiFi Problems . . . . . . . . . . . . . . . . 2 61 2.1. Low Reliability . . . . . . . . . . . . . . . . . . . . . 3 62 2.2. Low Data Rate . . . . . . . . . . . . . . . . . . . . . . 4 63 2.3. High Interference . . . . . . . . . . . . . . . . . . . . 4 64 2.4. High Power Consumption . . . . . . . . . . . . . . . . . 4 65 3. Common remedies to multicast over wifi problems . . . . . . . 4 66 4. State of the Union . . . . . . . . . . . . . . . . . . . . . 5 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 69 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 70 8. Normative References . . . . . . . . . . . . . . . . . . . . 6 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 73 1. Introduction 75 Multicast over wifi has been used to low levels of success, usually 76 to a point of being so negative that multicast over wifi is not 77 allowed. In addition to protocol use of broadcast/multicast for 78 control messages, more applications, such as push to talk in 79 hospitals, video in enterprises and lectures in Universities, are 80 streaming over wifi. And many end devices are increasingly using 81 wifi for their connectivity. One of the primary problems multicast 82 over wifi faces is that link local 802.11 doesn't necessarily support 83 multicast, it supports broadcast. To make make multicast over wifi 84 work successfully we often need to modify the multicast to instead be 85 sent as unicast in order for it to successfully transmit with useable 86 quality. Multicast over wifi experiences high packet error rates, no 87 acknowledgements, and low data rate. This draft reviews these 88 problems found with multicast over wifi. While this is not a 89 solutions draft, common workarounds to some of the problems will be 90 listed, along with the impact of the workarounds. 92 2. Multicast over WiFi Problems 94 802.11 is a wireless broadcast medium which works well for unicast 95 and has become ubiquitous in its use. With multicast, however, 96 problems arise over wifi. There are no ACKs for multicast packets, 97 for instance, so there can be a high level of packet error rate (PER) 98 due to lack of retransmission and because the sender never backs off. 99 It is not uncommon for there to be a packet loss rate of 5% which is 100 particularly troublesome for video and other environments where high 101 data rates and high reliability are required. Multicast, over wifi, 102 is typically sent on a low date rate which makes video negatively 103 impacted. Wifi loses many more packets then wired due to collisions 104 and signal loss. There are also problems because clients are unable 105 to stay in sleep mode due to the multicast control packets continuing 106 to unnecessarily wake up those clients which subsequently reduces 107 energy savings. Video is becoming the dominant content for end 108 device applications, with multicast being the most natural method for 109 applications to transmit video. Unfortunately, multicast, even 110 though it is a very natural choice for video, incurs a large penalty 111 over wifi. 113 One big difference between multicast over wired versus multicast over 114 wired is that wired links are a fixed transmission rate. Wifi, on 115 the other hand, has a transmission rate which varies over time 116 depending upon the clients proximity to the AP. Throughput of video 117 flows, and the capacity of the broader wifi network, will change and 118 will impact the ability for QoS solutions to effectively reserve 119 bandwidth and provide admission control. 121 The main problems associated with multicast over WiFi are as follows: 123 o Low Reliability 125 o Lower Data Rate 127 o High interference 129 o High Power Consumption 131 These points will be elaborated separately in the following 132 subsections. 134 2.1. Low Reliability 136 Because of the lack of acknowledgement for packets from Access Point 137 to the receivers, it is not possible for the Access Point to know 138 whether or not a retransmission is needed. Even in the wired 139 Internet, this characteristic commonly causes undesirably high error 140 rates, contributing to the relatively slow uptake of multicast 141 applications even though the protocols have been available for 142 decades. The situation for wireless links is much worse, and is 143 quite sensitive to the presence of background traffic. 145 2.2. Low Data Rate 147 For wireless stations associated with an Access Points, the necessary 148 power for good reception can vary from station to station. For 149 unicast, the goal is to minimize power requirements while maximizing 150 the data rate to the destination. For multicast, the goal is simply 151 to maximize the number of receivers that will correctly receive the 152 multicast packet. For this purpose, generally the Access Point has 153 to use a much lower data rate at a power level high enough for even 154 the farthest station to receive the packet. Consequently, the data 155 rate of a video stream, for instance, would be constrained by the 156 environmental considerations of the least reliable receiver 157 associated with the Access Point. 159 2.3. High Interference 161 As mentioned in the previous subsection, multicast transmission to 162 the stations associated to an Access Point typically proceeds at a 163 much higher power level than is required for unicat to many of the 164 receivers. High power levels directly contribute to stronger 165 interference. The interference due to multicast may extend to 166 effects inhibiting packet reception at more distant stations that 167 might even be associated with other Access Points. Moreover, the use 168 of lower data rates implies that the physical medium will be occupied 169 for a longer time to transmit a packet than would be required at high 170 data rates. Thus, the level of interference due to multicast will be 171 not only higher, but longer in duration. 173 Depending on the choice of 802.11 technology, and the configured 174 choice for the base data rate for multicast transmission from the 175 Access Point, the amount of additional interference can range from a 176 factor of ten, to a factor thousands for 802.11ac. 178 2.4. High Power Consumption 180 One of the characteristics of multicast transmission is that every 181 station has to be configured to wake up to receive the multicast, 182 even though the received packet may ultimately be discarded. This 183 process has a relatively large impact on the power consumption by the 184 multicast receiver station. 186 3. Common remedies to multicast over wifi problems 188 One common solution to the multicast over wifi problem is to convert 189 the multicast traffic into unicast. This is often referred to as 190 multicast to unicast (MC2UC). Converting the packets to unicast is 191 beneficial because unicast packets are acknowledged and retransmitted 192 as needed to prevent as much loss. The Access Points (AP) is also 193 able to provide rate limiting as needed. The drawback with this 194 approach is that the benefit of using multicast is defeated. 196 Using 802.11n helps provide a more reliable and higher level of 197 signal-to-noise ratio in a wifi environment over which multicast 198 (broadcast) packets can be sent. This can provide higher throughput 199 and reliability but the broadcast limitations remain. 201 4. State of the Union 203 In discussing these issues over email and, most recently, in a side 204 meeting at IETF 99, it is generally agreed that these problems will 205 not be fixed anytime soon primarily because it's expensive to do so 206 and multicast is unreliable. The problem of v6 neighbor discovery 207 saturating the wifi link is only part of the problem. A big problem 208 is that the 802.11 multicast channel is an afterthought and only 209 given 100th of the bandwidth. Multicast is basically a second class 210 citizen, to unicast, over wifi. Unicast may have allocated 10mb 211 while Multicast will be allocated 1mb. There are many protocols 212 using multicast and there needs to be something provided in order to 213 make them more reliable. Wifi traffic classes may help. We need to 214 determine what problem should be solved by the IETF and what problem 215 should be solved by the IEEE. 217 Apple's Bonjour protocol, for instance, provides service discovery 218 (for printing) that utilizes multicast. It's the first thing 219 operators drop. Even if multicast snooping is utilized, everyone 220 registers at once using Bonjour and the network has serious 221 degradation. There is also a lot of work being developed to help 222 save battery life such as the devices not waking up when receiving a 223 multicast packet. If an AP, for instance, expresses a DTIM of 3 then 224 it will send a multicast packet every 3 packets. But the reality is 225 that most AP's will send a multicast every 30 packets. For unicast 226 there's a TIM. But because multicast is going to everyone, the AP 227 sends a broadcast to everyone. DTIM does power management but 228 clients can choose to wake up or not and whether to drop the packet 229 or not. Then they don't know why their bonjour doesn't work. The 230 IETF may just need to decide that broadcast is more expensive so 231 multicast needs to be sent wired. 802.1ak works on ethernet and wifi. 232 802.1ak has been pulled into 802.1Q as of 802.1Q-2011. 802.1Q-2014 233 can be looked at here: http://www.ieee802.org/1/pages/802.1Q- 234 2014.html . If we don't find a generic solution we need to establish 235 guidelines for multicast over wifi within the mboned wg. A multicast 236 over wifi IETF mailing list is formed (mcast-wifi@ietf.org) and more 237 discussion to be had there. This draft will serve as the current 238 state of affairs. 240 This is not a solutions draft, but to provide an idea going forward, 241 a reliable registration to Layer-2 multicast groups and a reliable 242 multicast operation at Layer-2 could provide a generic solution. 243 There is no need to support 2^24 groups to get solicited node 244 multicast working: it is possible to simply select a number of 245 trailing bits that make sense for a given network size to limit the 246 amount of unwanted deliveries to reasonable levels. We need to 247 encourage IEEE 802.1 and 802.11 to revisit L2 multicast issues. In 248 particular, Wi-Fi provides a broadcast service, not a multicast one. 249 In fact all frames are broadcast at the PHY level unless we beamform. 250 What comes with unicast is the property of being much faster (2 251 orders of magnitude) and much more reliable (L2 ARQ). 253 5. IANA Considerations 255 None 257 6. Security Considerations 259 None 261 7. Acknowledgments 263 The following people have contributed information and discussion in 264 the meetings and on the list which proved helpful for the development 265 of the latest version this Internet Draft: 267 Dave Taht, Donald Eastlake, Pascal Thubert, Juan Carlos Zuniga, 268 Mikael Abrahamsson, Diego Dujovne, David Schinazi, Stig Venaas, 269 Stuart Cheshire, Lorenzo, Greg Shephard, Mark Hamilton 271 8. Normative References 273 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 274 Requirement Levels", BCP 14, RFC 2119, 275 DOI 10.17487/RFC2119, March 1997, 276 . 278 Authors' Addresses 280 Mike McBride 281 Huawei 282 2330 Central Expressway 283 Santa Clara CA 95055 284 USA 286 Email: michael.mcbride@huawei.com 287 Charlie Perkins 288 Huawei 289 2330 Central Expressway 290 Santa Clara CA 95055 291 USA 293 Email: charlie.perkins@huawei.com