Subject: Re: [Roll] Energy metric for link (was: Polling WG for adoption of Metrics Draft)

From: Mukul Goyal <[email-masked]>
Date: Mon, 27 Apr 2009 13:49:34 -0500 (CDT)

I am not sure if the routing protocol MUST aim for maximization of the network life time. There will be a variety of the nodes in the network - some nodes dedicated to forwarding packets of others, some nodes just acting as end points and some nodes doing both operations. I think, rather than aiming for optimizing the life time/performance, the routing protocol should allow different "local" policies to be enforced. The routing protocol should not decide whether a node must participate in routing. The routing protocol should find the best routes among the nodes willing to forward packets. A node should be able to decide whether to forward packets or not based on the local policy factors such as battery levels.

Thanks
Mukul
   
----- Original Message -----
From: "Richard Kelsey" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Sent: Monday, April 27, 2009 10:04:27 AM GMT -06:00 US/Canada Central
Subject: Re: [Roll] Energy metric for link (was: Polling WG for adoption of  Metrics Draft)

   Date: Fri, 24 Apr 2009 23:31:09 +0200
   From: Michele Rossi <[email-masked]>

   In some cases, we may want to extend the lifetime of some specific
   nodes due to their location in the network or to their specific
   function, and residual energies can be used as a metric to implement
   this.

This requires a mechanism to determine which nodes should
use their residual energy to originate messages and which
nodes should use their residual energy to forward messages.

   Thus, I agree with Mukul in that a node could locally
   decide whether to participate or not in the routing based
   on local metrics, such as its residual battery level
   (among others). As an example, nodes in a sensor network
   that are sensing an important event and that are also
   running out of battery could decide to use their energy
   to send their measurements to a gathering point rather
   than relaying messages from other nodes.

How does a node determine whether its measurements are more
or less important than some other device's measurements?
Not participating in routing makes sense only if the
device's local measurements have a higher priority than
other devices'.  This doesn't seem like a decision that can
be made locally.

If every node decides to reserve the last X% of its battery
for its own measurements, then a network is likely to
shut down as soon as a significant number of nodes is down to
X% battery.  This make sense only if X is zero.  Why shut
down when there is still energy available?

   Finally, I agree with Richard in that using a link metric
   would lead to more stable routing.

That wasn't the point I was trying to make.  My point was
that it makes more sense to treat a battery powered device
as being bandwith limited, with the limit determined by its
initial energy and its design lifetime, than as a device
that has one behavior for the first part of its lifetime and
then switches to some other behavior when its battery gets
low.  How this is reflected in a metric is a separate issue.

For example, a battery-powered node could dynamically adjust
its cost(s) to be as low as possible within its bandwidth
limit.  If it forwards too many messages it pushes the cost
up; too few and it reduces its cost, down to some floor
determined by its non-energy-related costs.  This would
maximize the utility of the network while ensuring that
the device lasts as long as it is meant to.

                                 -Richard Kelsey

---

From: Mischa Dohler <[email-masked]>
Date: Tue, 28 Apr 2009 09:28:35 +0200

Mukul, for the reasons you outlined and a long list of other reasons, we 
have been very careful to use the word "optimize" instead of "maximize" 
in our drafts. Mischa.

Mukul Goyal wrote:
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 28 Apr 2009 10:52:35 +0200

Hi Mukul and Misha:

I think you're making a fundamental point that there is some
deployment/case specific logic that will influence the selection of the
routing topologies that a node belongs to, the peers it associates with,
and the next hops it selects for a given route. There will be routing
time logic (participating to a topology) and forwarding time logic
(distributing packets to feasible successors).  

The routing logic might use battery levels, the scavenging capabilities,
or it might not. It might use a number of other parameters such as level
of security, Group identifier, available bandwidth, and anything from
barometric pressure to relative speed. The forwarding logic might use
filtered forwarding success history, fairness/load balancing, bicasting,
interference level, xmit power, etc...).

An example in the Home Automation case is for a node to decide to
participate (or not) to a routing topology towards a given sink,
depending on the reachability that the sink provides (default route vs.
power utility network vs. home surveillance network).
 
