Re: Reducing the battery impact of ND

[Erik Nordmark <[e-mail]>]

On 1/17/14 2:49 PM, Lorenzo Colitti wrote:
> On Fri, Jan 17, 2014 at 9:20 AM, Erik Nordmark <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     One of your "yes please" below is a change to ND - Andrew's b) about
>     restarting RS would require a (small) standards update.
>
>
> We should try to get that into draft-6man-resilient-rs.

It seems to be out of scope for the problem resilent-rs set out to solve 
which was loss issues for the initial RS. It might not be wise to expand 
that drafts scope to also cover (part of) efficient-nd.

    Erik

>     And if you work out the details on b) I suspect you'll find that to
>     completely avoid the periodic multicast RAs the routers need to know
>     whether hosts expect periodic RA as opposed to all the hosts doing
>     the RS restart. That would imply some more protocol change.
>
>
> You don't need to avoid them. You just need to make them infrequent
> enough that they are not a substantial cause of power drain. I know from
> solid data that on a device like a mobile phone on a wifi network, an RA
> every 30 minutes is *way* down in the noise in terms of power
> consumption. (While "one RA every 3 seconds because the router sends a
> multicast RS to everyone every time a device joins the network" *does*
> have an impact).
>
>     And just to be perfectly clear, I don't think assuming (near)
>     perfect MLD snooping including in WiFi APs is undesirable. Hence my
>     focus has been to remove as much as possible of the ND multicasts
>     including the DAD and NS packets.
>
>
> You don't need to do the snooping on the APs. You can do it on the
> client side, in the wifi firmware. The power savings between "received
> but filtered out in wifi firmware" and "received, passed to the main
> processor and ignored" are substantial; again, for a mobile phone on
> wifi, we have data on this.
 >
>
>     But my overall observation is that if we think we can fix (even a
>     subset of) this without a standards update, then we are just fooling
>     ourselves.
>
>
> It depends what sort of device you're talking about. If you're talking
> about a mobile phone, then we can fix it for sure.

If all you want is to max the RA timers to > 30 minutes then you don't 
need a standards change. But the other things that have been discussed 
seem to require an update to RFC 4861.

FWIW I don't have a problem with an opt-in update to 4861. I even think 
efficient-nd is the way to go because it reduces overall ND multicast 
traffic and not just your narrow focus on mobile phone battery life.

    Erik

> If you're talking
> about a sensor whose battery needs to last for months, then maybe not.
> But that's what we have 6LowPAN for.
>
> Cheers,
> Lorenzo