Subject: Re: [Roll] RPL Metric ID

From: Sung Lee <[email-masked]>
Date: Thu, 15 Oct 2009 10:20:06 -0400

JP and WG members,

This may be considered link reliability.
But in our experience, we found the following information very helpful
in improving the stability of network and also (and you could say) in
avoiding loops as well.

We use what we call 'W' (weight).
When we forward data packet, we require per-hop ACK.
When we receive ACK, we adjust the new W to be old W -1 (W_new = W_old - 1).
When we don't receive ACK, we adjust the new W to be old W + 1 (W_old =
W_old +1).
When we detect a loop, we adjust the W value to MAX.

We have experimented MAX value based on real system, MAX value of 10
seems to be a good value to start with.

Now this can be combined with other metric values you are all
discussing. We have experimented quite a lot with combing several
metrics with the above weight in determining the path, which so far
seems to work in our system.
For instance, the other metric values you are discussing (such as link
quality, RSSI, and/or everything else - please note this can be as
simple as hop count, RSSI, or whatever the WG determines) can be used
with along with W value to determine.

I am interested in what the WG thinks of using this 'W' as part of
metric for RPL.
Best regards,
Sung

[email-masked] wrote:
> Message: 1
> Date: Wed, 7 Oct 2009 20:07:52 +0200
> From: JP Vasseur <[email-masked]>
> Subject: [Roll] RPL Metric ID
> To: IETF ROLL <[email-masked]>
> Cc: Kris Pister <[email-masked]>
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset="us-ascii"; Format="flowed";
> 	DelSp="yes"
>
> 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.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://www.ietf.org/mail-archive/web/roll/attachments/20091007/2aca25e8/attachment.htm>
>
> ------------------------------
>
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>
>
> End of Roll Digest, Vol 21, Issue 11
> ************************************
>

---

From: Philip Levis <[email-masked]>
Date: Thu, 15 Oct 2009 09:05:23 -0700

> I am interested in what the WG thinks of using this 'W' as part of

Sung,

I think the general approach of directly measuring the datapath is a  
great way to have fast and accurate link estimation. CTP's 4-bit link  
estimator (4B) has some similarities to what you describe, although it  
smoothes estimates much more: I'd be concerned about excessive  
instability in the above algorithm, as note that you can't measure a  
link you're not using.

Have you read the 4-bit paper? You can find it at http://sing.stanford.edu/singpubs.html

Phil