The roll fundamentals drafts identifies this external decision engine as
a plug-in to the tree formation protocol because we expect a same core
routing mechanism with loop avoidance Esperanto, but multiple,
case-by-case, routing and forwarding policies. In particular, it should
be possible to get some basic, un-optimized and maybe degraded services
out of a network of nodes that do not all implement a same common set of
policies because if we fail to enable that, we'll be stuck with our
initial set of policies and will block all evolution.

I understand that the term 'plug-in' might be ill-chosen. More important
than the name is to reach consensus on the concept, at which point we'll
probably have to define an open TLV infrastructure with generic
propagation rules to enable the advertisement of specific information
and enable the implementation of the specific 'plug-ins' that will be
required for specific policies.

Pascal

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
Mischa Dohler
>Sent: mardi 28 avril 2009 09:29
>To: Mukul Goyal
>Cc: [email-masked]; [email-masked]
>Subject: Re: [Roll] Energy metric for link
>
>> I am not sure if the routing protocol MUST aim for maximization of
the network life time. There will be a
>variety of the nodes in the network - some nodes dedicated to
forwarding packets of others, some nodes just
>acting as end points and some nodes doing both operations. I think,
rather than aiming for optimizing the life
>time/performance, the routing protocol should allow different "local"
policies to be enforced. The routing
>protocol should not decide whether a node must participate in routing.
The routing protocol should find the
>best routes among the nodes willing to forward packets. A node should
be able to decide whether to forward
>packets or not based on the local policy factors such as battery
levels.

---

From: <[email-masked]>
Date: Tue, 28 Apr 2009 10:34:03 +0100

Hi all:
It looks that the residual node energy has been extensively discussed.
Well, how about the expected node lifetime itself? The residual energy
rule helps equalize node lifetime yet sometimes node lifetimes are not
expected the same according to their roles. For instance, one sensor
node may be expected to work for years while another one may only be
expected to work for months. So, besides the residual node energy
parameter, how about to jointly consider another one, such as expected
node lifetime?

Best,
Dali

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Mukul Goyal
Sent: 27 April 2009 19:50
To: Richard Kelsey
Cc: [email-masked]; [email-masked]
Subject: Re: [Roll] Energy metric for link (was: Polling WG for adoption
of Metrics Draft)

I am not sure if the routing protocol MUST aim for maximization of the
network life time. There will be a variety of the nodes in the network -
some nodes dedicated to forwarding packets of others, some nodes just
acting as end points and some nodes doing both operations. I think,
rather than aiming for optimizing the life time/performance, the routing
protocol should allow different "local" policies to be enforced. The
routing protocol should not decide whether a node must participate in
routing. The routing protocol should find the best routes among the
nodes willing to forward packets. A node should be able to decide
whether to forward packets or not based on the local policy factors such
as battery levels.

Thanks
Mukul
   
----- Original Message -----
From: "Richard Kelsey" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Sent: Monday, April 27, 2009 10:04:27 AM GMT -06:00 US/Canada Central
Subject: Re: [Roll] Energy metric for link (was: Polling WG for adoption
of  Metrics Draft)

                                 -Richard Kelsey

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 28 Apr 2009 13:59:18 +0200

Mukul Goyal a écrit :
> the network life time.

I think the routing protocol could maximize for the network life time,
or for path life time, or for other relevant criterion.

I think it's worth conceiving the metrics now and make use of them in
various ways later.

> There will be a variety of the nodes in the network - some nodes
> dedicated to forwarding packets of others, some nodes just acting as
> end points and some nodes doing both operations. I think, rather than
> aiming for optimizing the life time/performance, the routing protocol
> should allow different "local" policies to be enforced. The routing
> protocol should not decide whether a node must participate in
> whether to forward packets or not based on the local policy factors
> such as battery levels.

I agree mainly with the policy aspect.

I just think today although there are ideas about what a ROLL routing 
protocol may be, there is really no detail concept of an energy-related 
metric, or how that ROLL protocol may make use of it.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 28 Apr 2009 14:12:34 +0200

