Subject: [Roll] ROLL Routing Metrics - WF feed-back needed

From: JP Vasseur <[email-masked]>
Date: Tue, 21 Oct 2008 07:14:19 +0200

Dear WG,

As you know, routing metrics for LLN are part of our WG charter.
draft-mjkim-roll-routing-metrics-01 is a first draft attempting to list a
set of link and node metrics candidates. We intentionally left a wide set of
metrics of various nature: link/node, static/dynamic, ...

We of course have to be quite careful here: defining metrics is one thing,
determining what to do and how to make a careful use of it is the hard part.
There is a number of notorious examples where metrics have been defined but
have never been used simply for a number of reasons:
1. Computing an aggregated metric as a polynomial function of a set of
metrics is too difficult to operate,
2. Use of a set of attributes as hierarchical constraints implies heavy
policy configuration,
3. Use of dynamic metrics was the source of routing oscillations (e.g.
ARPANET) 
4. ....

So we would need your feed-back, bearing in mind that we may want to only
keep the metrics that are critical to LLNs.

Waiting for your comments ...

Thanks.

JP and Kim.
_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: "Miguel Sanchez" <[email-masked]>
Date: Wed, 29 Oct 2008 11:59:20 +0100

> So we would need your feed-back, bearing in mind that we may want to only keep the metrics that are critical to LLNs.
>

Not sure what is the best way but being able to use remaining-energy
as a parameter for routing decisions maybe useful (if routing
contemplates that). Remaining node energy may be added to other
metrics (delay, traffic, PER, etc).

Cheers,

Miguel Sánchez
Universidad Politécnica de Valencia, Spain
_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Wed, 29 Oct 2008 09:54:25 -0400

I absolutely agree with using remaining-energy. Would also 
suggest bandwidth on the link (current and maximum), BER,
and latency.

Regards,
Stan 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Miguel Sanchez
Sent: Wednesday, October 29, 2008 6:59 AM
To: ROLL WG
Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed

Cheers,

Miguel Sánchez

---

From: JP Vasseur <[email-masked]>
Date: Thu, 30 Oct 2008 08:29:42 +0100

Hi,

> suggest bandwidth on the link (current and maximum), BER,

All currently defined also.

Still I think that we need to think a bit more about this. I personally
question whether we need these metrics or not. Designing a routing protocols
with so many dynamic metric is not trivial.

For the sake of illustration propagation delay may greatly vary if queueing
delays are taken into account. So does the bandwidth.

Thus we do need to make sure that we do not end up with a wide set of
dynamic metrics that will unavoidably lead to routing instabilities.

Other comments from the WG ?

Thanks.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Thu, 30 Oct 2008 08:29:44 +0100

Good since the node energy metric is already captured in the document
(Section 4.2). We will still have to define how often such metrics may be
changed.

Thanks

JP.

---

From: "Mischa Dohler" <[email-masked]>
Date: Thu, 30 Oct 2008 08:43:22 +0100

Hola Miguel, JP, all,

They are all already either implicitly or explicitly part of the specs. If
we start thinking however which one to explicitly include and which to
exclude, remaining energy is definitely a vital metric.

Mischa.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of JP
Vasseur
Sent: Thursday, October 30, 2008 8:30 AM
To: Stan Ratliff (sratliff); Miguel Sanchez; ROLL WG
Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed

Hi,

Thanks.

JP.

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Miguel
> Sanchez

---

From: JP Vasseur <[email-masked]>
Date: Thu, 30 Oct 2008 08:55:54 +0100

Good, feel free to comment on other metrics, we need to make a careful
decision on which one we keep, remove, add, ...

Thanks for the comments.

JP.

---

From: "Miguel Sanchez" <[email-masked]>
Date: Thu, 30 Oct 2008 09:29:04 +0100

I've got a terminology problem with "propagation delay" (5.3), while
defined in the draft (and later defined is path propagation) a new
meaning is given to the term. (For short range communications
transmission time could be used instead).

