Re: Reducing the battery impact of ND

Erik Nordmark <> Sat, 18 January 2014 05:02 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5EC071ADBFF for <>; Fri, 17 Jan 2014 21:02:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Hp3uw2XR1thm for <>; Fri, 17 Jan 2014 21:02:04 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 025F91ADD02 for <>; Fri, 17 Jan 2014 21:02:03 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.14.4/8.14.4) with ESMTP id s0I51kVi028038 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 17 Jan 2014 21:01:47 -0800
Message-ID: <>
Date: Fri, 17 Jan 2014 21:01:46 -0800
From: Erik Nordmark <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Lorenzo Colitti <>
Subject: Re: Reducing the battery impact of ND
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Sonic-ID: C;nk2rof1/4xG7TjqjisUCUQ== M;Fgcuov1/4xG7TjqjisUCUQ==
Cc: 6man Chairs <>, 6man WG <>, Andrew 👽 Yourtchenko <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 18 Jan 2014 05:02:05 -0000

On 1/17/14 2:49 PM, Lorenzo Colitti wrote:
> On Fri, Jan 17, 2014 at 9:20 AM, Erik Nordmark <
> <>> 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.


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


> 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