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

From: Rahul Jadhav <[email-masked]>
Date: Fri, 5 Jan 2018 17:12:02 +0530

Hi Remy,

Please find my comments inline.

Regards,
Rahul
p.s. i feel a voice call will help us better here. Will ping you.

On 25 December 2017 at 12:44, Liubing (Remy) <[email-masked]>
wrote:

> Hi Rahul,
>
>
>
> Please find my comments inline.
>
>
>
> Best regards,
>
> Remy
>
>
>
> *From:* Roll [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Rahul Jadhav
> *Sent:* Wednesday, December 20, 2017 8:11 PM
> *To:* Charlie Perkins <[email-masked]>
> *Cc:* Routing Over Low power and Lossy networks <[email-masked]>
> *Subject:* Re: [Roll] Review of AODV-RPL
>
>
>
> Hello Charlie,
>
>
>
> Please find my response inline..
>
> Regards,
>
> Rahul
>
>
>
> On 15 December 2017 at 20:49, Charlie Perkins <
> [email-masked]> wrote:
>
> 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.
>
>
>
> [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.
>
> [Remy] I think we have a misunderstanding here. “Bidirectional” talks
> about the reachability, while “symmetric” talks about the upward and
> downward routes. The “asymmetric” here signifies the upward and downward
> routes between the OrigNode and the TargNode are different, while
> "bidirectional" means control messages can be received in two directions.
> Both RPL and AODV-RPL use bidirectional links.
>

[RJ] I m not very clear of this text. AODV-RPL cannot depend on
bidirectional links to establish asymmetric 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).
>
>
> 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.
>
>
>
> [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*.
>
> [Remy] The upstream destination is the OrigNode, which is the root of the
> DODAG. An intermediate node only needs to maintain a route entry to the
> OrigNode, including the information of the next hop on the upstream route.
> The next hop is actually the node’s preferred parent in this DODAG.
>

[RJ] I understand that from the routing table perspective only the OrigNode
entry has to be established. My point was in context to identifying/probing
adjoining next hop through which this route would be established. For this
probing you need to maintain a table which will have all adjoining peers.

>
>
> 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.
>
>
>
> [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 thhen e 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.
>
> [Remy] The node doesn’t have to probe all its neighbor. Don’t forget that
> AODV-RPL is an extension of RPL, and the RREP and RREQ are two new DIO
> options. Thus the DIO transmission, local repair and many other mechanisms
> to maintain the state are the same as RPL.  Therefore, the control overhead
> will stay the same.
>

[RJ] I understand that the DIO transmission, and other factors remain the
same. Adding RREP/RREQ on top of existing DIO messaging does not achieve
asymmetric paths. When OrigNode sends a DIO, its received by another node
downstream and the path is established upstream. This is the mechanism RPL
follows. Also AODV-RPL follows the same signalling mechanism and this is
where the problem starts with the asymmetric path claim.

>
>
>
>
>
>
>
> 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.
>
>
> 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.
>
>
>
> [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?
>
> [Remy] Again, it is still in the framework of RPL, so the probing is done
> in the same way as RPL, i.e. by DIO and DIS, which are controlled by the
> trickle timer.
>
[RJ]: No. Probing cannot be done the same way. In case of RPL, DIO is sent
downstream and the downstream nodes use DIO metrics and messaging signal
qualities to establish upstream path. This is ok in case of RPL because RPL
says that it depends upon bidirectional connectivity (not necessarily
symmetric but still bidirectional for e.g. power levels in both direction
might vary but the messaging still works) for it to work.
Now for AODV-RPL's asymmetric claim to work, the upstream and downstream
paths between the same pair of nodes can be different. For asymmetric
links, AODV-RPL cannot depend upon RPL's style of DIO messaging.

>
>
>
>
> 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.
>
>
>
> [RJ] Yeah, for local instances this might not be a problem. Thanks.
>
>
>
>
>    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.
>
>
>
> [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
>
>
> 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.
>
>
>
> [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
>
>
>
>
>
>
> Regards,
> Charlie P.
>
>
>

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 5 Jan 2018 21:19:48 +0200

Hi Rahul

> bidirectional links to establish asymmetric paths.

My understanding:   means that any physical link cannot be dependent that
it connects two way communication, so we always expect one-way. other
protocols assume that any link is bidirectional as two way, so RPL depends
on bidirectional links, but AODV-RPL claims that is not.

> [RJ] I understand that from the routing table perspective only the
> OrigNode entry has to be established. My point was in context to
> identifying/probing adjoining next hop through which this route would be
> established. For this probing you need to maintain a table which will have
> all adjoining peers.
>

why you need the adjoining?

> where the problem starts with the asymmetric path claim.

I agree that the draft needs more explaining of the AODV_RPL mechanism to
show that it is not same as RPL. I agree that the draft is not well
detailed.

>> [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?
>>
AODV-RPL has different messages, so it is different style to establish paths