Regarding the energy metric I can see a problem if only one value is
given (ie: remaining enery). The value might be infinite to signal
nodes without energy restrictions, but for the remaining nodes, a
single value may not be enough. Let me elaborate on this with an
example: A node may have an overall lower consumption than another
one. If the former has slightly less energy than the second one, then
choosing the later may not be the best choice for long term
survivability of the network (this could be addressed by advertising
expected node lifetime instead of node's remaining energy).

 On the other hand, without knowing the initial energy, it's not
possible to know what fraction of the original energy is the remaining
one. This could be addressesed advertising remaining energy as a
percentage (contrary to the above paragraph approach).

And last, in certain network setups some nodes may be easy to replace
while others are not. You may want batteries to die out more often on
nodes that can have their batteries replaced easily even though other
nearby nodes have more energy available. Energy metric need to be
complemented with other metrics. (Network survivability is not the
only factor we have to take into account).

Regards,

Miguel Sánchez

---

From: "Eunsook \"Eunah\" Kim" <[email-masked]>
Date: Thu, 30 Oct 2008 17:40:08 +0900

IMHO, we need to think this work *with* protocol design, not *before*.
We can come up with "we need energy metrics, link quality metrics, etc"
However, we should think how to implement the metrics, as this work is
in standard track.
In my expectation, this work should include more than a list of metrics,
and it is not easy for me to think of metrics without protocols.
Please let me know if i need to see in other way.

Thanks,
-eunah

---

From: "Mischa Dohler" <[email-masked]>
Date: Thu, 30 Oct 2008 09:35:36 +0100

Miguel, the absolute energy value if advertised frequently enough or the
absolute energy and its first order time derivative if advertised
once/infrequently should suffice. These values can reflect the real energy
budget or some virtual one. The latter is useful for cases as you outlined
below where some nodes may wish to pretend to lack energy because changing
battery is a hassle. Mischa. (PS: An interesting route setup procedure had
been proposed by Bachir et al, where the response to the request is delayed
in each node by an amount which is inversely proportional to the remaining
energy, automatically stipulating the route with highest energy to be
chosen. Other metrics could of course also be incorporated into this
approach.)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Miguel Sanchez
Sent: Thursday, October 30, 2008 9:29 AM
To: JP Vasseur
Cc: [email-masked]; Stan Ratliff (sratliff); ROLL WG
Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed

Regards,

Miguel Sánchez

>> From: [email-masked] [mailto:[email-masked]] On Behalf Of
JP

---

From: JP Vasseur <[email-masked]>
Date: Thu, 30 Oct 2008 09:52:17 +0100

Hi Eunah,

Thanks for your comments.

> Please let me know if i need to see in other way.

You may want to ;-) I agree with you that there is of course a relationship
between the protocol and the metrics. That being said, there is no reason
why we should not specify the metrics to be used by the routing protocol.
Can't we answer to the question "do we need to have the link bandwidth, BER,
... As routing metrics ?".

And we need to be cautious not to define a large set of dynamic metrics that
we won't be able to use in a routing protocols. Some metrics will be used as
constraints, others will be used as metrics. One can define weighted
function to compute the path cost using a set of metrics but clearly history
shows that such functions are not really usable. This is the debate that we
need to have right now.

Thoughts ?

Thanks.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Thu, 30 Oct 2008 10:02:12 +0100

Hi Miguel,

> transmission time could be used instead).

Let me make sure that I get your point here. The document says:
"Propagation delay is the time taken for the packet to traverse the
link from the source node to the target node."

I think that the notion of source and target node is confusing and the text
should read:

" Propagation delay is the time taken for the packet to traverse the
link. "

Does that clarify ?

> expected node lifetime instead of node's remaining energy).

Absolutely. The remaining energy metric may be difficult to interpret and
the expected lifetime may be hard to compute.

> percentage (contrary to the above paragraph approach).

Yes or ... We may use a simple multi-threshold mechanisms: "Low, Medium,
High" where:
"LOW: avoid this node if possible"
"Medium: no particular constraint"
"HIGH: favor this node"

