Subject: Re: [Roll] RPL Metric ID

From: Sung Lee <[email-masked]>
Date: Tue, 27 Oct 2009 12:57:46 -0400

Philip,

Sorry for my late response. I have been quite swamped with work and
travels.
I read your paper and I liked it. I like your concept of using
information from all three layers.
Although our approach is not as "formalized" as yours, I think
fundamentally we do share some similarity.
I would say that one difference is that we try to reflect the existence
of loop in the estimation. Since we do actively check for loop
existence, we reflect that into the estimation value by penalizing it.
But please note that we do not actively try to remove the loop when we
find it. Our experience is that by reflecting the existence of loops in
the estimation/metric, it sorts itself out over time.

Thanks for sharing your paper.
Best regards,
Sung

[email-masked] wrote:
>
> Message: 2
> Date: Thu, 15 Oct 2009 09:05:23 -0700
> From: Philip Levis <[email-masked]>
> Subject: Re: [Roll] RPL Metric ID
> To: Sung Lee <[email-masked]>
> Cc: [email-masked]
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>
>
> On Oct 15, 2009, at 7:20 AM, Sung Lee wrote:
>
>
>> 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.
>>
>
> 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
>
>
>
>
>