Reducing the battery impact of ND

[Lorenzo Colitti <[e-mail]>]

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.

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:

   1. 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.
   2. 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