Avoid/favor should of course be interpreted in the context of energy.

What do you think ?

But ... In any case, we need to avoid the definition of metric that are
implementation/node dependent. The way you model energy cannot be
standardized.

We also need to ensure that nodes use consistent metrics (a fairly common
problem).

> nearby nodes have more energy available.

Absolutely, as defined in the industrial routing requirement document. This
should be an administrative constraint.

Energy metric need to be
> only factor we have to take into account).

Right. Did you have a look at the other ones ?

Thanks.

JP.

---

From: "MiJeom Kim" <[email-masked]>
Date: Thu, 30 Oct 2008 18:11:25 +0900

Hi, all,

I also agree on all of your comments. One thing I want to make it clear, the
document specifies node latency (4.4) and propagation delay (5.3). I believe
node latency is regarding time delay at node and propagation delay is one at
link. So, queuing delay is comprised in node latency, I think.

Thanks,

Mijeom.

---

From: JP Vasseur <[email-masked]>
Date: Thu, 30 Oct 2008 11:05:21 +0100

Hi,

Indeed and I must say that I am a bit skeptical about the use of node
latency, queueing delays, ... Considering the speed at which such metrics
tend to change. As as matter of fact this was an issue found in the ARPANET.
We could use low pass filter but then the relevance of such metrics is
questionable ...

JP.

---

From: "Miguel Sanchez" <[email-masked]>
Date: Thu, 30 Oct 2008 11:56:36 +0100

Hi JP,

> link from the source node to the target node."

Definition is clear enough but what bothers me is that "propagation
delay" equals link length over propagation speed in my book.
Apparently the meaning here is more like transmission time +
propagation delay (the latter as I've defined here).
> " Propagation delay is the time taken for the packet to traverse the

Do you mean including the transmission time?

> Avoid/favor should of course be interpreted in the context of energy.
I think the high/medium/low approach may hurt some implementations
over a numerical value (i.e: choosing between two nodes with high
value).
> implementation/node dependent. The way you model energy cannot be

We've to find a way to create an standard way for energy reporting. Haven't we?

> Right. Did you have a look at the other ones ?
I mostly agree with the rest, perhaps I'd chose PER (packet error
rate) metric instead of BER.

Regards,

Miguel Sánchez

---

From: JP Vasseur <[email-masked]>
Date: Thu, 30 Oct 2008 12:30:22 +0100

Hi Miguel,

> propagation delay (the latter as I've defined here).

Ah I see what you mean, it is w/o transmission delay (just propagation
delay). We'll clarify.

> over a numerical value (i.e: choosing between two nodes with high

But that may be "good" enough ... The issue with a numeric value is that it
will be really hard to define a consistent way to compute the value *and*
will be hard to use by the computation engine.

Agree ?

> We've to find a way to create an standard way for energy reporting. Haven't

Heu ... You may want to try ... But certainly not trivial.

> rate) metric instead of BER.

One problem though: the PER of a function of packet size and can be computed
knowing the BER anyway.

Agree ?

Thanks.

JP.

---

From: Kris Pister <[email-masked]>
Date: Thu, 30 Oct 2008 09:33:51 -0700

I agree with Miguel that we need a standard way of energy reporting, and 
I agree with JP that it's hard to do.
Part of the challenge is that energy sources and storage vary so much.  
We have:
 * line power - great if you can get it!
 * battery storage
      - this is time varying.  The available energy in a battery is a 
strong function of the temperature and the usage profile.  So a battery 
powered mote may correctly calculate five years of lifetime in summer, 
and then that winter under the exact same load conditions it may 
correctly calculate a lifetime of ten years.  The same mote with the 
same battery may have better performance in summer at higher loads.
 * capacitive storage
 * energy scavenging
      - this is time varying, and tough to bound (usefully

All of this makes energy/power/lifetime reporting painful, yet I can not 
picture a successful routing protocol that doesn't somehow take these 
factors into account.

What we did in HART was have a mote report:
1) whether it's line, battery, or battery/cap+scavenger powered
2) it's expected lifetime at the current load
3) it's peak packet rate (e.g. scavenging limited)
4) how long it can last at that rate (e.g. storage limit)
5) how long it takes to recover once storage is exhausted

