Subject: Re: [Roll] Review of AODV-RPL

From: Charlie Perkins <[email-masked]>
Date: Fri, 15 Dec 2017 07:19:13 -0800

Hello Rahul,

Thanks for the review!  It is much appreciated.  I have some follow-up 
below.

On 11/15/2017 8:57 PM, Rahul Jadhav wrote:
>
> Following is my review of AODV-RPL.
>
> One of the stated goal of AODV-RPL is to cater to asymmetric links. 
> While this is really great to have, I have doubts that the current 
> specification achieves it in a practical way. Foll is the reasoning:
>
>  1. The Messaging:
>
>     AODV-RPL requires that you send a multicast message from OrigNode
>     to TargNode and realise a routing path in the opposite direction.
>
>     For e.g. A -> B -> C -> D, A sends a RREQ-Instance message towards
>     D and nodes B,C,D establish routing adjacencies in the opposite
>     direction. This kind of messaging is the reason why RPL depends on
>     bidirectional links for control/data paths.
>

It's not just RPL.  A lot of protocols work this way.

>     2. The Assumptions:
>
>     a. Quoting draft,
>
>         “Each intermediate node R_i computes the rank for
>         RREQ-Instance and creates a routing table entry for the
>         upstream route towards thesource if the routing
>         metrics/constraints are satisfied.For this purpose R_i ***must
>         use the asymmetric link metric measured in the upstream
>         direction***, from R_i to its upstream neighbor that
>         multicasted the RREQ-Instance message.”
>
>     This is the primary assumption which achieves asymmetric
>     behaviour. But it’s an implementation nightmare to do this
>     measurement especially because we do not know which neighbour we
>     might end up tieing up with (thus need to probe all neighbours).
>

I don't think this is true.  A node simply has to keep track of the 
information for the upstream destination, and the information about the 
specific node from which the RREQ was received.

>     It will add up so much to the control overhead and also requires
>     (a good deal of) state info to be maintained on behalf of the
>     neighbouring nodes.
>

I don't see why it adds much to the control overhead.  The state can be 
timed out after a relatively small duration of time.  We will add that 
timeout parameter for the next revision.

>     Anyways i tried to search for your implementation to check on this
>     but i could not find it.
>
>     b. Use of past conditions to suggest future traffic path selection:
>
>         “If the RREQ-Instance arrives over an interface that is not
>         known tobe symmetric, or is known to be asymmetric, the 'S'
>         bit is set to be 0.”
>
>     This is a typical problem we face as well. Probing for
>     measurements at such scale (all neighbours) is a problem. If you
>     do the probing sparsely, the network conditions might have changed
>     when you want to use the measurements.
>

Yes, this is naturally a problem in dynamic networks.  We can't predict 
the future, so we are stuck with recording salient aspects of the past.  
No matter how often we measure, it is guaranteed to be wrong some (or 
most!) of the time in the future.  And yet we persist.

But we do not require periodic or exhaustive measurements for all 
neighbors -- only as needed for the protocol to work.

> Other points:
>
>  1. Use of odd/even numbers for pairing instances may not be a robust
>     way of pairing … There could be race conditions where other
>     P2P-RPL instances or floating DODAG instances end up using one of
>     the same value in the instance-id pair. How to resolve such collision?
>

But, the instance-ids are local.  So if two different nodes use the same 
ID that is O.K.  If those two nodes need to have a peer-to-peer route to 
the same destination, that is still O.K., but the RREP sent back to one 
of the source nodes will be able to use the paired instance-ID and the 
streamlined RREP, and the other RREP will have to include an unpaired 
instance-ID along with the IPv6 address of the target node.  That will 
be a rare occurrence, and so the optimization of eliding the IPv6 
address  will usually be possible.

>  1. I would recommend to use Cooja with links in DGRM mode to evaluate
>     the perf.
>

This sounds like a good idea.  The other co-authors will probably have 
more follow-up about this.

>  1. The RSSI values in the Appendix do not look correct. An RSSI of
>     <-70dbm is too good [1] to have for good PDR. The mapping of
>     RSSI-ETX in the appendix hence may not be correct (i believe these
>     values are from Cooja).
>

I don't understand how an RSSI could be "too good", unless you mean that 
the power level is too high and causes widespread interference.  
Admittedly, I am no expert in interpreting PHY layer effects, but anyway 
usually higher received power allows more accurate detection, if the 
background noise level remains the same.

>
> [1]RSSI is Under-Appreciated 
> https://sing.stanford.edu/site/publications/emnets2006srinivasan.pdf
>

Thanks for the link.  I read through it very briefly on this fine 
morning.  However, I have also read other papers that seriously question 
the value of relying on RSSI.  I'll try to remember and find one for 
further discussion.  Notably, the authors seem to focus on particular 
hardware, and a single link between two neighbors, for their discussion, 
unless I missed something.

Regards,
Charlie P.

---

From: Rahul Jadhav <[email-masked]>
Date: Wed, 20 Dec 2017 17:40:56 +0530

Hello Charlie,

Please find my response inline..

Regards,
Rahul

