Subject: Re: [Roll] DT update -- MUSTs - energy for link metric? (JP Vasseur)

From: "Theodore Zahariadis" <[email-masked]>
Date: Wed, 20 May 2009 10:21:45 +0300

Dear Tim, Alex,

Maybe the question could be asked somewhat differently...
Maybe something like:
"Is the network survivability a routing protocol requirement or a feature?"
or
"Is a routing protocol that can achieve longer lifetime for the network
(as a whole) better than a protocol that exhausts selectively some
nodes?"

If energy is not taken into account and a node has many data to send,
then the nodes in a fixed path will be exhausted. On the other hand, if 
energy
is a metric, the path will change (maybe it will not be always the
optimal one), but the energy will be reduced progressively. Moreover, if
the nodes have a method to create some energy (e.g. a tiny photovoltaic 
cell,
or windmill) the network may survive.

We have done a number of simulations in JSIM trying to combine routing and
trust. It seams that even in a trust framework, taking into account energy 
metrics
may drastically increase the network lifetime.

Of course all these apply to homogeneous nodes. If the nodes are 
heterogeneous
calculating the optimal energy metric may be too hard (may not worth).
On the other hand, there may be some thresholds put e.g. "if the remaining
energy of node "a" is less than "x", avoid it, unless it is the node with 
the maximum
energy in the neighborhood".

BR,
Theodore

> Date: Tue, 19 May 2009 14:38:06 +0200
> From: JP Vasseur <[email-masked]>
> Subject: Re: [Roll] DT update -- MUSTs - energy for link metric?
> To: Alexandru Petrescu <[email-masked]>
> Cc: ROLL WG <[email-masked]>, [email-masked]
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes
>
> but again, this does not really answer *the* question: why should the
> routing protocol take link energy into account during path computation ?
>
> On May 19, 2009, at 12:11 PM, Alexandru Petrescu wrote:
>
>> JP Vasseur a ?crit :
>>> Hi Alex,
>>> On May 15, 2009, at 8:39 AM, Alexandru Petrescu wrote:
>>>> Tim, thanks for the update - that's hard work.
>>>> A side remark about one particular interest: the req list doesn't
>>>> seem to include a metric for energy of the link: energy necessary
>>>> to send a packet on the link, or energy radiated in the air, or
>>>> similar.
>>>> Or I can't find it - is there one?
>>>> I do find reqs for energy as constraints of the node device: level
>>>> of energy, energy of the node, power available, power budget, etc.
>>>> Or is the link energy completely out of scope?
>>> It would be useful to know what the WG thinks about link energy
>>> metrics.
>>
>> I am very interested on all WG oppinions on link energy metric.
>>
>>> Here is my take on it. Node energy metric is undoubtedly needed, in
>>> many cases, one may want to avoid a node that is battery operated or
>>> running our of battery, we are all in sync with this. Now with
>>> regards to link energy metrics, this is by far less obvious. Why
>>> would you care knowing that the energy required to transmit 1 bit is
>>> X over a link L1 and 2*X over a link L2?
>>
>> My first impression: because typical cost metrics are _link_
>> metrics, not node metrics - the hop count is the number of links,
>> not of
>> nodes (a 3 node topology uses a 2 hop count metric - the number of
>> links).
>>
>> More often than not the parameters advertised in Router Advertisements
>> of OSPF and ICMP are link parameters: link MTU, link prefix.
>>
>> It sounds attractive to reuse the same link concept for energy.
>>
>> Prior publications making think link energy is relevant:
>>
>>             Callaway, E., "Secure Low-Power Operation of Wireless
>>             Sensor Networks", Intelligent Systems, January 2004.
>>
>> Mentions transmission of a packet with a particular 15.4 transceiver
>> to
>> be 56 micro-Joules, and is computed relative to the number of bits
>> transmitted.
>>
>>              L. Li, J-Y. Jalpern, ICC'01, Finland., "Minimum-Energy
>>              Mobile Wireless Networks Revisited", June 2001.
>>
>> Explicitely assumes that "a transmission between node u and v takes
>> power p(uv) [...]".
>>
>>              IEEE Global Telecommunications Conference, Globecom '03,
>>              "Measurement and Characterization of Link Quality Metrics
>>              in Energy Constrained Wireless Sensor Networks", 2003.
>>
>> Mentions that the energy to transmit a packet is proportional to
>> 'link inefficiency', and this latter (not the energy) is defined as a
>> metric.
>>
>>> It might very well be that the node connected to L2 has no energy
>>> constraint by contrast with the node connected to L1 being battery
>>> operated.
>>
>> There seems indeed to be a decoupling between the energy left to a
>> node, its battery level, its consumption patterns - and the energy
>> needed to send an MTU-sized packet on a link.
>>
>> They could be both needed, I can't easily say, because the
>> NP-completeness issue: routing according to metric "link-energy" _and_
>> metric "node-energy" may be NP-hard to do.
>>
>> Alex