The peak packet rate provides a mechanism for the application to require 
a given lifetime from the battery, which is another important 
consideration, as others have mentioned.

It's not perfect, but it's good enough to let the routing algorithm make 
rational decisions, such as {energy, power, lifetime}-aware load 
balancing, etc.

ksjp

---

From: Kris Pister <[email-masked]>
Date: Thu, 30 Oct 2008 09:40:06 -0700

>>  One problem though: the PER of a function of packet size and can be 
computed

Actually no.  PER in LLNs is generally not a simple function of BER or 
packet size.  This is due to external interference and multipath 
fading.  A minor point perhaps, but one that often surprises people who 
are used to more traditional networks.

ksjp

---

From: JP Vasseur <[email-masked]>
Date: Thu, 30 Oct 2008 18:33:40 +0100

PER if a function of BER along with other parameters of course (for a given
BER the PER varies with packet size).

---

From: Kris Pister <[email-masked]>
Date: Thu, 30 Oct 2008 11:54:06 -0700

JP, I realize that this is probably a minor point, but you're not 
getting it.  For low power radio systems, BER, PER, and packet size are 
often related to each other in very weird ways.  Saying that for a given 
BER the PER varies with packet size is just not true.
Example:
A poorly-sealed microwave oven can knock out roughly 8 of every 17 ms on 
some channels in the 2.4GHz band.  For a single-channel system with 
short packets, that will give me a BER of 50%, and a PER that is almost 
independent of packet size.

ksjp

JP Vasseur wrote:
>>>>  One problem though: the PER of a function of packet size and can be
>>>>         
>> computed
>>     
>>>> knowing the BER anyway.
>>>>

---

From: Philip Levis <[email-masked]>
Date: Thu, 30 Oct 2008 12:33:03 -0700

On Oct 30, 2008, at 11:54 AM, Kris Pister wrote:

> getting it.  For low power radio systems, BER, PER, and packet size  
> are often related to each other in very weird ways.  Saying that for  
> a given BER the PER varies with packet size is just not true.
> Example:
> A poorly-sealed microwave oven can knock out roughly 8 of every 17  
> ms on some channels in the 2.4GHz band.  For a single-channel system  
> with short packets, that will give me a BER of 50%, and a PER that  
> is almost independent of packet size.

Agreed. The direct correspondence is for theoretical formulations that  
make assumptions of uniformity and independence which are not true in  
practice. They are valuable in that they tell you about SNR/BER/PER,  
but the real world adds additional complexity that is very difficult  
(read: not worth it) to formalize.

Phil

---

From: "MiJeom Kim" <[email-masked]>
Date: Fri, 31 Oct 2008 13:55:56 +0900

Hi, Miguel,

As I pointed out in my early posting, "Propagation delay" is just time a
packet to traverse a link. So it doesn't include transmission time. On the
other hand, node latency comprises transmission time, packet processing time
and queuing delay in section 4.4. In section 5.3, path latency = propagation
delay of all links + node latency of all nodes along the path. Since
propagation delay is negligible as Philip wrote and it's hard to get its
value, we might exclude the propagation delay from routing metrics. Need
more opinions.

Regarding the energy metric, I believe that there is a trade-off between
multi-threshold approaches and using numerical values. But, for practical
solutions, we might need to compromise precision by choosing multi-threshold
mechanisms.

Thanks,
Mijeom.

---

From: "Miguel Sanchez" <[email-masked]>
Date: Fri, 31 Oct 2008 09:19:41 +0100

Hi Mijeom,

> packet to traverse a link. So it doesn't include transmission time. On the

Ok, I see, from the current wording I was not sure whether
transmission time was included or not.

> solutions, we might need to compromise precision by choosing multi-threshold

The number of bits used for encoding energy information seems like an
implementation issue to me.

Thanks,

