Subject: [Roll] Review of AODV-RPL

From: Rahul Jadhav <[email-masked]>
Date: Thu, 16 Nov 2017 12:57:40 +0800

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.

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

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

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?
   2. I would recommend to use Cooja with links in DGRM mode to evaluate
   the perf.
   3. 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).

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

Regards,

Rahul

---

From: satish anamalamudi <[email-masked]>
Date: Sun, 19 Nov 2017 21:09:53 +0800

Hello Rahul,

Thanks a lot for the review and comments on AODV-RPL. Please see my
response to your comments in [SA].

With regards

Satish.

   1. The Messaging:

[SA] Yes Rahul. The control messages(RREQ, RREP) and application data
transmission is in the opposite direction for AODV-RPL. We are checking for
the bi-directional asymmetry during control message broadcast and initiates
another multicast RREQ from destination whenever there is link asymmetry
from Source to Destination.

2. The Assumptions:

a. Quoting draft,

[SA] In fact, the AODV-RPL draft is not intended to check how the links are
going to be symmetric (or) asymmetric. The objective of our draft is when
the link is bidirectional asymmetric then how the AODV-RPL protocol handles
the scenarios of asymmetric bi-directional links.  Please check the below
link for the implementation of asymmetric AODV-RPL in Cooja Simulator.

https://github.com/lavanyahm/Contiki_AODVRPL

[SA]  Yes, this is indeed a good problem in itself which calls for a
separate draft exploring alternate methods. In the literature, one comes
across several techniques being proposed that include active and passive
probing techniques, radio sniffing, statistical channel estimation methods,
message passing, and other energy efficient techniques. In AODV-RPL, we
assume that the link property is obtained through some means, and do not
recommend any specific method to come with the symmetric and asymmetric
link property.

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?

[SA] In order to establish the upstream route from TargNode to OrigNode,
OrigNode multicasts the RREQ-Instance message to its one-hop neighbours.
In order to enable intermediate nodes R_i to associate a future RREP
message to an incoming RREQ message, the RREQ message MUST assign an odd
number for the OrigNode's Dest SeqNo which is included in the RREQ message.
When an intermediate node R_i receives a RREQ message in storing mode, it
MUST store the OrigNode's Dest Seqno along with the other routing
information needed to establish the route back to the OrigNode.  This will
enable R_i to determine that a future RREP message (containing a paired
Dest Seqno for the TargNode) must be transmitted back to the OrigNode's IP
address.

'T' bit (DIO-RREP option):  'T' is set to true to indicate that the
TargNode IPv6 Address field is present.

TargNode IPv6 Address  (when present) :  IPv6 address of the TargNode that
receives RREP-Instance message. In order to reduce the need for the
TargNode IPv6 Address to be included with the RREP message, the Dest SeqNo
of the RREP is paired, whenever possible, with the Dest SeqNo from the RREQ
message, which is always an odd number.  The pairing is accomplished by
adding one to the Dest Seqno from the RREQ message and using that, whenever
possible, as the Dest Seqno for the RREP message.  If this is not possible
(for instance because the incremented sequence number is still a valid
sequence number for another route to the TargNode from an earlier Route
Discovery operation), then the 'T' bit is set and an odd number is chosen
for the TargNode's Dest SeqNo.

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

[SA] Please, check the above github link. We too used the DGRM mode to
evaluate the performance of AODV-RPL.

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).
[SA] Yes, we considered the appendix values based on the experiments in
Cooja simulator.

On Thu, Nov 16, 2017 at 12:57 PM, Rahul Jadhav <[email-masked]> wrote:

> “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 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.
>
> 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?
> [1]  RSSI is Under-Appreciated https://sing.stanford.edu/
> site/publications/emnets2006srinivasan.pdf
>
>
> Regards,
>
> Rahul
>
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>
>

-- 

*With Regards,*

*Dr. Satish Anamalamudi, PhD.,*

---

From: Rahul Jadhav <[email-masked]>
Date: Sun, 19 Nov 2017 20:45:20 +0530

Please find my comments inline [RJ].
Regards,
Rahul

On 19 November 2017 at 18:39, satish anamalamudi <[email-masked]>
wrote:

> the bi-directional asymmetry
>
> [RJ] I did not understand  how this checking happens. Based on what i
read, the draft says that this checking (i.e detection of bidirectional
asymmetry) is left upto implementation. And my point is that it is
non-trivial, albeit impractical to do it for constrained networks
especially the way draft words it.

> during control message broadcast and initiates another multicast RREQ from
> destination whenever there is link asymmetry from Source to Destination.
>
> 2. The Assumptions:
>
> a. Quoting draft,
>
> [SA] In fact, the AODV-RPL draft is not intended to check how the links
> are going to be symmetric (or) asymmetric. The objective of our draft is
> when the link is bidirectional asymmetric then how the AODV-RPL protocol
> handles the scenarios of asymmetric bi-directional links.
>
> [RJ] The draft talks about establishing asymmetric paths and leaves the
critical asymmetric detection part out of scope. My point is, the draft
currently relies on some mechanism which is impractical and further builds
a signalling mechanism on top of it.

> Please check the below link for the implementation of asymmetric AODV-RPL
> in Cooja Simulator.
>
> [RJ] Thank you this link. After skimming through the implementation i
understand that the node defines the uplink ETX based on RREQ multicast
message signal strength. This is not realistic. Consider if the upstream
node is transmitting at a higher power. The downstream node will receive
the signal with good RSSI and it will infer (incorrectly) that the upstream
connectivity (ETX) is good as well.

> probing techniques, radio sniffing, statistical channel estimation
> methods, message passing, and other energy efficient techniques. In
> AODV-RPL, we assume that the link property is obtained through some
> means, and do not recommend any specific method to come with the
> symmetric and asymmetric link property.
>
> [RJ] All the above techniques are good in specific context. Can you have
an implementation consideration section in the draft which talks about how
to use any of these techniques especially considering that the probe
neighbour set is open-ended?

> for the TargNode's Dest SeqNo.

[RJ] This whole explanation talks about setting odd number in Dest SeqNo.
The draft does not assign an odd number to seq numbers. (Pls point me to
appropriate section if it does).
I mentioned about odd-numbered instanceID and not seqno. InstanceIDs are
paired between RREQ/RREP instances based on this odd-numbered InstanceID
scheme which in my opinion is fragile (has issues with race-conditions
which i mentioned before)

> evaluate the performance of AODV-RPL.
[RJ] In DGRM mode, if you maintain a link pair (lets say A -- B) where only
A could transmit to B but B cannot transmit to A, the implementation wont
work. What i m trying to say is, merely using DGRM mode does not help. DGRM
mode allows Cooja to define asymmetric links but you still need to further
define realistic parameters for DGRM mode without depending on the default
values.

> [SA] Yes, we considered the appendix values based on the experiments in

[RJ] The values in the appendix are incorrect and misleading. Cooja
simulator RSSI values are incorrect and you should not use cooja simulator
to get these values. Please refer to the other reference "RSSI is under
appreciated" to understand how practical RSSI values look.

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