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

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 13 May 2009 15:00:25 +0200

Kris Pister a écrit :
> 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}

This ^ is too poor representation of what is energy, too little 
resolution, too small range of values.

It wouldn't allow for fine grain decision in large networks.  Compare it 
to the IP metric cost which has at least 15 values (RIP).

Besides, what does 'SCAVENGER' mean in this context?  IS this a manual 
dynamo or something?

Is there an ordering relationship? (UNLIMITED larger than SCAVENGER 
larger than OK larger than LOW)?  It's not obvious...

Alex

> 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
> 
> Miguel Sánchez wrote:
>> 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:
>>   
>>> 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
>>> _______________________________________________
>>> Roll mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/roll
>>>     
>> _______________________________________________
>> Roll mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/roll
>>   
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Omprakash Gnawali <[email-masked]>
Date: Wed, 13 May 2009 09:50:01 -0700

On Wed, May 13, 2009 at 6:00 AM, Alexandru Petrescu
<[email-masked]> wrote:
> Kris Pister a écrit :
>>
>> 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}
>
> This ^ is too poor representation of what is energy, too little resolution,
> too small range of values.
>
> It wouldn't allow for fine grain decision in large networks.  Compare it to
> the IP metric cost which has at least 15 values (RIP).
>
> Is there an ordering relationship? (UNLIMITED larger than SCAVENGER larger
> than OK larger than LOW)?  It's not obvious...

Regarding the energy metric, it would be helpful to know if there are
successful routing protocols (little bit more than simulation-only
papers) that take energy into account. What does their energy
representation look like? What shortcomings do they have that we are
trying to improve on here? If there are already lots of non-standard
LLNs with proprietary protocols, and if energy is a useful metric,
perhaps they already use it? Some context information such as that
would help the WG understand if we are trying to standardize what is
already done or if we are trying to do new research.

- om_p

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 13 May 2009 21:47:38 +0200

Omprakash Gnawali a écrit :
>>> 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}
>> It wouldn't allow for fine grain decision in large networks. 
>> Compare it to the IP metric cost which has at least 15 values 
>> (RIP).
>> 
>> Besides, what does 'SCAVENGER' mean in this context?  IS this a 
>> manual dynamo or something?
>> 
> representation look like?

On my side, I can say about some chipsets reporting battery levels, in
mili-Volt, and micro-Ampère.  I havent'seen one hardware report in
Joule.  I've seen cards reporting dBm and RSSI.  This is not an argument
against Joule.

Also performed theoretical calculations for 1280byte sized packets on
WiFi brandname 100mWatt power is 19 micro-Joules.  Also assisted at
measurements with ampermeters serially connected on battery of emitting 
devices.

I am interested in any hands-on report helping evaluate how much Joules
does it take to send an 1280-byte packet on a wireless link.

> What shortcomings do they have that we are trying to improve on here?

I think the most important is to come up with a common - read agreed -
means to represent Energy.  Be it for node or for links.

> If there are already lots of non-standard LLNs with proprietary 
> protocols, and if energy is a useful metric, perhaps they already use
>  it?

Yes, I am interested to learn this.

> Some context information such as that would help the WG understand if
> we are trying to standardize what is already done or if we are trying
> to do new research.

I agree.

Alex

---

From: Kris Pister <[email-masked]>
Date: Mon, 18 May 2009 19:19:21 -0700

The wireless HART standard allows for power aware routing.  HART nodes 
specify their power-related information when they join a network, and 
report energy consumption on a regular basis, to a centralized network 
manager.  MPLS people might call this manager a Path Computation 
Engine.  In these networks, basically all routing decisions are made by 
the PCE and pushed to the nodes.  This is somewhat similar to what HYDRO 
does for peer-to-peer routes.
Applications request services (packet flows between endpoints, with rate 
and latency requirements and duration), and the PCE determines if it can 
provide the requested service with sufficient redundancy to meet 
reliability requirements, while respecting the power-related 
restrictions of the nodes along the route.  If it can, the route is 
installed, all routers along the path have their Layer2 links 
provisioned to meet the flow requirements, and the application gets a 
handle (basically a flow label) to use for any packets sent on that flow.

The info that the node reports at join includes
* peak tx rate [133 byte packets/s]
* maximum lifetime at the peak rate [s]
* recovery time [s]

These were chosen to cover at least the four different cases that we 
could think of:
line powered, energy-scavenging, peak-power-limited, total-energy limited

For line-powered devices, the peak rate is a function only of the 
phy/mac.  In the case of HART, this is one 133 byte (max total for 
802.15.4) packet every 10ms.  Max lifetime at this rate is INF, recovery 
time is 0.

For energy harvesting devices, the peak rate and max lifetime at that 
rate are related to the size of the short-term storage (capacitor, 
rechargeable battery, ...).  Recovery time is determined by the short 
term storage in Joules divided by the useful scavenging (charging) rate 
in Watts.

For peak-power-limited devices (like many batteries, but also some 
line-powered devices in hazardous environments where energy storage is 
severely restricted) the peak rate depends on the radio and the supply.  
Max lifetime INF, recovery time 0.

For total-energy limited devices (e.g. batteries), the product of peak 
rate and lifetime is related to the total energy stored in the battery.  
Recovery time is likely 0.

Some "shortcomings" (from an IETF perspective) that would need to be 
changed if we wanted to do something similar in RoLL:
* figure out how to handle a wide range of phy/macs, with very different 
packet sizes.  Even in HART where you know the packet size for all 
devices, you'd still like more info - what if I send a 30B packet?  Can 
I send 4 times as many (Ans: almost certainly not, it's rarely linear)
* figure out how to do this in a distributed manner, instead of centralized
* figure out how much, if any, of this has to do with routing

ksjp

Omprakash Gnawali wrote:
> [...]