Miguel
>
> Thanks,
> Mijeom.
>
>
>
> -----원본 메시지-----
> 보낸 사람: "Miguel Sanchez" <[email-masked]>
> 보낸 날짜: 2008-10-30 오후 7:56:36
> 받는 사람: "JP Vasseur" <[email-masked]>
> 참조: "ROLL WG" <[email-masked]>
> 제목: Re: [Roll] ROLL Routing Metrics - WF feed-back needed
>
> Hi JP,
>
> Miguel Sanchez
>>> Miguel Sanchez
>>>>> They are all already either implicitly or explicitly part of the
>>>>> specs.. If
>>>>>> Miguel Sanchez
>>>>>> Universidad Politecnica de Valencia, Spain

---

From: "MiJeom Kim" <[email-masked]>
Date: Fri, 31 Oct 2008 18:04:52 +0900

Hi, Ksjp,

Thank you for the information. It seems pretty good even though it requires
quite a few variables to be calcuated. I believe those are the minimum to
get meaningful metrics.

Mijeom.

On Fri, Oct 31, 2008 at 1:33 AM, Kris Pister <[email-masked]>wrote:

> I agree with Miguel that we need a standard way of energy reporting, and I
> agree with JP that it's hard to do.
> Part of the challenge is that energy sources and storage vary so much.  We
> have:
> powered mote may correctly calculate five years of lifetime in summer, and
> then that winter under the exact same load conditions it may correctly
> calculate a lifetime of ten years.  The same mote with the same battery may
> have better performance in summer at higher loads.
>  * capacitive storage
>  * energy scavenging
> The peak packet rate provides a mechanism for the application to require a
> given lifetime from the battery, which is another important consideration,
> as others have mentioned.
>
> rational decisions, such as {energy, power, lifetime}-aware load balancing,
> etc.
>
> ksjp
>
>
>
>

---

From: JP Vasseur <[email-masked]>
Date: Fri, 31 Oct 2008 12:14:02 +0100

Hi Kris,

On 10/30/08 5:33 PM, "Kris Pister" <[email-masked]> wrote:

>       - this is time varying.  The available energy in a battery is a strong
> function of the temperature and the usage profile.  So a battery powered mote
> may correctly calculate five years of lifetime in summer, and then that winter
> under the exact same load conditions it may correctly calculate a lifetime of
> ten years.  The same mote with the same battery may have better performance in
> summer at higher loads.
> 
> JP> and usage profile may also change.
> 
>  * capacitive storage
>  * energy scavenging
> JP> this is why I¹m questioning the usefulness of knowing the remaining energy
> expressed in Joules or other metrics. Knowing this value will not tell you
> anything as to whether you should or should not use that node when computing
> the path. Another metric may be the remaining estimated lifetime but still, is
> the node capable (without consuming too much energy) of gathering historical
> data etc ... to provide an accurate value hoping that other criterion such as
> usage profile or temperature as you pointed out will not change ?
> 
> picture a successful routing protocol that doesn't somehow take these factors
> into account.
> 
> JP> This is fine (static node property).
> 
> given lifetime from the battery, which is another important consideration, as
> others have mentioned.
> 
> JP> What can be done then is: to specify a simple flag based mechanism as a
> MUST routing metric and optionally specify other parameters as the one above
> as long as we can also specify how to compute them (also difficult).
> 
> We also need to bear in mind that the collection of such a variety of metrics
> is easier when using central computation engine, much more problematic in
> distributed environments since the nodes may not all have enough CPU/Energy to
> taken them all into consideration (and store all metrics !).
> 
> A good discussion topic for Minneapolis ?
> 
> Cheers.
> 
> JP.
> 
> 
> 
> ksjp
> 
> JP Vasseur wrote:
>>  
>> Hi Miguel,
>> 
>> 
>> On 10/30/08 11:56 AM, "Miguel Sanchez" <[email-masked]>
>> <mailto:[email-masked]>  wrote:
>> 
>>   
>>  
>>>  
>>> Hi JP,
>>> 
>>> On Thu, Oct 30, 2008 at 10:02 AM, JP Vasseur <[email-masked]>
>>> <mailto:[email-masked]>  wrote:
>>>     
>>>  
>>>>  
>>>> Hi Miguel,
>>>> 
>>>> 
>>>> On 10/30/08 9:29 AM, "Miguel Sanchez" <[email-masked]>
>>>> <mailto:[email-masked]>  wrote:
>>>> 
>>>>       
>>>>  
>>>>>  
>>>>> On Thu, Oct 30, 2008 at 8:55 AM, JP Vasseur <[email-masked]>
>>>>> <mailto:[email-masked]>  wrote:
>>>>>         
>>>>>  
>>>>>>  
>>>>>> On 10/30/08 8:43 AM, "Mischa Dohler" <[email-masked]>
>>>>>> <mailto:[email-masked]>  wrote:
>>>>>> 
>>>>>>           
>>>>>>  
>>>>>>>  
>>>>>>> Hola Miguel, JP, all,
>>>>>>> 
>>>>>>> On 10/29/08 2:54 PM, "Stan Ratliff (sratliff)" <[email-masked]>
>>>>>>> <mailto:[email-masked]>  wrote:
>>>>>>> 
>>>>>>>            
>>>>>>>  

 
Regards,
Stan

