Subject: [recipe] Sleeping Nodes

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 15 Jul 2011 09:37:42 +0300

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.

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 15 Jul 2011 08:31:40 +0000

Dear Hannes,

Thanks for reviving this list and pointing to Magaret's slides.

There is another extensive discussion of sleeping nodes in the keynote
http://www.green-communications.net/globecom09/docs/GreenComm-GLOBECOM09-1-
1-Gupta.pdf
that energy-saving pioneer Rajesh Gupta gave 2009 at the 2nd workshop of
the IEEE Green Communications
Workshop series at ICC and GlobeCom (http://www.green-communications.net/).

Cheers,

    Juergen

On 15.07.11 08:37, "Hannes Tschofenig" <[email-masked]> wrote:

>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:
>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
>
>_______________________________________________
>recipe mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/recipe

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 15 Jul 2011 11:58:24 +0300

Hi Juergen, 

thanks for the pointer. It is an interesting slide set. I have not seen it before. Nevertheless I missed a bit the higher layer protocol aspects. Most of the focus is on the radio equipment, which is certainly important, but not necessarily within the realm of the IETF. 

In a publication from Pasi he also investigated the keep alive aspects of protocol design and concluded that they have a negative impact on the battery lifetime. Here is the reference: 
Henry Haverinen, Jonne Siren, and Pasi Eronen. Energy Consumption of Always-On Applications in WCDMA Networks. In Proceedings of the 65th Semi-Annual IEEE Vehicular Technology Conference (VTC 2007 Spring), Dublin, Ireland, April 2007.
http://www.pasieronen.com/publications/haverinen_siren_eronen_vtc2007.pdf

It would be easy to suggest to get rid of NATs and firewalls, which are the main reason for increased keep alive message transmission to prevent state at these device to disappear, to improve energy efficiency but, as we know, that approach will not work easily. 

You may remember that we worked on NAT and firewall signaling protocols (in the NSIS working group) to control various aspects of these middleboxes. These could have provided an interesting potential to either learn about the state management policy or to even control it but they never got deployed. 

Ciao
Hannes

---

From: JinHyeock Choi <[email-masked]>
Date: Sat, 16 Jul 2011 23:17:26 +0900

Hannes

thanks for the pointers.

> 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