idnits 2.17.1 draft-desmouceaux-ipv6-mcast-wifi-power-usage-00.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 (July 2014) is 3573 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Desmouceaux 3 Internet-Draft Cisco Systems 4 Intended status: Informational July 2014 5 Expires: December 31, 2014 7 Power consumption due to IPv6 multicast on WiFi devices 8 draft-desmouceaux-ipv6-mcast-wifi-power-usage-00 10 Abstract 12 IPv6 networks make a consequent use of multicast for several 13 purposes, including mandatory functions such as Neighbor Discovery. 14 Although this use of multicast does not create real difficulties on 15 wired networks, it can become painful on wireless ones, notably in 16 terms of power consumption. There might be little effect on home 17 networks, however, such effects become more important on large-scale 18 networks. This memo provides statistics about the multicast traffic 19 rate in a large IPv6 wireless network and the induced device power 20 consumption, in response to a call emitted at IETF 89. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on December 31, 2014. 39 Copyright Notice 41 Copyright (c) 2014 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Simplified BSD License text 50 as described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. IPv6 typical multicast traffic . . . . . . . . . . . . . . . . 3 57 2.1. Behavior when joining a network . . . . . . . . . . . . . 3 58 2.2. Behavior once connected . . . . . . . . . . . . . . . . . 3 59 3. Power consumption induced by multicast traffic . . . . . . . . 4 60 4. Large-scale wireless networks . . . . . . . . . . . . . . . . 5 61 4.1. Typical orders of magnitude . . . . . . . . . . . . . . . 5 62 4.1.1. Arrival rates . . . . . . . . . . . . . . . . . . . . 5 63 4.1.2. Connection durations . . . . . . . . . . . . . . . . . 6 64 4.2. Influence of such networks over devices . . . . . . . . . 7 65 4.3. Roaming . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 5. Possible solutions . . . . . . . . . . . . . . . . . . . . . . 8 67 5.1. Optimizing Router Solicitations retransmissions . . . . . 8 68 5.2. Proxying multicast traffic . . . . . . . . . . . . . . . . 8 69 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 74 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 1. Introduction 79 Multicast is widely used in IPv6 for configuration purposes through 80 the Neighbor Discovery protocol [RFC4861]. On IEEE 802.11 wireless 81 links, this can have a negative impact on low-energy devices such as 82 smartphones, as stated in [I-D.vyncke-6man-mcast-not-efficient]. The 83 802.11 protocol [IEEE80211] includes a power-save mode for such 84 devices, allowing them to be in a sleep state in which they will be 85 notified when packets addressed to them are pending. However, there 86 is no known powerful equivalent of wired-links Multicast Listener 87 Discovery (MLD) snooping [RFC4541], hence all devices will be woken 88 up when multicast traffic is pending. 90 In this document, we provide data illustrating the issue at 3 levels: 92 o typical multicast traffic emitted by a device when joining an IPv6 93 network, and 'background multicast noise' generated once 94 connected; 96 o power consumption statistics for wireless devices when confronted 97 to multicast traffic; 99 o orders of magnitude of connections frequencies and durations in 100 large-scale wireless networks. 102 Confronting these 3 levels makes it possible to model the power 103 consumption overhead of multicast traffic on typical large wireless 104 networks. 106 We finally discuss possible solutions at the IP and the 802.11 level. 108 2. IPv6 typical multicast traffic 110 2.1. Behavior when joining a network 112 When joining an IPv6 network, devices usually emit the following 113 multicast traffic: 115 1. duplicate address detection for the link-local address; 117 2. router solicitation; 119 3. duplicate address detection for the SLAAC address; 121 4. duplicate address detection for the SLAAC privacy address. 123 In addition, MLDv2 [RFC3810] frames are emitted for registration to 124 the solicited-node multicast addresses needed for Duplicate Address 125 Detection. Their number is not deterministic since other multicast 126 protocols may interfere, but is typically at least 4. 128 Depending on the configuration of the router, the Router 129 Advertisement sent by the router in response to the node's Router 130 Solicitation may also be multicast. 132 On Linux and Apple MacOS X clients that were tested, joining the 133 network also induces Multicast Domain Name System (mDNS) [RFC6762] 134 traffic. Once more, the number of packets emitted depends on the 135 network environment, but is around 20. Likewise, Microsoft Windows 136 clients generate Link-local Multicast Name Resolution (LLMNR) 137 [RFC4795] multicast traffic when they connect to the network. 139 2.2. Behavior once connected 141 Once connected, some devices keep on sending IPv6 multicast frames. 142 Protocols inducing such traffic include Neighbor Discovery, MLD, and 143 local discovery or name-resolution protocols, such as mDNS, LLMNR, 144 Simple Service Discovery Protocol (SSDP), Web Services Dynamic 145 Discovery (WS-D). 147 On a typical middle-scale enterprise network, IPv6 multicast traffic 148 induced by these protocols has a noticeable impact. Our measures on 149 a 160-hosts network show that the average rate of multicast traffic 150 transiting through the link is 4.5 frames per second. The following 151 table shows the repartition of the multicast traffic between these 152 protocols, as it was measured: 154 Protocol ICMPv6 mDNS LLMNR WS-D 156 Ratio 0.53 0.33 0.12 0.03 158 Based on the previous data, we can deduce how much multicast traffic 159 is generated by a "representative" device. Doing a simple cross- 160 multiplication, we obtain a rate of 0.028 multicast packets/s for a 161 single device, or 101 frames/hour. (This result is confirmed on a 162 small isolated test network of two hosts.) The following table shows 163 the indicative number of multicast packets emitted by a such a 164 representative device on our test network in an hour: 166 Protocol ICMPv6 mDNS LLMNR WS-D 168 Frames per hour 53 33 12 3 170 3. Power consumption induced by multicast traffic 172 While multicast traffic has no significant influence on actively 173 connected devices, it might have a poor impact on the ones that are 174 in power-save mode. 176 In power-save mode, the hardware of such a device needs to regularly 177 wake up in order to check whether pending frames are buffered for it. 178 To do so, it wakes up every DTIM_PERIOD beacons (DTIM_PERIOD usually 179 being set to 1 or 2) and retrieves the beacon emitted by the Access 180 Point (AP). If multicast traffic is pending, this will be indicated 181 by the AP by setting a specific bit in the beacons's Time Information 182 Management (TIM) information element to 1. 184 If a device sees that this bit is set, it will stay awake in order to 185 retrieve the frames. The device CPU will then be awakened and frames 186 will be transmitted by the wireless firmware to the IP stack. (Note 187 that this might not happen if the firmware implements a multicast 188 filter, but even in this case, current will be drawn to retrieve the 189 frames.) 191 Power consumption measurements on smartphone devices confirm the 192 negative impact of multicast traffic on sleeping devices. The 193 measurement was performed on a Samsung i9195 by attaching an ammeter 194 between the battery and the phone. When idle (screen off, GSM off, 195 WiFi on, 802.11 power-save enabled by the device), current drawn is 196 10 mA in average. When a multicast frame is received and the CPU 197 awakened to process it, the current draw goes to between 100 and 150 198 mA during a small peak of time. 200 Assuming that the duration of the current peak induced by processing 201 a multicast frame is 0.1 s, a device would hence use K times more 202 energy when it receives RATE multicast packets per second, than when 203 it receives none, where K = (10*(1 - RATE*0.1) + 150*RATE*0.1)/10. 204 The following table gives K as a function of RATE. 206 RATE (pkts/s) 0.01 0.1 0.5 1 2 4 >10 208 K 1.014 1.14 1.7 2.4 3.8 6.6 15 210 A possible workaround to this issue is to implement a multicast 211 filter at the firmware level, which will only forward multicast 212 packets to the IP stack if their destination address matches one of 213 those registered by the device. Although this would have a positive 214 impact on battery consumption, the following measurements show that 215 this is not entirely satisfying. 217 Indeed, current drawn to retrieve pending multicast frames at L2 218 without waking up the main CPU is around 40 mA, which is still 4 219 times more than idle consumption. In order to simulate this, one can 220 tweak a router so that it always advertises the presence of multicast 221 frames by setting the TIM multicast bit to 1. The device's radio will 222 then always try to retrieve frames following this beacon. 224 4. Large-scale wireless networks 226 Previous sections provide data about the battery usage induced by 227 individual multicast frames, and the number of multicast frames 228 generated by a single host when connecting and once connected. 230 In order to model the battery usage of real-life networks, the 231 following section provides data about connection arrival rates and 232 connection durations in usual large-scale wireless networks. 234 4.1. Typical orders of magnitude 236 The following results are based on anonymized data from a dualstack 237 WiFi network in a conference setup. These data provide interesting 238 statistics about user habits in a network characterized by mobility, 239 where users move much from one room to another. Plus, it is a good 240 example of a large wireless network, since the user count during 241 working hours is between 600 and 700. 243 4.1.1. Arrival rates 245 Arrival rates in this test network follow a probability distribution 246 which is very close to an exponential law (the error rate being only 247 6%). The observed parameter for this law is such that 1/lambda = 6 248 seconds. 250 We are therefore in a scheme expected by the classical queuing 251 theory, where arrivals are memoryless and have the Markov property of 252 independence of the past. The smallness of the parameter is also an 253 indicator of the great mobility of such networks: in average, a 254 client joined the network every 6 seconds. 256 There is a small bias in previous measures due to people arriving en 257 masse at the beginning of the day and going to lunch at noon. This 258 bias does not affect the exponential nature of the law. However, it 259 has an non-negligible effect over the parameter of the distribution. 260 Computing the probability distribution over a shorter unbiased amount 261 of time leads to a greater arrival rate: 1/lambda becomes 4.5 262 seconds. 264 From these data it appears that arrival rates in wireless networks 265 characterized by mobility are high. Since arrivals mean multicast 266 traffic issued by the client's IPv6 stack, this already provides a 267 rough intuition that large wireless networks feature high rates of 268 multicast frames. 270 4.1.2. Connection durations 272 Once clients are connected, duration of their connections follow a 273 less typical probability distribution, which form is represented 274 below: 276 dur. distr. 277 ^ 278 | || 279 | || 280 | |\ 281 | | | 282 | | | 283 | | | 284 | | \ 285 | | \_ 286 | | \__ 287 | | \_____ 288 |____| \______ 289 | \_________ 290 +--------------------------------------> t 292 From these data it appears that there is a peak of connections which 293 last 5 minutes, whereas almost no connection lasts less than this. A 294 plausible explanation for this is that there are two kinds of 295 behaviors: devices which automatically join the network without human 296 intervention and disconnect after an idle timeout, and users who 297 consciously connect to the network. After this peak, the 298 distribution is roughly an exponential law, which correspond to the 299 latter case. 301 An average connection time of 55 minutes has been measured: at least, 302 clients do not seem to be eager to leave the network too soon once 303 they have joined it. 305 In our test network, arrivals follow an exponential law, and service 306 times do not follow a close-form probability distribution. We can 307 therefore model it as an M/G/oo queue. Once stabilized, the number 308 of hosts in such a system follows a Poisson law of parameter S/T, 309 where S is the expected service time and T=1/lambda the expected time 310 between two arrivals. 312 4.2. Influence of such networks over devices 314 In this section, we model the influence of a large wireless network 315 over a device, in terms of power consumption. 317 Let us assume that in average, N devices are present in the network, 318 and that the arrival rate is lambda. (See Section 4.1 for typical 319 numerical values). Then, Section 2 implies that the rate of multicast 320 frames in the network is RATE = 0.025*N + 4*lambda. The following 321 table gives RATE for a few values of N and lambda: 323 N 5 10 50 100 500 500 325 1/lambda (s) 600 600 60 60 60 5 327 RATE (pkts/s) 0.13 0.26 1.32 2.57 12.6 13.3 329 Finally, using Section 3, we can compute what is the energy overhead 330 induced by the multicast traffic on a device. This overhead is K = 331 (10*(1 - (0.025*N + 4*lambda)*10 + 150*(0.025*N + 4*lambda)*10)/10. 332 The following table gives K as a function of N and lambda: 334 N 5 10 50 100 500 500 336 1/lambda (s) 600 600 60 60 60 5 338 K 1.18 1.36 2.84 4.59 15 15 340 Thus, battery consumption induced by multicast traffic will be 341 doubled in a network of 30 nodes where the arrival rate is 10 342 minutes. 344 4.3. Roaming 346 Depending on the configuration of the wireless network, roaming might 347 have different consequences on multicast traffic emission. 349 When a host moves from one access point to another, roaming is 350 supposed to be seamless. If a device detects a drop in signal 351 quality, it will probe for a nearer access point with the same SSID. 352 If it finds one, it will send an Authentication frame and a 353 Reassociation Request. This will seem transparent to L3, except that 354 some timers may time out, causing retransmissions. 356 However, if access points are not properly geographically distributed 357 within the network, a device might lose connection to one before it 358 can reconnect to another. In such a case, seamless roaming cannot 359 happen and the device will have to go through the whole process of 360 connection at the IPv6 level. This will generate multicast traffic 361 as discussed in Section 2.1. 363 5. Possible solutions 365 [I-D.yourtchenko-colitti-nd-reduce-multicast] already provides 366 solutions at the IP layer. These include: 368 o increasing intervals between Router Advertisements, and possibly 369 remove the limit of 9000 s set by [RFC4861]; 371 o increasing the timer value for Neighbor Unreachability Detection; 373 o unicasting Router Advertisements; 375 o multicast filtering at the infrastructure level (MLD snooping). 377 At the L2 layer, it suggests using an efficient on-device multicast 378 filter which would send frames to the IP layer only if their 379 destination address is registered. 381 We explore other possible solutions in the next sections. 383 5.1. Optimizing Router Solicitations retransmissions 385 Some wireless systems retransmit all multicast packets received, so 386 that hosts have a better chance to obtain them. This causes a 387 problem when retransmitted packets are not desirable for hosts. 389 Without having to implementing a full multicast snooping mechanism, 390 which can be costly in terms of resources and complexity for small 391 systems like home boxes, a simple fix can be applied to APs in order 392 to reduce the amount of multicast traffic retransmitted. APs should 393 refrain from retransmitting packets destined to the all routers 394 address (ff02::2), since routers should not be present on the 395 wireless side. Essentially, Router Solicitations will be concerned. 397 5.2. Proxying multicast traffic 398 Some multicast traffic is only relevant to routers (for instance, MLD 399 reports) or can be proxied by them (mDNS, ND). For instance, 400 [RFC4389] specifies a means to proxy Neighbor Discovery traffic. 401 Hosts are informed of the router proxying Neighbor Discovery traffic 402 thanks to a bit in Router Advertisements. 404 On the same model, a more general option in Router Advertisements 405 could indicate which multicast addresses a router is able to proxy. 406 When a host receives such a Router Advertisement, it will record 407 those addresses. It will then use the router L2 address instead of a 408 33:33:XX:XX:XX:XX multicast L2 address as destination for 409 corresponding packets, thus reducing multicast traffic emission. The 410 router will still be able to know that the final destination is 411 multicast, since the destination IP address remains multicast (a 412 behavior permitted by [RFC6085]). A disadvantage of this solution, 413 though, is that it requires changes to the hosts. 415 6. Acknowledgements 417 The author would like to thank Andrew Yourtchenko, Eric Vyncke, Ole 418 Troan, Brian Hart and Mark Townsley for their precious opinions on 419 the subject. 421 7. IANA Considerations 423 This memo includes no request to IANA. 425 8. Security Considerations 427 None. 429 9. References 431 9.1. Normative References 433 [IEEE80211] 434 Institute of Electrical and Electronics Engineers, 435 "Wireless LAN Medium Access Control (MAC) and Physical 436 Layer (PHY) Specifications", IEEE Standard 802.11, 2012. 438 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 439 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 441 [RFC4861] Narten, T., Nordmark, E., Simpson, W. and H. Soliman, 442 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 443 September 2007. 445 [RFC6085] Gundavelli, S., Townsley, M., Troan, O. and W. Dec, 446 "Address Mapping of IPv6 Multicast Packets on Ethernet", 447 RFC 6085, January 2011. 449 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 450 February 2013. 452 9.2. Informative References 454 [I-D.vyncke-6man-mcast-not-efficient] 455 Vyncke, E., Thubert, P., Levy-Abegnoli, E. and A. 456 Yourtchenko, "Why Network-Layer Multicast is Not Always 457 Efficient At Datalink Layer", Internet-Draft draft-vyncke- 458 6man-mcast-not-efficient-01, February 2014. 460 [I-D.yourtchenko-colitti-nd-reduce-multicast] 461 Yourtchenko, A. and L. Colitti, "Reducing Multicast in 462 IPv6 Neighbor Discovery", Internet-Draft draft- 463 yourtchenko-colitti-nd-reduce-multicast-00, February 2014. 465 [RFC4389] Thaler, D., Talwar, M. and C. Patel, "Neighbor Discovery 466 Proxies (ND Proxy)", RFC 4389, April 2006. 468 [RFC4541] Christensen, M., Kimball, K. and F. Solensky, 469 "Considerations for Internet Group Management Protocol 470 (IGMP) and Multicast Listener Discovery (MLD) Snooping 471 Switches", RFC 4541, May 2006. 473 [RFC4795] Aboba, B., Thaler, D. and L. Esibov, "Link-local Multicast 474 Name Resolution (LLMNR)", RFC 4795, January 2007. 476 Author's Address 478 Yoann Desmouceaux 479 Cisco Systems 480 Issy Les Moulineaux, 92130 481 France 483 Email: ydesmouc@cisco.com