[email-masked] a écrit :
> Hi all: It looks that the residual node energy has been extensively 
> discussed. Well, how about the expected node lifetime itself? The 
> residual energy rule helps equalize node lifetime yet sometimes node 
> lifetimes are not expected the same according to their roles. For 
> instance, one sensor node may be expected to work for years while 
> another one may only be expected to work for months. So, besides the 
> residual node energy parameter, how about to jointly consider another
>  one, such as expected node lifetime?

I agree, I think representing the residual energy level of a battery
absolutely needs to express how old is that battery and maybe how many
recharging cycles has it been subjected to.

My liion battery lasts much shorter now than a year ago.

Alex

> 
> Best, Dali
> 
> -----Original Message----- From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Mukul Goyal Sent: 27 
> April 2009 19:50 To: Richard Kelsey Cc: [email-masked]; 
> [email-masked] Subject: Re: [Roll] Energy metric for link (was: 
> Polling WG for adoption of Metrics Draft)
> 
> the network life time. There will be a variety of the nodes in the 
> network - some nodes dedicated to forwarding packets of others, some 
> nodes just acting as end points and some nodes doing both operations.
>  I think, rather than aiming for optimizing the life
> policies to be enforced. The routing protocol should not decide
> whether a node must participate in routing. The routing protocol
> should find the best routes among the nodes willing to forward
> packets. A node should be able to decide whether to forward packets
> or not based on the local policy factors such as battery levels.
> 
> Thanks Mukul
> 
> ----- Original Message ----- From: "Richard Kelsey" 
> <[email-masked]> To: [email-masked] Cc: [email-masked], 
> [email-masked] Sent: Monday, April 27, 2009 10:04:27 AM GMT -06:00 
> US/Canada Central Subject: Re: [Roll] Energy metric for link (was: 
> Polling WG for adoption of  Metrics Draft)
> 
> Date: Fri, 24 Apr 2009 23:31:09 +0200 From: Michele Rossi 
> <[email-masked]>
> 
> This requires a mechanism to determine which nodes should use their 
> residual energy to originate messages and which nodes should use 
> their residual energy to forward messages.
> 
> Thus, I agree with Mukul in that a node could locally decide whether 
> to participate or not in the routing based on local metrics, such as 
> its residual battery level (among others). As an example, nodes in a 
> sensor network that are sensing an important event and that are also
>  running out of battery could decide to use their energy to send
> their measurements to a gathering point rather than relaying messages
> from other nodes.
> 
> How does a node determine whether its measurements are more or less 
> important than some other device's measurements? Not participating in
>  routing makes sense only if the device's local measurements have a 
> higher priority than other devices'.  This doesn't seem like a 
> decision that can be made locally.
> 
> If every node decides to reserve the last X% of its battery for its 
> own measurements, then a network is likely to shut down as soon as a 
> significant number of nodes is down to X% battery.  This make sense 
> only if X is zero.  Why shut down when there is still energy 
> available?
> 
> Finally, I agree with Richard in that using a link metric would lead 
> to more stable routing.
> 
> That wasn't the point I was trying to make.  My point was that it 
> makes more sense to treat a battery powered device as being bandwith 
> limited, with the limit determined by its initial energy and its 
> design lifetime, than as a device that has one behavior for the first
>  part of its lifetime and then switches to some other behavior when 
> its battery gets low.  How this is reflected in a metric is a 
> separate issue.
> 
> For example, a battery-powered node could dynamically adjust its 
> cost(s) to be as low as possible within its bandwidth limit.  If it 
> forwards too many messages it pushes the cost up; too few and it 
> reduces its cost, down to some floor determined by its 
> non-energy-related costs.  This would maximize the utility of the 
> network while ensuring that the device lasts as long as it is meant 
> to.
> 
> -Richard Kelsey _______________________________________________ Roll 
> mailing list [email-masked] https://www.ietf.org/mailman/listinfo/roll
>  _______________________________________________ Roll mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/roll
>