-----Original Message-----

Sanchez

 
So we would need your feed-back, bearing in mind that we may want to
only
keep the metrics that are critical to LLNs.

 

Cheers,

Miguel Sánchez

---

From: JP Vasseur <[email-masked]>
Date: Fri, 31 Oct 2008 12:22:10 +0100

Thanks for the note. The point that I was trying to make was that the BER
and the packet size had of course an effect on the PER but as you pointed
out there is no simple equation providing the PER as a direct function of
BER and packet size! Furthermore, the hypothesis of uniform error
distribution is usually not true, etc.

Cheers,

JP.

On 10/30/08 7:54 PM, "Kris Pister" <[email-masked]> wrote:

> JP, I realize that this is probably a minor point, but you're not getting it.
> For low power radio systems, BER, PER, and packet size are often related to
> each other in very weird ways.  Saying that for a given BER the PER varies
> with packet size is just not true.
> Example:
> A poorly-sealed microwave oven can knock out roughly 8 of every 17 ms on some
> channels in the 2.4GHz band.  For a single-channel system with short packets,
> that will give me a BER of 50%, and a PER that is almost independent of packet
> size.
> 
> ksjp
> 
> JP Vasseur wrote:
>>  
>> On 10/30/08 5:40 PM, "Kris Pister" <[email-masked]>
>> <mailto:[email-masked]>  wrote:
>> 
>>   
>>  
>>>  
>>> JP Vasseur wrote:
>>>     
>>>  
>>>>  
>>>>>

---

From: "Miguel Sanchez" <[email-masked]>
Date: Fri, 31 Oct 2008 12:24:45 +0100

Hi JP,

On Fri, Oct 31, 2008 at 12:14 PM, JP Vasseur <[email-masked]> wrote:
> function of the temperature and the usage profile.  So a battery powered
> mote may correctly calculate five years of lifetime in summer, and then that
> winter under the exact same load conditions it may correctly calculate a
> lifetime of ten years.  The same mote with the same battery may have better
> performance in summer at higher loads.
>
> JP> this is why I'm questioning the usefulness of knowing the remaining
> energy expressed in Joules or other metrics. Knowing this value will not
> tell you anything as to whether you should or should not use that node when
> computing the path. Another metric may be the remaining estimated lifetime

I disagree.

At least if remaining energy is infinitum (mains powered) tells you something.

OTOH, if limited, depending on other properties of the nodes (like
where it gets its energy from) it is also useful for making routing
decisions too.

> but still, is the node capable (without consuming too much energy) of
> gathering historical data etc ... to provide an accurate value hoping that
> other criterion such as usage profile or temperature as you pointed out will
> not change ?
>

Kind regards,

Miguel

---