On 15 December 2017 at 20:49, Charlie Perkins <[email-masked]
> wrote:

> One of the stated goal of AODV-RPL is to cater to asymmetric links. While
> this is really great to have, I have doubts that the current specification
> achieves it in a practical way. Foll is the reasoning:
>
>    1. The Messaging:
>
> AODV-RPL requires that you send a multicast message from OrigNode to
> TargNode and realise a routing path in the opposite direction.
>
> For e.g. A -> B -> C -> D, A sends a RREQ-Instance message towards D and
> nodes B,C,D establish routing adjacencies in the opposite direction. This
> kind of messaging is the reason why RPL depends on bidirectional links for
> control/data paths.
>
>

[RJ] But this mode of signaling does not help satisfy the stated goal of
establishing asymmetric links. RPL (and others like p2p-rpl) follows this
mode of signaling and hence depend on bidirectional links.

> 2. The Assumptions:
>
> a. Quoting draft,
>
> “Each intermediate node R_i computes the rank for RREQ-Instance and
> creates a routing table entry for the upstream route towards the source
> if the routing metrics/constraints are satisfied.  For this purpose R_i
> ***must use the asymmetric link metric measured in the upstream
> direction***, from R_i to its upstream neighbor that multicasted the
> RREQ-Instance message.”
>
> This is the primary assumption which achieves asymmetric behaviour. But
> it’s an implementation nightmare to do this measurement especially because
> we do not know which neighbour we might end up tieing up with (thus need to
> probe all neighbours).
>
>

[RJ] Assuming a moderately populated hop, a node now needs to keep track of
information in context all the peers on the same hop. You mentioned, 'node
needs to track only upstream destination' ... but imo this is not true. For
P2P paths, its a different DAG instance and thus there are no
pre-determined *upstream destinations*.

> It will add up so much to the control overhead and also requires (a good
> deal of) state info to be maintained on behalf of the neighbouring nodes.
>
>

[RJ] The reason for high control overhead is that the node will have to
keep probing the neighbors to maintain state. The problem with smaller
duration time is that the probe will be more frequent! Regardless, the
table that needs to be maintained for such information is directly
proportional to the number of neighboring peers.

>
>
> Anyways i tried to search for your implementation to check on this but i
> could not find it.
>
> “If the RREQ-Instance arrives over an interface that is not known to be
> symmetric, or is known to be asymmetric, the 'S' bit is set to be 0.”
>
> This is a typical problem we face as well. Probing for measurements at
> such scale (all neighbours) is a problem. If you do the probing sparsely,
> the network conditions might have changed when you want to use the
> measurements.
>
>
> the future, so we are stuck with recording salient aspects of the past.  No
> matter how often we measure, it is guaranteed to be wrong some (or most!)
> of the time in the future.  And yet we persist.
>

[RJ] May be this is the part i don't get ... You mentioned "only as needed
for the protocol to work" ... Can this be elaborated?

>    way of pairing … There could be race conditions where other P2P-RPL
>    instances or floating DODAG instances end up using one of the same value in
>    the instance-id pair. How to resolve such collision?
>
>
> the same destination, that is still O.K., but the RREP sent back to one of
> the source nodes will be able to use the paired instance-ID and the
> instance-ID along with the IPv6 address of the target node.  That will be a
> rare occurrence, and so the optimization of eliding the IPv6 address  will
> usually be possible.
>

[RJ] Yeah, for local instances this might not be a problem. Thanks.

>    <-70dbm is too good [1] to have for good PDR. The mapping of RSSI-ETX in
>    the appendix hence may not be correct (i believe these values are from
>    Cooja).
>
>

[RJ] My reference here is to the RSSI to ETX mapping table in the draft.
The values noted in that table do not look correct. For RSSI -55 to -45dbm,
the expected ETX is 993. On what basis was this table generated ? Typically
i have found that RSSI of < -80dbm results in very good PDRs (also the ref
i attached says the same).

>
>
>
> [1]  RSSI is Under-Appreciated https://sing.stanford.edu/site
> /publications/emnets2006srinivasan.pdf
>
>
> the value of relying on RSSI.
>
I'll try to remember and find one for further discussion. Notably, the
> authors seem to focus on particular hardware, and a single link between two
> neighbors, for their discussion, unless I missed something.
>

[RJ] The authors have not merely focused on single link between two
neighbors. The slides of the paper-talk gives a better picture,
https://sing.stanford.edu/site/talks/emnets2006srinivasan.ppt

---

From: "S.V.R.Anand" <[email-masked]>
Date: Wed, 20 Dec 2017 22:19:37 +0530

Hello Rahul,

Thanks a lot for your review. 

I agree with your observation on the RSSI-ETX table. 

The RSSI values mentioned in the draft is the value obtained from the
hardware register of the transceiver, in our case it is CC2420. The real
RSSI value is obtained by adding an offset to this value as per the
datasheet of the transceiver. In the case of CC2420 this offset is -45.
So, we need to apply this offset to RSSI values given in the table. 

In summary, we will update the table with proper RSSI values in the next
revision.

Regards 
Anand

> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll