Subject: [Roll] Polling WG for adoption of Metrics Draft

From: "David E. Culler" <[email-masked]>
Date: Tue, 24 Mar 2009 12:14:30 -0700

The ROLL charter includes the following work item:
* Specification of routing metrics used in path calculation. This 
includes static and dynamic link/node attributes required for routing in 
LLNs.

The following draft has been submitted and discussed at the ROLL WG 
meeting during IETF 74:
* http://tools.ietf.org/html/draft-mjkim-roll-routing-metrics-03

The consensus at the meeting was that it was ready to WG polling.  I 
would like to poll the WG for adoption of this draft as a WG draft.  
Please respond to the list to establish consensus. 

Also, please provide feedback to the authors on the draft through the list.

Thanks,

  David Culler

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 24 Mar 2009 21:17:55 +0100

IIRC, for energy metrics, I _think_ presenter mentioned that it would be
very difficult to come up with a set of metrics covering all possible
energy metrics.  Which is understandable knowing the wide range of
energy sources available to computing devices.

But at the same time I think it would be valuable if we could come up
with _some_ metrics, about the energy consumption.  The most
straighforward way of metering energy is the way one actually uses in
practice.  These should be documented.

_If_ this document cited below has an intention to document at least a
few metrics, metrics related to energy, in practice - then I'm all for
it.  It currently doesn't document any.

Alex

David E. Culler a écrit :
> The ROLL charter includes the following work item: * Specification of
> routing metrics used in path calculation. This includes static and
> dynamic link/node attributes required for routing in LLNs.
> 
> meeting during IETF 74: *
> http://tools.ietf.org/html/draft-mjkim-roll-routing-metrics-03
> 
>  Please respond to the list to establish consensus. Also, please
> provide feedback to the authors on the draft through the list.
> 
> Thanks,
> 
> David Culler _______________________________________________ Roll
> mailing list [email-masked] https://www.ietf.org/mailman/listinfo/roll
> 
>

---

From: Miguel Sánchez <[email-masked]>
Date: Tue, 24 Mar 2009 22:32:06 +0100

Hi,

The document acknowledges the importance of remaining node energy but
refuses to propose a metric: I do not get it!

I think some energy related metric should be proposed in a revision of
the document if we want routing to be energy aware. Of course we could
end up with just tagging certain nodes as non-forwarders, but I think
we can do better.

However I do not have a detailed propossal at the moment.

Regards,

Miguel Sánchez
Universidad Politecnica de Valencia, Spain

On Tue, Mar 24, 2009 at 8:14 PM, David E. Culler
<[email-masked]> wrote:
> * Specification of routing metrics used in path calculation. This includes static and dynamic link/node attributes required for routing in LLNs.
>
> The following draft has been submitted and discussed at the ROLL WG meeting during IETF 74:
> The consensus at the meeting was that it was ready to WG polling.  I would like to poll the WG for adoption of this draft as a WG draft.  Please respond to the list to establish consensus.
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Kris Pister <[email-masked]>
Date: Wed, 25 Mar 2009 18:00:26 -0700

Miguel - I understand your frustration.  There was in fact a 2 bit (and 
I mean that in both senses of the phrase) discrete metric in the 
document: {UNLIMITED, SCAVENGER, OK, LOW}
I'm not super happy with that list, but it's a step up from "no info".  
Certainly "unlimited" is a good piece of information to know.  
"scavenger" doesn't help all that much unless it tells you something 
about how many packets per second your scavenger can support.  I really 
don't like "OK" and "LOW".
Below are some candidate metrics with more detail.  I've made the 
assumption/recommendation that the node can summarize it's energy in 
terms of packets that it can forward (short packets?  long packets?  
Usually there's an affine relationship between packet length and energy 
consumption), and it's power consumption in units of packets per second.

total remaining packets forwardable -  This would be for a primary 
battery powered node with a limit on total energy.
average packets per second, lifetime - this would be for a primary 
battery powered node with a lifetime constraint, or an energy scavenger 
with a consistent but low power supply.
peak packets per second, short term - this would be for an energy 
scavenger with short-term storage (ultra-cap, rechargeable battery), or 
similarly a low-current primary battery with short-term storage.

Now of course some will say "this is routing - we know nothing of 
packets per second.  Flows are unknowable".  In that case, these metrics 
are close to useless.
For most of the applications in the requirements draft, however, flows 
are well known, and long-term induration, in which case a power-aware 
routing or traffic engineering algorithm can make very good use of this 
information.

ksjp

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 26 Mar 2009 17:22:33 +0100

Hi David,

I'm all for it. 

This work has to slightly precede the routing work that depends on it so
it's fair that the WG gets control over it, and the way to get there is
to make it WG doc.

Pascal

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
David E. Culler
>Sent: mardi 24 mars 2009 12:15
>To: [email-masked]
>Subject: [Roll] Polling WG for adoption of Metrics Draft
>

---

From: Miguel Sánchez <[email-masked]>
Date: Thu, 26 Mar 2009 17:56:37 +0100

Hi Kris,

On Thu, Mar 26, 2009 at 2:00 AM, Kris Pister <[email-masked]> wrote:
> Miguel - I understand your frustration.  There was in fact a 2 bit (and I
> mean that in both senses of the phrase) discrete metric in the document:
> {UNLIMITED, SCAVENGER, OK, LOW}

Let's assume that is the only thing we're going to have (not sure why
we should set with that though). But for a metric to be useful we need
to be able to make comparisons:

I think we could agree that

UNLIMITED > OK > LOW

Not sure where to put SCAVENGER though. I would say it depends on the
current success of the scavenging process.

Even more difficult let's me decide which sub-path is best:

OK --- SCAVENGER --- OK --- LOW

or

OK ----- LOW --- LOW

or

UNLIMITED ---- SCAVENGER ---- OK

(different number of hops is intended).

> Certainly "unlimited" is a good piece of information to know.  "scavenger"
> doesn't help all that much unless it tells you something about how many
> packets per second your scavenger can support.  I really don't like "OK" and
> "LOW".
> assumption/recommendation that the node can summarize it's energy in terms
> of packets that it can forward (short packets?  long packets?  Usually
> there's an affine relationship between packet length and energy
> total remaining packets forwardable -  This would be for a primary battery
> powered node with a limit on total energy.
> average packets per second, lifetime - this would be for a primary battery
> powered node with a lifetime constraint, or an energy scavenger with a
> consistent but low power supply.
> peak packets per second, short term - this would be for an energy scavenger
> with short-term storage (ultra-cap, rechargeable battery), or similarly a
> low-current primary battery with short-term storage.
>

I do like these much more.

For a given path, like in a chain, the expected path lifetime is the
one of the weakest link.  Given a numeric value of links metric
routing algorithm would chose the lowest min of each alternative and,
given a tie, the one with less hops. But still we'd need a numeric
value for that.

My proposal is for you to consider a few more bits for energy
reporting (now we have 2 bits only). At any rate "unlimited" is always
going to be a value (maximum) , and "forbidden" should also be another
(minimum or zero) preventing any forwarding at all.

Whether energy comes from a battery, solar panel or other source only
matters when you take into account that some energy sources are
"renewable" (ie. a low energy value today can increase after sunrise).
However, battery operated equipment can also get the energy source
replaced and thus increasing the available energy at the node too.
(The latter requiring a human operator). I say this because much
emphasis seems to be put to highlight the energy scavenging process
and I am not sure that detail needs to be taken care of as part of the
energy metric in ROLL.

> Now of course some will say "this is routing - we know nothing of packets
> per second.  Flows are unknowable".  In that case, these metrics are close
> to useless.

> For most of the applications in the requirements draft, however, flows are
> well known, and long-term induration, in which case a power-aware routing or
> traffic engineering algorithm can make very good use of this information.
>
> ksjp
>
Kind regards,

Miguel Sánchez

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 26 Mar 2009 22:10:48 +0100

Kris Pister a écrit :
[...]
>  Usually there's an affine relationship between packet length and
> energy consumption), and it's power consumption in units of packets
> per second.

Energy akin to MTU?

For a particular link, energy representation for a link as MTU.  This
computer's interface needs x Watts to send a typical 1280byte IPv6 
packet and y Watts to receive such.

(Watt and not Joule for this case).

These x and y figures are usually the same for all interfaces attached
to that link, independent of computer - a server would spend same
amount of energy to send that packet on that link, as a micro-controller
on a PDA.

Which would give to represent energy in the RA, as MTU is.

Alex

---

From: Zach Shelby <[email-masked]>
Date: Fri, 27 Mar 2009 08:52:14 +0200

Ditto, it has my support as well.

- Zach

-- 
http://zachshelby.org - My blog “On the Internet of Things”
Mobile: +358 40 7796297

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

This e-mail and all attached material are confidential and may contain 
legally privileged information. If you are not the intended recipient, 
please contact the sender and delete the e-mail from your system without 
producing, distributing or retaining copies thereof.

---

From: Zach Shelby <[email-masked]>
Date: Fri, 27 Mar 2009 08:52:28 +0200

- Zach

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 27 Mar 2009 00:03:06 -0700

The document has my support.
Thomas