Re: [Roll] RPL Metric ID

["Anders Brandt" <abr at sdesigns.dk>]

> Mukul Goyal wrote:
>> I think both latency and reliability are important metrics.

Same for me.

One word of warning on the energy discussion:
It seems like the assumption is that the routing protocol should manage
the number of transmitted packets in order to ensure that the energy
consumption is distributed among more nodes.

There is however a caveat here:
From our experience, a radio uses energy. Period.
Receiving uses the same as transmitting - the difference is just which
amplifiers use the energy.
Thus, the way to use less energy is to use the radio less - i.e. sleep
some of the time. Which again translates into higher latency to reach
such nodes. Obviously, there is something to save, since a radio may
quickly determine if it is the intended recipient of a packet and return
to sleep again OR receive the entire packet and stay awake to forward
the packet on to another node in the network.

Thus, what I am trying to say is:
Unless the lower layers have a smart way of quickly returning to sleep
(which some technologies have) the routing protocol will keep all nodes
awake within direct range - and they will all use power for listening =>
nothing gained from distributing the traffic.
Can battery-powered 802.15.4. nodes quickly return to sleep if they are
not the intended recipient?
If not, the energy metric may be rather useless (?)

Cheers,
  Anders
  


-----Original Message-----
From: roll-bounces at ietf.org [mailto:roll-bounces at ietf.org] On Behalf Of
JP Vasseur
Sent: 12. oktober 2009 13:46
To: Tim Winter
Cc: roll at ietf.org
Subject: Re: [Roll] RPL Metric ID


On Oct 9, 2009, at 4:08 PM, Tim Winter wrote:

> Mukul Goyal wrote:
>> I think both latency and reliability are important metrics.
>>
> +1
>

We have a good consensus to have both latency and reliability. We now
need to agree on the units.

Unit for latency ?

Unit for ETX (I propose to use the ETX): thoughts ?

>> I am sort of negative on using memory/CPU availability as metric or 
>> constraint. They seem like local factors to me. If a node is running 
>> low on memory/CPU, it can simply not participate in routing.
>>
>>
> Exposing an exaggerated rank might also be an option.
>

Indeed, although we have planned to use an Overload bit since we may not
want all nodes to trigger a DAG recomputation but only to not send
traffic until the bit is cleared.

Cheers.

JP.

> -Tim
>> Thanks
>> Mukul
>> ----- Original Message -----
>> From: "JP Vasseur" <jvasseur at cisco.com>
>> To: "IETF ROLL" <roll at ietf.org>
>> Cc: "Kris Pister" <kpister at dustnetworks.com>
>> Sent: Wednesday, October 7, 2009 1:07:52 PM GMT -06:00 US/Canada 
>> Central
>> Subject: [Roll] RPL Metric ID
>>
>>
>> Dear all,
>>
>> We would appreciate your feed-back on RPL routing metrics.
>>
>> Now that RPL is stabilizing it is time to move forward with the 
>> METRIC I-D. The next revision will be a major one, with packet 
>> encoding, processing rules, etc.
>>
>> We discussed and agreed some time ago on several links and nodes 
>> metrics (also required according to our requirement IDs).
>>
>> Still, there are a few metrics for which we would like to know 
>> whether you think that they should be specified.
>>
>> 4.2.  Latency
>>
>>
>>   As with throughput, the latency of many LLN MAC sub-layers can  
>> be    varied over many orders of magnitude, again with a  
>> corresponding    change in current consumption.  Some LLN MACs will  
>> allow the latency    to be adjusted globally on the subnet, or on a  
>> link-by-link basis, or    not at all.  Some will insist that it be  
>> fixed for a given link, but    allow it to be variable from link to  
>> link.  For efficient operation,    nodes must be able to report the  
>> range of latency that their links    can handle, and the currently  
>> available latency.
>>
>> 4.3.  Link reliability
>>
>>   In LLNs, link reliability is degraded by external interference  
>> and    multi-path interference.  Multipath typically affects both  
>> directions    on the link equally, whereas external interference is  
>> sometimes uni-    directional.  Time scales vary from milliseconds  
>> to days, and are    often periodic and linked to human activity.   
>> Packet error rate can    generally be measured directly, and other  
>> metrics (e.g. bit error    rate, mean time between failures) are  
>> typically derived from that.
>>
>> In addition:
>>
>> Node Memory resources:
>>
>> Memory is a critical node resources in presence of constrained nodes.

>> Is there a need to report node memory resources as a routing 
>> metric/constraint ?
>>
>> Node CPU resources: CPU duty cycle for virtually all LLN applications

>> to date is well below 10%, and the trend in low power embedded 
>> systems is to more capable processors rather than less.
>> Computational speed is not expected to be a limiting factor in 
>> routing in LLNs. Is there a need to report node CPU resources as a 
>> routing metric/constraint ?
>>
>> Link Security metrics
>>
>> Thanks for your feed-back.
>>
>> JP, Mijeon, Kris. _______________________________________________
>> Roll mailing list
>> Roll at ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
>> _______________________________________________
>> Roll mailing list
>> Roll at ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
>>
>
> _______________________________________________
> Roll mailing list
> Roll at ietf.org
> https://www.ietf.org/mailman/listinfo/roll

_______________________________________________
Roll mailing list
Roll at ietf.org
https://www.ietf.org/mailman/listinfo/roll