Re: Reducing the battery impact of ND

Lorenzo Colitti <> Fri, 17 January 2014 22:50 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E64621ACCFC for <>; Fri, 17 Jan 2014 14:50:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.916
X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6rlfI3N-95lc for <>; Fri, 17 Jan 2014 14:49:59 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c05::231]) by (Postfix) with ESMTP id 65A8E1ACCF8 for <>; Fri, 17 Jan 2014 14:49:59 -0800 (PST)
Received: by with SMTP id k19so2900133igc.4 for <>; Fri, 17 Jan 2014 14:49:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=bSjP7bFvMGTDmPABDxuonKYWHfALWhkLdrmBtjoEBZY=; b=f6zWdp0FTRueIjOMDcFU+uWmh18brKdQ0ZK50P06NzizlK5S1U5BEjRT5+H23/JP3g AX3yqw/+Pit35bB9s2sPQHDS2DWXo5Ngv6ZIoa0AFmumSqdAgbpKuaj9WT7BaVq52aF3 nOwvkVtpEMGVAva9zD5RXVxgl4l3kLLwj4oFZEnB2NySaOOFudHuCnb9zkL5hmawE8Xb U7Mw5Y1Mm6YoRCBB/fjbSIqy0X974mHHZWMu3gYTtxkbo2a9CU4ACeDMopKTX8QD8NhU VaBAv80YYCWbdG/qJfTCpcZbgBxJPvHxMFonOGqJZtiPQ7AcF9/h07f4C2zjhaOk4L2F qTrA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=bSjP7bFvMGTDmPABDxuonKYWHfALWhkLdrmBtjoEBZY=; b=aChUslTHxZkYPguMeSmBYSFJSxNQ7GDk8loF6rSdfEk/w/YcYsfVbgM6xY5sd/zDOq FccQjsCsg41DmYj5FGAD9cTbd96IWrb1qx6llUKd0TokuCzOaueFWmRirJioJNELLfIh 9cRQEBvFwB1vbxCltWqnE1yDqAIBeltmSHXikZeDobN25QuJV5h1va+y9YoLrhX0W6mI H31DWMUz0fsv4R2LNMFEOZdycphC8FWShLmdJHchXvXOhrDM1mFyuLCTMDSYv+Ep7JeM c/wFQnLLJOts8Caq9qTifziZB9guObmh1oAsS85Pe7bwmJLJYCjWXhzpwOp7oic6SBYL qbwg==
X-Gm-Message-State: ALoCoQmZP/puCEtPgem6QfuDJiIkAXG42PbBWonNaQPu4vn29BXm9+/JJDbQZQaxIGiUGinOrJkiAeTFCJwhy6bkxtJDDjrQOzQnklNcIXQyTAb0PhkltTL+yqgMf29SzOXAoMWfrNUfO7Rei7ZOE3XUbS9B3F1YyMRGYvfB+5UwlXg0osYjZs6ycthCwpeWPspIwoVMXVnE
X-Received: by with SMTP id vh1mr4118591icb.24.1389998986587; Fri, 17 Jan 2014 14:49:46 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Fri, 17 Jan 2014 14:49:26 -0800 (PST)
In-Reply-To: <>
References: <> <>
From: Lorenzo Colitti <>
Date: Sat, 18 Jan 2014 07:49:26 +0900
Message-ID: <>
Subject: Re: Reducing the battery impact of ND
To: Erik Nordmark <>
Content-Type: multipart/alternative; boundary="bcaec5299ad7d88aa604f0325bb7"
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: Fri, 17 Jan 2014 22:50:02 -0000

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.

> 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 you're talking about
a sensor whose battery needs to last for months, then maybe not. But that's
what we have 6LowPAN for.