Subject: Re: [Roll] RPL Metric ID

From: Mukul Goyal <[email-masked]>
Date: Thu, 8 Oct 2009 09:59:39 -0500 (CDT)

JP

If we want to use ETX as the reliability metric, it should be ETX at the network layer. It should be related to the packet loss rate L (as observed by the network layer) as follows: ETX = 1/(1-L).

I dont really have preferences for the latency. I may have objections if you have some preferences. :)

Mukul

----- Original Message -----
From: "JP Vasseur" <[email-masked]>
To: "Mukul Goyal" <[email-masked]>
Cc: "Kris Pister" <[email-masked]>, "IETF ROLL" <[email-masked]>
Sent: Thursday, October 8, 2009 12:52:27 AM GMT -06:00 US/Canada Central
Subject: Re: [Roll] RPL Metric ID

Hi Mukul,

On Oct 7, 2009, at 9:40 PM, Mukul Goyal wrote:

> I think both latency and reliability are important metrics.
>

OK thanks for the feed-backs.
The most obvious and common reliability is ETX.
Any preference for the latency?

> 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.

And we already have an "overload" bit.

Thanks.

JP.

>
> Thanks
> Mukul
>
> ----- Original Message -----
> From: "JP Vasseur" <[email-masked]>
> To: "IETF ROLL" <[email-masked]>
> Cc: "Kris Pister" <[email-masked]>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: JP Vasseur <[email-masked]>
Date: Fri, 9 Oct 2009 11:44:35 +0200

Hi Mukul,

On Oct 8, 2009, at 4:59 PM, Mukul Goyal wrote:

> JP
>
> If we want to use ETX as the reliability metric, it should be ETX at  
> the network layer. It should be related to the packet loss rate L  
> (as observed by the network layer) as follows: ETX = 1/(1-L).

Yes, with some variations though since L is not always reported by the  
link layer (in the absence of ACK).

>
> I dont really have preferences for the latency. I may have  
> objections if you have some preferences. :)

Sure ;-)

Cheers.

JP.

> Cc: "Kris Pister" <[email-masked]>, "IETF ROLL" <[email-masked] 
> >

---

From: JP Vasseur <[email-masked]>
Date: Fri, 9 Oct 2009 11:46:38 +0200

Hi Mukul,

Sure ;-)

Cheers.

JP.