From: JP Vasseur <[email-masked]>
Date: Fri, 31 Oct 2008 12:27:27 +0100

Agree.

A good time to ask the question to the WG.

Do you think that we need to specify node latency as a metric ? Note that
this mean: queueuing delays (per link) and processing time (per node).

ps: I’m personally very skeptical about using such varying metrics ... W/o
high risk of routing oscillations, or we need very carefully designed
threshold-based mechanisms certainly no dynamic metrics reflecting “real
time” values.

Thanks.

JP.

On 10/31/08 5:18 AM, "김미점[USN연구담당]" <[email-masked]> wrote:

> value, we might exclude the propagation delay from routing metrics. Need more
> opinions.
>  
>>>>> wrote:

---

From: JP Vasseur <[email-masked]>
Date: Fri, 31 Oct 2008 12:33:10 +0100

Hi Miguel,

> where it gets its energy from) it is also useful for making routing

OK let's try to step back. I'm proposing a flag-based mechanism to avoid the
use of a node should this node run out of energy. The decision to set the
flag is made by the node (no specified) according to many parameters
(estimated like time, ... Etc). Some nodes having more power may make use of
complex models.

If you advertise your remaining power in Joules, how would you expect the
nodes to change their routing decisions since they have no idea of whether
you are running low in energy (it highly depends on what the node does, the
external conditions, ... Etc) ?

Thanks.

JP.

---

From: "Miguel Sanchez" <[email-masked]>
Date: Fri, 31 Oct 2008 12:49:22 +0100

Hi JP,

> external conditions, ... Etc) ?

Please note that my propossal is to advertise both, remaining energy
in absolute value (ie. Joules) plus a relative value (ie. percentage).
Just absolute value is only useful if infinite (ie. mains-powered
nodes). So I think we agree on this.

Cheers,

Miguel

---

From: Philip Levis <[email-masked]>
Date: Fri, 31 Oct 2008 09:20:22 -0700

On Oct 31, 2008, at 4:27 AM, JP Vasseur wrote:

> Do you think that we need to specify node latency as a metric ? Note  
> that this mean: queueuing delays (per link) and processing time (per  
> node).
>
> ps: I’m personally very skeptical about using such varying  
> metrics ... W/o high risk of routing oscillations, or we need very  
> carefully designed threshold-based mechanisms certainly no dynamic  
> metrics reflecting “real time” values.

Node latency -- the time that passes between packet reception and  
packet transmission -- can be important but not for either queueing  
delay or processing time. Rather, node latency can be important if  
there is some kind of underlying scheduling. Or would you consider  
this queueing delay? Note that it can differ greatly depending on  
which node is the next hop.

Phil

---

From: JP Vasseur <[email-masked]>
Date: Fri, 31 Oct 2008 17:50:13 +0100

Hi,

On 10/31/08 5:20 PM, "Philip Levis" <[email-masked]> wrote:

>> ps: I¹m personally very skeptical about using such varying
>> metrics reflecting ³real time² values.
> 
> this queueing delay?

It does depends on the nature of the nodes, applications running in the
network, ... Etc. By "underlying scheduling" are you referring to the OS
scheduler or L2 scheduling ?

Note that it can differ greatly depending on
> which node is the next hop.

In any case, I think that *the* question is: do we want the protocols to use
such link and node metrics in routing decisions ?

Cheers.
JP.

---

From: JP Vasseur <[email-masked]>
Date: Fri, 31 Oct 2008 18:00:44 +0100

Hi Phil,

On 10/31/08 5:20 PM, "Philip Levis" <[email-masked]> wrote:

> delay or processing time.

That depends ... On the type of nodes, traffic type, ... Etc.

Rather, node latency can be important if
> there is some kind of underlying scheduling. Or would you consider

By "underlying scheduling" are you referring to the OS scheduler or the L2
scheduling ?

> which node is the next hop.

But before we start to look at all components, I think that *the* question
is whether we want the routing protocol to take into account such highly
variable node and link metrics ?

Thanks.

JP.