Re: [recipe] Sleeping Nodes

JinHyeock Choi <jinchoe@gmail.com> Sat, 16 July 2011 14:17 UTC

Return-Path: <jinchoe@gmail.com>
X-Original-To: recipe@ietfa.amsl.com
Delivered-To: recipe@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4567721F85C6 for <recipe@ietfa.amsl.com>; Sat, 16 Jul 2011 07:17:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bv2p3zHC1aO7 for <recipe@ietfa.amsl.com>; Sat, 16 Jul 2011 07:17:32 -0700 (PDT)
Received: from mail-pz0-f52.google.com (mail-pz0-f52.google.com [209.85.210.52]) by ietfa.amsl.com (Postfix) with ESMTP id D3DB521F85C4 for <recipe@ietf.org>; Sat, 16 Jul 2011 07:17:29 -0700 (PDT)
Received: by pzd13 with SMTP id 13so2909880pzd.39 for <recipe@ietf.org>; Sat, 16 Jul 2011 07:17:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=GE56XFEu/YKtjHsfMwhy2gh2UGtN1YIo8X/nxcfJlBQ=; b=Fc8DO9EmtB5zIRVCDviaam5Iet5xXeYOfIuziQIA0L+4R+yl6RyVfG2AIrV8Eh+Er1 8c1WJz69iGHtHGBC7s5AU9k12HFRNz3hwjLDSmoZ6igz0Xywc7gBUCcxXdi3Oxh3qcBJ KIXDyfBXEtIcPSH5v0wMJZ0VUvgFYGOTcSX50=
MIME-Version: 1.0
Received: by 10.68.65.198 with SMTP id z6mr2797791pbs.218.1310825846186; Sat, 16 Jul 2011 07:17:26 -0700 (PDT)
Received: by 10.68.63.230 with HTTP; Sat, 16 Jul 2011 07:17:26 -0700 (PDT)
In-Reply-To: <1F32F796-E219-4673-85CE-6CE11A72820F@gmx.net>
References: <1F32F796-E219-4673-85CE-6CE11A72820F@gmx.net>
Date: Sat, 16 Jul 2011 23:17:26 +0900
Message-ID: <CAOqz15oyVXp=ZvxK9F3=cF4WQeHuwEeSi=9Su8w5WRTHJi5wiw@mail.gmail.com>
From: JinHyeock Choi <jinchoe@gmail.com>
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Cc: recipe@ietf.org, eerg-request@listserv.netlab.nec.de
Subject: Re: [recipe] Sleeping Nodes
X-BeenThere: recipe@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "RECIPE \(Reducing Energy Consumption with Internet Protocols Exploration\)" <recipe.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/recipe>, <mailto:recipe-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/recipe>
List-Post: <mailto:recipe@ietf.org>
List-Help: <mailto:recipe-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/recipe>, <mailto:recipe-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 16 Jul 2011 14:17:37 -0000

Hannes

thanks for the pointers.

> While Margaret talked a lot about ND I am wondering whether someone of
> you had looked into energy efficiency of other protocols already as well.

Bruce wrote “proxZzzy for sleeping hosts (Standard ECMA-393)”
http://www.ecma-international.org/publications/standards/Ecma-393.htm
which delves into proxy operation for sleep mode
and covers several protocols such as ND, DHCP, SIP....

While working on IPv6 over WiMAX in 16ng, we found out
it’s not easy for mobile nodes to operate in sleep mode
because of always-on assumption.

>From energy viewpoint, we'd better find a way to run protocols
with intermittent-on.

Thanks for your kind consideration.

Best regards

JinHyeock



