Re: [recipe] Sleeping Nodes

[Juergen Quittek <[e-mail]>]

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" <[e-mail]> 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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/recipe