Re: Reducing the battery impact of ND

[Tim Chown <[e-mail]>]

Hi,

On 11 Jan 2014, at 04:25, Lorenzo Colitti <[e-mail]> wrote:

> Andrew,
> 
> thank you for bringing solid data and analysis to the equation. That is always appreciated.
> 
> On Sat, Jan 11, 2014 at 8:57 AM, Andrew 👽 Yourtchenko <[e-mail]> wrote:
> 2) The bigger problem - the battery life:
> 
> This can be a real problem, yes. But as you say, I think we can mitigate it well without changing ND at all.
>  
> WiFi is a pretty expensive thing to do, power-wise. To help extend the
> battery, the mobile devices try very hard to shut off the radio
> whenever they can. The wireless station would go to sleep, and inform
> the AP about this fact - so the AP can buffer the frames for it [1].
> Further optimizations in this area were introduced by 802.11e (WMM-PS)
> [2], where the frames destined to workstation could be transmitted
> more efficiently and radio duty cycle is reduced.
> 
> Spontaneous all-hosts multicasts interfere with these mechanisms, thus
> the battery drain on the devices is much higher
> 
> One thing that I think we haven't discussed here is that in principle, there are *very few* all-hosts multicasts - basically, only RA. Even RS is all-routers multicast, not all hosts. So really the only thing we're talking about is solicited-node multicasts for NS (and occasional unsolicited NAs, which should only really happen when nodes change their MAC addresses. Note that I'm not talking about malicious nodes here because any malicious node can decide to spam the link with multicast messages regardless of what the ND protocol looks like.

This is a useful reminder to consider the use/impact of multicast in the dnssd work, given one of the scenarios is Zigbee networks. mDNS uses ff02::fb iirc.

Tim

> I think that using multicast instead of broadcast and defining solicited-node multicast addresses based on the IID, were very wise choices. This is because there are so many different groups (2^24), that even in very large networks, each solicited-node multicast group will likely only have one member. So - at least in principle - there are two layers at which the battery impact of NS packets can be reduced to zero or close to zero:
> If the AP keeps state of what MAC addresses have joined which multicast groups, it can selectively turn multicast NS into a set of unicast NS (L2 unicast; not L3 unicast). This will be a pretty significant bandwidth optimization both because a) as you say, unicast is faster than multicast, and b) because one multicast NS will almost certainly turn into only one unicast NS. Win/win.
> Even if the AP does not do #1, if the wifi chipset in the device keeps state of what multicast groups the device has joined, then the wifi chipset can simply drop packets that aren't interesting to the device's main CPU. From experience we know that this can also lead to massive battery savings - the wifi chipset is basically on a lot of the time anyway, because it has to listen for beacons and incoming packets, and this sort of filtering can be pretty efficient.
> That leaves RAs. Multicast RAs are a bane for battery life, because every time a device joins the network, it sends an RS. If the router responds with a multicast RA, then all devices on the link get a packet which they didn't need. On large wifi networks, I've seen this cause RAs once every 3-4 seconds, which is really painful in terms of battery life. Fortunately, there's an easy solution here: respond to router solicitations with unicast RAs sent to the sender. This is pretty trivial, and it doesn't require any state anywhere. There is a corner case where, if 10000 devices come online at the same time because the AP just booted up, you can get a thundering herd problem and have to send 10000 unicast packets, but this is can be optimized too: if the router sees that it's sending more than 100 solicited unicast RAs per second, it can simply send a multicast RA instead.
>  
> - especially in a typical network where the mobile devices move, and might trigger an RS/RA on each L2 roam between BSSIDs.
> 
> The client devices I'm familiar with don't send RSes when L2 roaming between BSSIDs on the same SSID. Is this a bug? Should they?
> 
> I hear someone saying: "Yes, but this is all about wireless, DC is all
> different story - it's all switches, they don't hold the state!" - yes
> and no.
> 
> I'd argue that it's not "yes and no", it's just "no". The state required by the approaches I suggest above is the same amount of state as multicast snooping, and it's pretty much the same amount of state required by the efficient ND approach - but it doesn't require complicating the ND protocol
>  
> Maybe worth to split the problem area into smaller subsets and see
> whether a "cheaper" solutions are possible. Let's first take the
> "multicast RAs" problem, and assume we do the below steps:
> 
> a) Allow the environments that wish to do so, to send solicited RAs
> unicast. (standard already permits to do so).
> 
> Yes please!
>  
> b) Have the hosts restart the  Resilient RS [5] process at 1/2 or so
> of router lifetime expiry: the router now can have the heuristic to
> know which hosts are supporting the "unicast RA update" mechanism
> *and* did not receive the periodic RA which would have been sent
> usually at 1/3 the lifetime expiry (three RAs per lifetime rule of
> thumb).
> 
> Yes please!
>  
> c) bump up the allowable MaxRtrAdvInterval and AdvDefaultLifetime to
> their maximum theoretically possible values (spec says the hosts
> should already be able to handle those, I did not test though) - this
> would allow to further reduce the periodic RA frequency, from 2.5
> hours today to ~18.2 hours, or, if we feel adventurous, put all-ones
> to be a "solicited-only RAs by default" - thus, unless another router
> sends an RA with different lifetime, refreshing the router info
> becomes host-driven, with an option for a router to override at any
> time.
> 
> This sort of depends what device you have. For example - on a mobile phone, receiving one packet every 2.5 hours is *so far down* in the noise that it just doesn't matter. Your phone is doing a massive amount of stuff already - it's syncing your email, receiving wifi beacons, checking calendar alarms, etc. etc. All of that uses way more CPU than receiving one multicast RA.
> 
> There may be other devices that have lower power requirements, though I'm not sure - perhaps these devices simply can't use 802.11-style wifi because it's too expensive, and so already have to use something like 6LowPAN. I don't know if there's a use case here.
>  
> These steps take care of the "multicast RA" problem. But again, also,
> each of them by itself brings incremental usefulness, and is doable on
> a single device => no "chicken and egg", they gradually shrink the
> issue - and are compatible with the existing tweaks that solve the
> same problem (in a more layer-violating way).
> 
> Care to work together on a document that provides operational guidance to optimize battery impact of ND on wifi networks? Since they involve zero protocol changes, v6ops would be a good candidate group for it. And it might help persuade vendors that are not your employer to implement stuff like this :-)
>  
> Now let's think of updating the various caches while roaming:
> 
> How much more do you think this sort of thing will help, assuming we do the "100% feasible using the existing protocol" stuff above?
> 
> NB: the above does not take care of the "defending the host's address
> on behalf of the sleeping node" problem.
> 
> An NS is 72 bytes, and if we do multicast snooping, then a sleeping node is only ever going to be woken up if a node with the same last 3 address bytes shows up. That should be extremely rare.
> 
> Cheers,
> Lorenzo
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------