On Fri, Jul 15, 2011 at 3:37 PM, Hannes Tschofenig
<hannes.tschofenig@gmx.net>; wrote:
> Hi all,
>
> in the recently published report from the Smart Object Workshop we have section about "sleeping nodes":
> http://tools.ietf.org/html//draft-iab-smart-object-workshop-01#section-3.2
>
> Given the scope of this group you may find the writeup interesting.
>
> The writeup was based on the discussions at the workshop following Margaret's presentation, which can found here http://www.iab.org/wp-content/IAB-uploads/2011/04/Wasserman.ppt.
> You may also find her paper "IT’S NOT EASY BEING 'GREEN'"  interesting:
> http://www.iab.org/wp-content/IAB-uploads/2011/03/Wasserman.pdf
>
> While Margaret talked a lot about ND I am wondering whether someone of you had looked into energy efficiency of other protocols already as well.
>
> Ciao
> Hannes
>
> --------
>
> 3.2.  Sleep Modes
>
>   One limitation of smart objects is the available energy.  To extend
>   battery life, for example of a watch battery or single AAA battery
>   for months, these small, low power devices have to sleep from 99% to
>   99.5% of their time.  For example, a light sensor may wake up to
>   check whether it is night-time to turn on light bulbs.  Most parts of
>   the system are off-line most of the time and particularly
>   communication components are put into a sleeping state (e.g., WLAN
>   radio interface) and only very few components of an embedded system
>   board, such as sensors, are triggered periodically.  When interesting
>   events happen then these components wake-up other parts of the
>   system, for example a radio interface to connect to the Internet.
>   Every bit is precious, so is every round trip, and every millisecond
>   of radio activity.
>
>   Many IETF protocols implicitly assume that nodes in a network are
>   always-on and respond to messages, i.e., to maintain a persistent
>   presence on the network in order to respond to periodic messages that
>   are required in order to maintain persistent sessions, connections,
>   security associations, or state.  These protocols work well on
>   networks with sufficient network bandwidth, where there is a low cost
>   to receiving/sending messages, and nodes are persistently available
>   on the network.
>
>   In the early days a machine had gotten a specific IP address
>   allocated and it could use it when it wanted to send an IP packet.
>   You might need to execute an ARP exchange first before sending the
>   packet but you could keep the mapping in the cache for 15 minutes.
>
>   Nowadays we want to make sure that we are on the right network before
>   we send an IP packet, we run neighbor discovery, we cannot keep
>   neighbor discovery for 15 minutes and so when a node wakes up again
>   it essentially has to re-do it to refresh the cache, we want to run
>   Detecting Network Attachment (DNA) procedures to check that hosts are
>   on the same network either by re-getting an address using the Dynamic
>   Host Configuration Protocol (DHCP) or by noticing that the node is
>   using the same default gateway because of a received Router
>   Advertisement (RA).  Essentially, a number of steps have to be taken
>   before sending a packet.
>
>   However, these protocols do not work well, if at all, when the cost
>   of sending/receiving those messages is high (in terms of bandwidth or
>   battery life) or in cases where nodes sleep periodically and are not
>   persistently available to receive those messages.  A number of issue
>   arise from these almost-always-off nodes.
>
>   Also a lot of our protocols are getting more chatty.  Keeping the
>   receiver up for an additional roundtrip costs extra energy.  Protocol
>   messages can also be lengthy, e.g., many protocols carry XML-based
>   payloads.
>
>   There are a couple of ways to think about how to make the situation
>   less worse:
>
>   1.  The Always-On Assumption
>
>       When designing a protocol that assumes that the nodes will always
>       be there at least consider an alternative paradigm.  For example,
>       with duplicate address detection an alternative would be not to
>       use it.  There might be also the option to consider an
>       architecture with a proxy node that these nodes can poll when
>       they boot up to find out whether anyone tried to contact them or
>       whether anything they care about has happened, or the proxy
>       answers on behalf of another node.
>
>
>   2.  High Cost to Rejoin the Network
>
>       The goal of these things is to determine whether a wireless node
>       is not moved to another network while it was asleep and that
>       might be a viable thing to do.  Expecting a wirelss node to go
>       through all these steps every time it wakes up before it is
>       allowed to send an Ip packet could be considered rather
>       excessive.
>
>       Can we find ways to reduce the number of protocol interactions
>       that have to be executed for network attachment, including
>       determining whether a node has moved or the environment has
>       changed otherwise?
>
>
>   3.  Verbose Protocols
>
>       Some protocols involve multiple roundtrips and/or lengthy
>       messages.  As a result, low-powered nodes have to use more power
>       in sending messages and have to stay powered on for a longer
>       period of time as they wait for the protocol exchanges to
>       complete.  The best way to address these problems is to ensure
>       that the simplest possible protocol exchanges are used when the
>       protocols in question are designed.  However, in some cases
>       alternative encoding formats and compression may also help.
>
>   One can argue that certain features are not useful in an environment
>   where most nodes are sleeping.  The main focus of past investigations
>   has been on IPv6 and ND but other protocols do also deserve a deeper
>   investigation, such as DNS, and DHCP.
>
>   During the protocol design phase certain protocols were assumed to be
>   used in a human-to-device context and therefore it was argued that
>   the verbose encoding is helpful.  Examples are the Hypertext Transfer
>   Protocol (HTTP), the Session Initiation Protocol (SIP), and
>   Extensible Messaging and Presence Protocol (XMPP).  Nowadays these
>   protocols are also being considered and used in device-to-device
>   communication and the verbose nature is not helpful.
>
>   While the principles seem to be most useful for low-power, battery
>   powered devices they would also be useful for other devices as well.
>   Energy efficiency is useful for normal devices as well, such as
>   laptops and smart phones.
>
>   For example, consider energy consumption in a home environment.  The
>   question is whether it will save more energy than it uses and
>   therefore one has to consider the overall energy consumption of the
>   entire solution.  This is not always an easy question to answer.
>   IEEE 802.11 nodes, for example, use a lot of power if they cannot be
>   made to sleep most of the time.  A light bulb may use less power but
>   there is also the device that controls the bulb that may consume a
>   lot of energy all the time.  In total, more energy may be consumed
>   when considering these two devices together.
>
> _______________________________________________
> recipe mailing list
> recipe@ietf.org
> https://www.ietf.org/mailman/listinfo/recipe
>