---

From: JP Vasseur <[email-masked]>
Date: Wed, 20 May 2009 09:44:03 +0200

Hi,

On May 20, 2009, at 9:21 AM, Theodore Zahariadis wrote:

> then the nodes in a fixed path will be exhausted. On the other hand,  
> if energy
> the nodes have a method to create some energy (e.g. a tiny  
> photovoltaic cell,

That was exactly my point. Energy as a NODE metric is a definite MUST.  
I was highly questioning the need
for energy link metric. A link may require x more times energy that  
another link to transmit but if it is connected
to a main power node, then you would certainly favor that link.

As pointed out earlier in a previous email, energy link would in my  
opinion make sense if nodes are homogenous,
which is not our cases, thus my argument for only using node energy  
metric. Makes sense ?

> trust. It seams that even in a trust framework, taking into account  
> energy metrics

Sure. By the way, as general comment do not hesitate to send pointer  
to simulations. Although they cannot be used
to demonstrate that something works, that can provide interesting  
datapoint.

>
> Of course all these apply to homogeneous nodes.

Here it is.

> If the nodes are heterogeneous
> energy of node "a" is less than "x", avoid it, unless it is the node  
> with the maximum

Yes, and we use node energy metrics for that matter.

Thanks.

JP.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 20 May 2009 12:07:22 +0200

JP Vasseur a écrit :
>> Maybe the question could be asked somewhat differently... Maybe 
>> something like: "Is the network survivability a routing protocol 
>> requirement or a feature?" or "Is a routing protocol that can 
>> achieve longer lifetime for the network (as a whole) better than a 
>> protocol that exhausts selectively some nodes?"
>> 
>> If energy is not taken into account and a node has many data to 
>> send, then the nodes in a fixed path will be exhausted. On the 
>> other hand, if energy is a metric, the path will change (maybe it 
>> will not be always the optimal one), but the energy will be reduced
>>  progressively. Moreover, if the nodes have a method to create some
>>  energy (e.g. a tiny photovoltaic cell, or windmill) the network
>> may survive.
> 
> That was exactly my point. Energy as a NODE metric is a definite 
> MUST. I was highly questioning the need for energy link metric. A 
> link may require x more times energy that another link to transmit 
> but if it is connected to a main power node, then you would certainly
>  favor that link.

It's not that obvious, because a link itself is not connected to a
single power supply, it's at least two - one for each node on the link.

What if these 2 supplies are totally different: one is mains 220V the
other is battery cell.  Would the routing protocol still favor that link?

Also the money cost: sending a packet on higher-energy link is
supposedly costlier than sending on a lower-energy link, regardless of
the power supply being a mains supply (220V) or battery cell.

Alex

> opinion make sense if nodes are homogenous, which is not our cases, 
> thus my argument for only using node energy metric. Makes sense ?
> 
>> 
>> We have done a number of simulations in JSIM trying to combine 
>> routing and trust. It seams that even in a trust framework, taking 
>> into account energy metrics may drastically increase the network 
>> lifetime.
> 
> to simulations. Although they cannot be used to demonstrate that 
> something works, that can provide interesting datapoint.
> 
>> 
>> If the nodes are heterogeneous calculating the optimal energy 
>> metric may be too hard (may not worth). On the other hand, there 
>> may be some thresholds put e.g. "if the remaining energy of node 
>> "a" is less than "x", avoid it, unless it is the node with the 
>> maximum energy in the neighborhood".
>> 
> 
>> BR, Theodore
>>> Date: Tue, 19 May 2009 14:38:06 +0200 From: JP Vasseur 
>>> <[email-masked]> Subject: Re: [Roll] DT update -- MUSTs - 
>>> energy for link metric? To: Alexandru Petrescu 
>>> <[email-masked]> Cc: ROLL WG <[email-masked]>, 
>>> [email-masked] Message-ID: 
>>> <[email-masked]> Content-Type: 
>>> text/plain; charset=ISO-8859-1; format=flowed; delsp=yes
>>> 
>>> but again, this does not really answer *the* question: why should
>>>  the routing protocol take link energy into account during path 
>>> computation ?
>>> 
>>>>> Hi Alex, On May 15, 2009, at 8:39 AM, Alexandru Petrescu 
>>>>> wrote:
>>>>>> Tim, thanks for the update - that's hard work. A side 
>>>>>> remark about one particular interest: the req list doesn't
>>>>>>  seem to include a metric for energy of the link: energy 
>>>>>> necessary to send a packet on the link, or energy radiated 
>>>>>> in the air, or similar. Or I can't find it - is there one?
>>>>>>  I do find reqs for energy as constraints of the node 
>>>>>> device: level of energy, energy of the node, power 
>>>>>> available, power budget, etc. Or is the link energy 
>>>>>> completely out of scope?
>>>>> It would be useful to know what the WG thinks about link 
>>>>> energy metrics.
>>>> 
>>>>> Here is my take on it. Node energy metric is undoubtedly 
>>>>> needed, in many cases, one may want to avoid a node that is 
>>>>> battery operated or running our of battery, we are all in 
>>>>> sync with this. Now with regards to link energy metrics, this
>>>>>  is by far less obvious. Why would you care knowing that the 
>>>>> energy required to transmit 1 bit is X over a link L1 and 2*X
>>>>>  over a link L2?
>>>> 
>>>> metrics, not node metrics - the hop count is the number of 
>>>> links, not of nodes (a 3 node topology uses a 2 hop count 
>>>> metric - the number of links).
>>>> 
>>>> More often than not the parameters advertised in Router 
>>>> Advertisements of OSPF and ICMP are link parameters: link MTU, 
>>>> link prefix.
>>>> 
>>>> Callaway, E., "Secure Low-Power Operation of Wireless Sensor 
>>>> Networks", Intelligent Systems, January 2004.
>>>> 
>>>> Mentions transmission of a packet with a particular 15.4 
>>>> transceiver to be 56 micro-Joules, and is computed relative to 
>>>> the number of bits transmitted.
>>>> 
>>>> L. Li, J-Y. Jalpern, ICC'01, Finland., "Minimum-Energy Mobile 
>>>> Wireless Networks Revisited", June 2001.
>>>> 
>>>> Explicitely assumes that "a transmission between node u and v 
>>>> takes power p(uv) [...]".
>>>> 
>>>> "Measurement and Characterization of Link Quality Metrics in 
>>>> Energy Constrained Wireless Sensor Networks", 2003.
>>>> 
>>>> Mentions that the energy to transmit a packet is proportional 
>>>> to 'link inefficiency', and this latter (not the energy) is 
>>>> defined as a metric.
>>>> 
>>>>> It might very well be that the node connected to L2 has no 
>>>>> energy constraint by contrast with the node connected to L1 
>>>>> being battery operated.
>>>> 
>>>> There seems indeed to be a decoupling between the energy left 
>>>> to a node, its battery level, its consumption patterns - and 
>>>> the energy needed to send an MTU-sized packet on a link.
>>>> 
>>>> NP-completeness issue: routing according to metric 
>>>> "link-energy" _and_ metric "node-energy" may be NP-hard to do.
>>>> 
>>>> Alex
>> 
>> 
> 
>

---

From: "Theodore Zahariadis" <[email-masked]>
Date: Wed, 20 May 2009 16:19:04 +0300

Dear Alex,

----- Original Message ----- 
From: "Alexandru Petrescu" <[email-masked]>
To: "JP Vasseur" <[email-masked]>
Cc: "Theodore Zahariadis" <[email-masked]>; 
<[email-masked]>; <[email-masked]>
Sent: Wednesday, May 20, 2009 1:07 PM
Subject: [SPAM] Re: DT update -- MUSTs - energy for link metric? (JP 
Vasseur)

>>> requirement or a feature?" or "Is a routing protocol that can achieve 
>>> longer lifetime for the network (as a whole) better than a protocol that 
>>> exhausts selectively some nodes?"
>>>
>>> energy is a metric, the path will change (maybe it will not be always 
>>> the optimal one), but the energy will be reduced
>> That was exactly my point. Energy as a NODE metric is a definite MUST. I 
>> was highly questioning the need for energy link metric. A link may 
>> require x more times energy that another link to transmit but if it is 
>> connected to a main power node, then you would certainly
>>  favor that link.
>

>From what you say, I think it is definite that energy is a routing 
parameter.
Maybe the function has to be decided (technological, economical, ...) or
it may be a weighted factor (based on the application the weight may
change according to the value that we want to give to the energy metric),
but for sure energy can't be ignored.

BR,
Theodore

>> opinion make sense if nodes are homogenous, which is not our cases, thus 
>> my argument for only using node energy metric. Makes sense ?
>>
>>>
>>> We have done a number of simulations in JSIM trying to combine routing 
>>> and trust. It seams that even in a trust framework, taking into account 
>>> energy metrics may drastically increase the network lifetime.
>>
>> Sure. By the way, as general comment do not hesitate to send pointer to 
>> simulations. Although they cannot be used to demonstrate that something 
>> works, that can provide interesting datapoint.
>>
>>>
>>> If the nodes are heterogeneous calculating the optimal energy metric may 
>>> be too hard (may not worth). On the other hand, there may be some 
>>> thresholds put e.g. "if the remaining energy of node "a" is less than 
>>> "x", avoid it, unless it is the node with the maximum energy in the 
>>> neighborhood".
>>>
>>
>>>> <[email-masked]> Subject: Re: [Roll] DT update -- MUSTs - energy 
>>>> for link metric? To: Alexandru Petrescu <[email-masked]> 
>>>> Cc: ROLL WG <[email-masked]>, [email-masked] Message-ID: 
>>>>>> Hi Alex, On May 15, 2009, at 8:39 AM, Alexandru Petrescu wrote:
>>>>>>> Tim, thanks for the update - that's hard work. A side remark about 
>>>>>>> one particular interest: the req list doesn't
>>>>>>> similar. Or I can't find it - is there one?
>>>>>> regards to link energy metrics, this
>>>>>>  is by far less obvious. Why would you care knowing that the energy 
>>>>>> required to transmit 1 bit is X over a link L1 and 2*X
>>>>>>  over a link L2?
>>>>>
>>>>> My first impression: because typical cost metrics are _link_ metrics, 
>>>>> not node metrics - the hop count is the number of links, not of nodes 
>>>>> (a 3 node topology uses a 2 hop count metric - the number of links).
>>>>>
>>>>> to be 56 micro-Joules, and is computed relative to the number of bits 
>>>>> transmitted.
>>>>>
>>>>> L. Li, J-Y. Jalpern, ICC'01, Finland., "Minimum-Energy Mobile Wireless 
>>>>> Networks Revisited", June 2001.
>>>>>
>>>>> IEEE Global Telecommunications Conference, Globecom '03, "Measurement 
>>>>> and Characterization of Link Quality Metrics in Energy Constrained 
>>>>> Wireless Sensor Networks", 2003.
>>>>>
>>>>> Mentions that the energy to transmit a packet is proportional to 'link 
>>>>> inefficiency', and this latter (not the energy) is defined as a 
>>>>> metric.
>>>>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 20 May 2009 15:55:55 +0200

Theodore Zahariadis a écrit :
> Dear Alex,
> 
> ----- Original Message ----- From: "Alexandru Petrescu" 
> <[email-masked]> To: "JP Vasseur" <[email-masked]> 
> <[email-masked]>; <[email-masked]> Sent: Wednesday, May
> 20, 2009 1:07 PM Subject: [SPAM] Re: DT update -- MUSTs - energy for
> link metric? (JP Vasseur)
> 
> 
>> JP Vasseur a écrit :
>>> Hi,
>>> 
>>>>  something like: "Is the network survivability a routing
>>>> protocol requirement or a feature?" or "Is a routing protocol
>>>> that can achieve longer lifetime for the network (as a whole)
>>>> better than a protocol that exhausts selectively some nodes?"
>>>> 
>>>> other hand, if energy is a metric, the path will change (maybe
>>>> it will not be always the optimal one), but the energy will be
>>>> reduced progressively. Moreover, if the nodes have a method to
>>>> create some energy (e.g. a tiny photovoltaic cell, or windmill)
>>>> the network may survive.
>>> 
>>>  MUST. I was highly questioning the need for energy link metric.
>>> A link may require x more times energy that another link to
>>> transmit but if it is connected to a main power node, then you
>>> would certainly favor that link.
>> 
>> What if these 2 supplies are totally different: one is mains 220V
>> the other is battery cell.  Would the routing protocol still favor
>> that link?
>> 
>> supposedly costlier than sending on a lower-energy link, regardless
>> of the power supply being a mains supply (220V) or battery cell.
> 
> parameter. Maybe the function has to be decided (technological,
> economical, ...) or it may be a weighted factor (based on the
> application the weight may change according to the value that we want
> to give to the energy metric), but for sure energy can't be ignored.

Theodore, I tend to agree energy is a good candidate to make a metric 
for a routing protocol.

Link metric or node metric - that is a question apparently difficult to 
converge on.

Alex

> 
> BR, Theodore
> 
>> 
>> Alex
>> 
>> 
>>> 
>>> As pointed out earlier in a previous email, energy link would in
>>> my opinion make sense if nodes are homogenous, which is not our
>>> cases, thus my argument for only using node energy metric. Makes
>>> sense ?
>>> 
>>>> 
>>>>  routing and trust. It seams that even in a trust framework,
>>>> taking into account energy metrics may drastically increase the
>>>> network lifetime.
>>> 
>>> Sure. By the way, as general comment do not hesitate to send
>>> pointer to simulations. Although they cannot be used to
>>> demonstrate that something works, that can provide interesting
>>> datapoint.
>>> 
>>>> 
>>>> metric may be too hard (may not worth). On the other hand,
>>>> there may be some thresholds put e.g. "if the remaining energy
>>>> of node "a" is less than "x", avoid it, unless it is the node
>>>> with the maximum energy in the neighborhood".
>>>> 
>>> 
>>>>> <[email-masked]>
>>>>> but again, this does not really answer *the* question: why
>>>>> should the routing protocol take link energy into account
>>>>> during path computation ?
>>>>> 
>>>>>>>> remark about one particular interest: the req list
>>>>>>>> doesn't seem to include a metric for energy of the
>>>>>>>> link: energy necessary to send a packet on the link, or
>>>>>>>> energy radiated in the air, or similar. Or I can't find
>>>>>>>> it - is there one? I do find reqs for energy as
>>>>>>>> constraints of the node device: level of energy, energy
>>>>>>>> of the node, power available, power budget, etc. Or is
>>>>>>>> the link energy completely out of scope?
>>>>>>> needed, in many cases, one may want to avoid a node that
>>>>>>> is battery operated or running our of battery, we are all
>>>>>>> in sync with this. Now with regards to link energy
>>>>>>> metrics, this is by far less obvious. Why would you care
>>>>>>> knowing that the energy required to transmit 1 bit is X
>>>>>>> over a link L1 and 2*X over a link L2?
>>>>>> 
>>>>>> My first impression: because typical cost metrics are
>>>>>> _link_ metrics, not node metrics - the hop count is the
>>>>>> number of links, not of nodes (a 3 node topology uses a 2
>>>>>> hop count metric - the number of links).
>>>>>> 
>>>>>> Advertisements of OSPF and ICMP are link parameters: link
>>>>>> MTU, link prefix.
>>>>>> 
>>>>>> transceiver to be 56 micro-Joules, and is computed relative
>>>>>> to the number of bits transmitted.
>>>>>> 
>>>>>> Explicitely assumes that "a transmission between node u and
>>>>>> v takes power p(uv) [...]".
>>>>>> 
>>>>>> Mentions that the energy to transmit a packet is
>>>>>> proportional to 'link inefficiency', and this latter (not
>>>>>> the energy) is defined as a metric.
>>>>>> 
>>>>>>> It might very well be that the node connected to L2 has
>>>>>>> no energy constraint by contrast with the node connected
>>>>>>> to L1 being battery operated.
>>>>>> 
>>>>>> There seems indeed to be a decoupling between the energy
>>>>>> left to a node, its battery level, its consumption patterns
>>>>>> - and the energy needed to send an MTU-sized packet on a
>>>>>> link.
>>>>>>

---

From: Omprakash Gnawali <[email-masked]>
Date: Wed, 20 May 2009 07:24:13 -0700

On Wed, May 20, 2009 at 6:55 AM, Alexandru Petrescu
<[email-masked]> wrote:
>> <[email-masked]> To: "JP Vasseur" <[email-masked]> Cc:
>> "Theodore Zahariadis" <[email-masked]>; <[email-masked]>;
>> <[email-masked]> Sent: Wednesday, May
>>> It's not that obvious, because a link itself is not connected to a single
>>> power supply, it's at least two - one for each node on the
>>> link.
>>>
>>> Also the money cost: sending a packet on higher-energy link is supposedly
>>> costlier than sending on a lower-energy link, regardless
> Theodore, I tend to agree energy is a good candidate to make a metric for a
> routing protocol.
>

We can have both if the two are needed because their purpose would be
different. I have seen work on selecting different link depending on
their energy characteristics in the context of wireless radios (think
cellphones) but not in the context of the type of networks we are
talking about.

- om_p

---

From: JP Vasseur <[email-masked]>
Date: Wed, 20 May 2009 16:37:32 +0200

On May 20, 2009, at 4:24 PM, Omprakash Gnawali wrote:

>>> "Theodore Zahariadis" <[email-masked]>; <[email-masked] 
>>> >;
>>>> supposedly

Well node energy is a MUST we already converged on. Link energy is  
open for discussion.

> different.

Right.

> I have seen work on selecting different link depending on

Same here.

Thanks.

JP.

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

---

From: "Popa, Daniel" <[email-masked]>
Date: Wed, 20 May 2009 11:28:39 -0400

Dear Rollers, 

Accept my apologize if my following remarks may overlap some of previous discussions (I'm quite new with ROLL mailing and didn't follow all the previous discussions). 

I would further bring to the discussion some issues related to node and/or link energy metrics. I think it was Jean-Philippe that cited some works from the state-of-art that links "link energy metric" with the link quality (or link inefficiency) and I believe this is a good way to follow. Indeed, the following situation may often arrive: a (battery powered) node with enough available energy must spend lot of time trying to (re-)transmit (1st transmission + retransmissions at MAC Layer) a packet to its next-hop destination, if the link is heavily lossy and/or congested for some period of time. Conversely, a similar node with a less available power may have a 100% success rate to transmit the same packet, at a first attempt, to its next-hop destination, by using an alternative link/path with a much better quality. 

In addition, for battery powered devices, the power consumed by a (single) packet transmission (energy/bit) at PHY Layer, and for a given signaling rate (PHY bit rate), is in generally optimized to guarantee a long battery life. Therefore, the functioning mode of upper layers (MAC + NET) will greatly impact the energy consumption and thus operation of such layers must be optimized. 

 Taking into account only the node power might be tricky, if a (battery powered) device with enough energy will spent lot of its energy trying to (re-)transmit a packet over a lossy path. Taking into account only the "link energy ~ inefficiency" might also be tricky, as a main power supplied device may have no worry about the energy it spends by attempting to (re-)transmit a packet over a lossy path. 

 Why not defining a hierarchical use of the energy metrics, as a function of their power source:

Type (A) Main power supplied device : metrics (M1, M2, ...) (at least two: M1 = node energy metric; M2 = link energy metric)
Type (B) Battery powered device     : metrics (M1, M2, ....) (at least two: M1 = node energy metric; M2 = link energy metric)

A fast discrimination between battery and non-battery powered devices can be done as a function of (M1) values. If this is not enough, then link energy metric (M2) values can be used to discriminate between multiple paths available via battery powered devices, as well as via main power supplied devices.

Regards, 
Daniel   

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of JP Vasseur
Sent: mercredi 20 mai 2009 16:38
To: Omprakash Gnawali
Cc: [email-masked]
Subject: Re: [Roll] [SPAM] Re: DT update -- MUSTs - energy for link metric?(JP Vasseur)

Right.

Same here.

Thanks.

JP.

---

From: "Theodore Zahariadis" <[email-masked]>
Date: Wed, 20 May 2009 18:46:25 +0300

----- Original Message ----- 
From: "JP Vasseur" <[email-masked]>
To: "Omprakash Gnawali" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, May 20, 2009 5:37 PM
Subject: [SPAM] Re: [Roll] [SPAM] Re: DT update -- MUSTs - energy for link 
metric? (JP Vasseur)

On May 20, 2009, at 4:24 PM, Omprakash Gnawali wrote:

>>> Cc:
>>>> single
>> for a

> Well node energy is a MUST we already converged on. Link energy is  open 
> for discussion.

I agree for the node.

>> We can have both if the two are needed because their purpose would be

I agree.
However, wrt the link energy it may be difficult to be evaluated, leading to
only greedy algorithms. Lets say that we have the following paths:
A->B->D or
A->C->D

Energy at B and C may be known (via beacons?).
Moreover, the energy for links A->B and A->C may be calculated
(though in case A has a single interface they may vary only based on B and 
C).
However, energy for links B->D and C-> is very difficult to be evaluated
(and if the path is longer, practically it can't).

Thus, if the link energy is part of the routing algorithm, only greedy 
algorithms
may be supported.

Best

Theodore

---

From: JP Vasseur <[email-masked]>
Date: Wed, 20 May 2009 17:50:29 +0200

On May 20, 2009, at 5:46 PM, Theodore Zahariadis wrote:

>
> ----- Original Message ----- From: "JP Vasseur" <[email-masked]>
> Subject: [SPAM] Re: [Roll] [SPAM] Re: DT update -- MUSTs - energy  
> for link metric? (JP Vasseur)
>
>
>
>>>> <[email-masked]> To: "JP Vasseur"  <[email-masked] 
>>>> > Cc:

We're in sync.

> (though in case A has a single interface they may vary only based on  
> B and C).
> Thus, if the link energy is part of the routing algorithm, only  
> greedy algorithms
> may be supported.
>

Yes this is exactly why I was mentioning that the metric ID will  
evolve in parrallel with the protocol ID. There are several ways to  
sort this out, but let's see what we all come up with in term of  
protocols. More very soon ...

Cheers.

JP.

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 20 May 2009 09:43:50 -0700

Having it as a link parameter allows for heterogeneous links.  It is also consistent with the way TE parameters have ben handled in GMPLS, even when referring to parameters that are actually associated with the node as a whole, such as server cards.  

> From: Alexandru Petrescu [mailto:[email-masked]] 
> Sent: Wednesday, May 20, 2009 6:56 AM
> To: Theodore Zahariadis
> Cc: [email-masked]
> >>>> energy (e.g. a tiny photovoltaic cell, or windmill) the 
> network may 
> >>>> survive.
> >>> 
> >>> A link may require x more times energy that another link 
> to transmit 
> >>> but if it is connected to a main power node, then you would 
> >>> certainly favor that link.
> >> 
> >> other is battery cell.  Would the routing protocol still 
> favor that 
> >> link?
> >> 
> Theodore, I tend to agree energy is a good candidate to make 
> a metric for a routing protocol.
> 
> Link metric or node metric - that is a question apparently 
> difficult to converge on.
> 
> Alex
> 
> > 
> > BR, Theodore
> > 
> >> 
> >> Alex
> >> 
> >> 
> >>> 
> >>>>>>>> Tim, thanks for the update - that's hard work. A side remark 
> >>>>>>>> about one particular interest: the req list doesn't seem to 
> >>>>>>>> include a metric for energy of the
> >>>>>>>> link: energy necessary to send a packet on the link, 
> or energy 
> >>>>>>>> radiated in the air, or similar. Or I can't find it 
> - is there 
> >>>>>>>> one? I do find reqs for energy as constraints of the node 
> available, 
> >>>>>>>> power budget, etc. Or is the link energy completely out of 
> >>>>>>>> scope?
> >>>>>>> Here is my take on it. Node energy metric is 
> undoubtedly needed, 
> >>>>>>> in many cases, one may want to avoid a node that is battery 
> >>>>>>> operated or running our of battery, we are all in sync with 
> >>>>>>> this. Now with regards to link energy metrics, this is by far 
> >>>>>>> less obvious. Why would you care knowing that the energy 
> >>>>>>> required to transmit 1 bit is X over a link L1 and 2*X over a 
> >>>>>>> link L2?
> >>>>>> 
> >>>>>> not of nodes (a 3 node topology uses a 2 hop count 
> metric - the 
> >>>>>> number of links).
> >>>>>> 
> proportional to 
> >>>>>> 'link inefficiency', and this latter (not the energy) 
> is defined 
> >>>>>> as a metric.
> >>>>>> 
> >>>>>> There seems indeed to be a decoupling between the 
> energy left to 
> >>>>>> a node, its battery level, its consumption patterns
> >>>>>> - and the energy needed to send an MTU-sized packet on a link.
> >>>>>> 
> "link-energy" 
> >>>>>> _and_ metric "node-energy" may be NP-hard to do.
> >>>>>> 
> >>>>>> Alex
> >>>> 
> >>>> 
> >>> 
> >>> 
> >> 
> >> 
> >> 
> >> 
> > 
> > 
> > 
> 
>