Re: [recipe] Sleeping Nodes

[Hannes Tschofenig <[e-mail]>]

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

On Jul 15, 2011, at 11:31 AM, Juergen Quittek wrote:

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