Re: [Roll] Review of draft-ietf-roll-aodv-rpl-12

[Konrad Iwanicki <[e-mail]>]

Hello Charles,

Having read your replies and briefly skimmed through version 15 of the 
draft, I believe you have addressed my major concerns. Thank you. Also 
sorry for taking so long. I had a truly busy period.

Best,
-- 
- Konrad Iwanicki.

On 15/06/2022 02:33, Charles Perkins wrote:
> Hello Konrad,
> 
> After several iterations, we have finally prepared these resolutions for 
> your much appreciated comments on our draft.
> 
> 
>  > # Major issues / questions:
>  >
>  > 1. For garbage-collecting RREQ- and RREP-DODAGs that are no longer
>  > necessary, a timeout solution is used: the L field in the RRE(Q|P)
>  > messages. Although this is not formulated explicitly in the draft, from
>  > the format of the messages, I assume that the timeout is counted locally
>  > and independently by each node, from the moment it joins the
>  > corresponding DODAG. In particular, depending among others on the
>  > network topology, the configuration of Trickle, and the underlying
>  > link-layer, a node may start a timeout for a DODAG after another has
>  > already left this DODAG. This is dangerous as it may lead to situations
>  > in which information about a DODAG is never garbage-collected because
>  > nodes that leave the DODAG may rejoin it upon hearing information from
>  > other nodes that are still in the DODAG. I would opt for an alternative
>  > solution or at least some poisoning- or grace-period based approach. In
>  > addition, it would be nice to have in the draft a potential risk
>  > analysis regarding the configuration parameters of the solution.
> 
>     o  We will create another configurable parameter called 
> REJOIN_REENABLE,
>        with a relatively long default value. Time is indeed counted locally
>        and independently by each node.
> 
> 
>  > The synchronized termination of DODAG is hard unless we introduce time
>  > information is carried in the DIO packets which in turn calls for a time
>  > synchronized network.
>  >
>  > For AODV-RPL to work, OrigNode needs to set L field such that the 
> DODAG will
>  > not prematurely timeout during data transfer with the TargNode. For 
> setting
>  > this value, it has to consider factors like, Trickle timer, TargNode hop
>  > distance, network size, link behaviour, expected data usage time, and 
> so on.
>  > Once DODAG lifetime is exceeded, stale RRE(Q|P) DIO that might be in
>  > circulation need to be discarded by TargNode and OrigNode. Eventually 
> all the
>  > intermediate nodes timeout.
> 
> 
>     The transmission of RREQ-DIO obeys the Trickle timer [RFC6206]. If
>     the length of time specified by the L field has elapsed, the OrigNode
>     MUST leave the DODAG and stop sending RREQ-DIOs in the related
>     RPLInstance.  OrigNode needs to set L field such that the DODAG will 
> not
>     prematurely timeout during data transfer with the TargNode.
>     For setting this value, it has to consider factors such as
>     Trickle timer, TargNode hop distance, network size, link
>     behaviour, expected data usage time, and so on.
> 
> 
>  > 2. What is the rationale behind deleting by TargNode the DIO ART Option
>  > containing its address (and then taking address set intersections when
>  > propagating the DIOs)? What problem do these mechanisms aim to solve? A
>  > node can still receive DIOs along multiple paths. It should be able to
>  > choose the "most desirable one". Deleting the target address and using
>  > the intersection mechanism described in Sect. 6.2.2. may actually
>  > preclude this behavior if the "most desirable path" for a TargNode is
>  > not the one it obtains first. For example, consider the following
>  > circular network:
>  >
>  > A1 - OR - B1
>  > |         |
>  > A2        B2
>  > |         |
>  > T1 - T2 - B3
>  >
>  > with OR = OrigNode, T1 = TargNode1, T2 = TargNode2, and (A|B)* acting as
>  > intermediate routers. Suppose that the path over nodes B* is the most
>  > desirable one for both T1 and T2. Now, consider the following scenario.
>  > T1 receives an RREQ-DIO first from A2 and joins the RREQ-DODAG. It then
>  > propagates the DIO to T2 but with ART Option with its own address (T1)
>  > removed. In effect T2 also joins the RREQ-DODAG, remembering however
>  > that the last RREQ-DIO contained only T2. Now, T2 finally receives an
>  > RREQ-DIO from B3. It does not propagate to T1 this path because: (1) it
>  > removes its own address from the DIO and (2) the address of T1 is not
>  > included because of taking the intersection of the address sets T2
>  > received in the DIOs along the two paths. In effect, T1 will never learn
>  > the most desirable path. Is this what is expected to happen or am I
>  > missing something? Again, it is not clear to me what the goal of the
>  > removal and intersection is. In the end, original RPL creates routes
>  > from multiple targets (all nodes) to the root, so why does this protocol
>  > require dynamically removing the targets?
> 
> The proposed scheme is motivated by a familiar trade-off between optimal
> behavior and scalability.  AODV-RPL leans heavily towards scalability
> while trying to achieve good (albeit not optimal) performance.
> Once all the TargNodes listed in ART are reached, the proposed scheme 
> prevents
> DIO messages circulating in the network.   This reduces
> congestion, routing overheads and state maintenance.
> 
> 
>  > 
> ----------------------------------------------------------------------------- 
> 
>  >
>  >
>  > 3. A related concern applies to Sect. 6.2.6., more specifically, to the
>  > second statement: "If, on the other hand, TargNode was already
>  > associated with the RREQ-Instance, it takes no further action and does
>  > not send an RREP-DIO." To me, it implies that TargNode replies with
>  > RREP-DIO to the first RREQ that results in its joining the corresponding
>  > RREQ-DODAG. In particular, if it learns about a better path to OrigNode,
>  > it does not use this path instead of the first path it joined. Again, am
>  > I missing something or is this intentional? If so, it seems somewhat
>  > conflicting with the second paragraph of Sect. 6.3, which allows the
>  > node to wait for RREP_WAIT_TIME before replying. Trying to combine these
>  > two sections, my understanding would be that TargNode sends an RREP to
>  > the best path that it is able to learn within the RREP_WAIT_TIME. If
>  > this was the intention, then what is the rationale behind setting the
>  > default RREP_WAIT_TIME to 0 for L = 0? This would imply that for an
>  > RREQ-DODAG that is to be maintained infinitely long, only the first path
>  > to OrigNode learned by TargNode is considered. In general, why not
>  > introduce into the protocol algorithms for TargNode to update its path
>  > when it learns a better one? This would also require updating RREP
>  > propagation, which is again done only for the first received message
>  > (per Sect. 6.4).
> 
> New language:
> 
>     If TargNode is not already associated with the RREQ-Instance, it
>     prepares and transmits a RREP-DIO, possibly after waiting for
>     RREP_WAIT_TIME, as detailed in (Section 6.3).
> 
>     The nodes follow Trickle timers and the correspnding DIO message
>     transfers as specified in RFC 6550.  AODV-RPL does not modify this
>     behavior.
> 
> 
>  > 4. It is not entirely clear to me how Trickle timers govern
>  > transmissions of multicast RREQ/RREP DIOs. In particular, when the
>  > timers are reset? How is this policy influenced by the fact that, in
>  > line with my previous comments, in principle a node reacts only the
>  > first RREQ/RREP DIOs that cause its joining the corresponding DODAGs.
>  > Perhaps a bit extended discussion of these issues could be provided in
>  > Sect. 8.
> 
>     RREQ-Instance/RREP-Instance multicast uses trickle timer operations
>     [RFC6206] to control RREQ-DIO and RREP-DIO transmissions.  The
>     Trickle control of these DIO transmissions follows the procedures
>     described in the Section 8.3 of [RFC6550] entitled "DIO
>     Transmission".  If the route is symmetric, the RREP DIO does not need
>     the Trickle timer mechanism.
> 
>     Whether or not an intermediate node should be allowed to update its
>     route to OrigNode and retransmit a "better" RREQ is an interesting
>     point of discussion, outside the scope of this specification.
> 
> 
>  > 5. There is also no discussion in the draft of a situation in which a
>  > node has no resources to join a RREQ- or RREP-DODAG. While in the case
>  > of RPL, this is arguably not that relevant, in the proposed protocol,
>  > there may be many concurrent DODAGs, and hence it is intuitively more
>  > likely that some nodes may lack resources to handle all DODAGs.
> 
>     If a node does not have resources, it drops the RREQ.  A node cannot 
> join
>     the DODAG unless it has enough resources to send a corresponding RREP.
> 
> 
>  > # Smaller issues / nits:
>  >
>  > Page 4, definition of "AODV": add a space between "Routing" and 
> "[RFC3561]".
> 
> Done.
> 
>  >
>  > Page 4, definition of "DODAG RREQ-Instance": "control message
>  > transmission" (hard to parse) => "transmission of control messages"
> 
> Done.
> 
>  >
>  > Page 4, definition of "DODAG RREP-Instance": the same as above
> 
> Done.
>  >
>  > Page 6, text ""RREQ-DIO message" means the DIO message from OrigNode to
>  > TargNode" is confusing as DIO messages are link-local. Changing this to
>  > ""RREQ-DIO message" means a DIO message from OrigNode toward TargNode"
>  > may sound better. The same applies to the next statement.
> 
> Done.
> 
>  >
>  > Page 8, definition of "L": "the time" => "time"
> 
> Done.
> 
>  >
>  > Page 8, definition of "MaxRank" is confusing. The name would suggest
>  > that this is the maximal allowed value, whereas the text implies that
>  > this is the minimal disallowed value. Perhaps the name "MaxRank" could
>  > be changed to something else, like "RankLimit".
> 
> Done.
> 
> 
>  > Page 8, "Other nodes MUST NOT join RREQ instance if its own Rank would
>  > be" => "Any other node MUST NOT join..."
> 
> Done.
> 
> 
>  > Page 9, definition of "L": "The lifetime of the RREP-Instance MUST be
>  > shorter than the lifetime of the RREQ-Instance to which it is paired.
>  > What if the lifetime of the RREQ-Instance is infinite? In general, why
>  > such a requirement?
> 
> Revised text:
>        2-bit unsigned integer defined as in RREQ option.  The lifetime of
>        the RREP-Instance SHOULD be shorter than the lifetime of the RREQ-
>        Instance to which it is paired.
> 
> The motivations for OrigNode's choice for the value of the L field
> are considered likely to also pertain to the RREP-Instance, including the
> case when OrigNode sets the L field to be infinite.  The mandate was
> softened to "SHOULD" in case other considerations, beyond the scope of
> this document, are relevant to the TargNode's choice.
> 
> 
>  > Page 14, the last paragraph, text starting from "It does this..." is
>  > unclear to me. What happens in the end with MaxUseRank? (This is the
>  > first and only paragraph where this symbol occurs.)
> 
> "MaxUseRank" changed to be  MaxUsefulRank -- a bit more intuitive.
> 
>  > Page 18, the last paragraph: term "shift" is somewhat misleading (to me
>  > it describes bit shifts: right shift, left shift). Perhaps "offset" or
>  > "delta" would be better.
> 
> I changed the name from Shift to Delta and rewrote the relevant text.
> 
>  >
>  > Page 18, the last paragraph: The text starting with "In RREP-DIO option,
>  > the Shift field..." seems confusing. More specifically, it is not clear
>  > to me what is shifted/offset: (1) does the receiving node have to offset
>  > the RPLInstanceID in the RREP-DIO to obtain the RPLInstanceId in the
>  > RREQ-DIO OR (2) is the RPLInstanceID in the RREP-DIO equal to the
>  > RPLInstanceID in the RREQ-DIO but the receiving node should offset the
>  > former so as to avoid conflicts? I guess it is (1) but am not sure based
>  > on the text. In particular, what "original" means there?
> 
> New terms "RREQ_InstanceID" (RPLInstanceID, OrigNode_IPaddr) and
> "RREP_InstanceID" (RPLInstanceID, TargNode_IPaddr) will be added to the
> Terminology section to resolve this.  OrigNode allocates the local
> RPLInstanceID for the RREQ_InstanceID, and likewise TargNode
> for the RREP_InstanceID.
> 
>  > Page 18, the last paragraph: "would prevent intermediate routers to
>  > distinguish" => "intermediate routers could not distinguish".
> 
> Done.
> 
>  >
>  > Page 20, Sect. 6.4.4., "Otherwise In case of an asymmetric route" =>
>  > "Otherwise, in case of an asymmetric route"
> 
> Done.
> 
>  >
>  > Page 20, Sect. 7, the second paragraph: "is at least as large" as what?
>  > As the sequence number in the RREQ-DIO message?
> 
> Done.
> 
>  >
>  > Rather than / in addition to Appendix A, perhaps citing relevant
>  > scientific papers may be informative?
> 
> We cite the following relevant papers.
> 
> -  Lifeng Sang and Anish Arora and Hongwei Zhang, "On Link Asymmetry and
>     One-way Estimation in Wireless Sensor Networks", ACM Transactions on
>     Sensor Networks, Volume 6 Issue 2 February 2010 Article No.: 12pp 1–25i
>     https://doi.org/10.1145/1689239.1689242
> 
> -  Kannan Srinivasan, Prabal Dutta, Arsalan Tavakoli, Philip Levis,
>     "An empirical study of low-power wireless", ACM Transactions on Sensor
>     Networks, Volume 6 Issue 2 February 2010 Article No.: 16pp 1–49
>     https://doi.org/10.1145/1689239.1689246
> 
> - Prasant Misra; Nadeem Ahmed; Sanjay Jha, "An empirical study of 
> asymmetry in
>    low-power wireless links",  IEEE Communications Magazine
>    (Volume: 50, Issue: 7, July 2012)
> 
> Naturally Yours,
> Charlie P.
> 
> 
> ============================ Original email follows ======================
> 
> On 2/6/2022 11:05 PM, Konrad Iwanicki wrote:
>> Dear authors,
>>
>> I have the following remarks regarding the draft. (The comments are 
>> based solely on the contents of the draft. I did not review the change 
>> log nor any meeting proceedings.)
>>
>> # Major issues / questions:
>>
>> 1. For garbage-collecting RREQ- and RREP-DODAGs that are no longer 
>> necessary, a timeout solution is used: the L field in the RRE(Q|P) 
>> messages. Although this is not formulated explicitly in the draft, 
>> from the format of the messages, I assume that the timeout is counted 
>> locally and independently by each node, from the moment it joins the 
>> corresponding DODAG. In particular, depending among others on the 
>> network topology, the configuration of Trickle, and the underlying 
>> link-layer, a node may start a timeout for a DODAG after another has 
>> already left this DODAG. This is dangerous as it may lead to 
>> situations in which information about a DODAG is never 
>> garbage-collected because nodes that leave the DODAG may rejoin it 
>> upon hearing information from other nodes that are still in the DODAG. 
>> I would opt for an alternative solution or at least some poisoning- or 
>> grace-period based approach. In addition, it would be nice to have in 
>> the draft a potential risk analysis regarding the configuration 
>> parameters of the solution.
>>
>> 2. What is the rationale behind deleting by TargNode the DIO ART 
>> Option containing its address (and then taking address set 
>> intersections when propagating the DIOs)? What problem do these 
>> mechanisms aim to solve? A node can still receive DIOs along multiple 
>> paths. It should be able to choose the "most desirable one". Deleting 
>> the target address and using the intersection mechanism described in 
>> Sect. 6.2.2. may actually preclude this behavior if the "most 
>> desirable path" for a TargNode is not the one it obtains first. For 
>> example, consider the following circular network:
>>
>>   A1 - OR - B1
>>   |         |
>>   A2        B2
>>   |         |
>>   T1 - T2 - B3
>>
>> with OR = OrigNode, T1 = TargNode1, T2 = TargNode2, and (A|B)* acting 
>> as intermediate routers. Suppose that the path over nodes B* is the 
>> most desirable one for both T1 and T2. Now, consider the following 
>> scenario. T1 receives an RREQ-DIO first from A2 and joins the 
>> RREQ-DODAG. It then propagates the DIO to T2 but with ART Option with 
>> its own address (T1) removed. In effect T2 also joins the RREQ-DODAG, 
>> remembering however that the last RREQ-DIO contained only T2. Now, T2 
>> finally receives an RREQ-DIO from B3. It does not propagate to T1 this 
>> path because: (1) it removes its own address from the DIO and (2) the 
>> address of T1 is not included because of taking the intersection of 
>> the address sets T2 received in the DIOs along the two paths. In 
>> effect, T1 will never learn the most desirable path. Is this what is 
>> expected to happen or am I missing something? Again, it is not clear 
>> to me what the goal of the removal and intersection is. In the end, 
>> original RPL creates routes from multiple targets (all nodes) to the 
>> root, so why does this protocol require dynamically removing the targets?
>>
>> 3. A related concern applies to Sect. 6.2.6., more specifically, to 
>> the second statement: "If, on the other hand, TargNode was already 
>> associated with the RREQ-Instance, it takes no further action and does 
>> not send an RREP-DIO." To me, it implies that TargNode replies with 
>> RREP-DIO to the first RREQ that results in its joining the 
>> corresponding RREQ-DODAG. In particular, if it learns about a better 
>> path to OrigNode, it does not use this path instead of the first path 
>> it joined. Again, am I missing something or is this intentional? If 
>> so, it seems somewhat conflicting with the second paragraph of Sect. 
>> 6.3, which allows the node to wait for RREP_WAIT_TIME before replying. 
>> Trying to combine these two sections, my understanding would be that 
>> TargNode sends an RREP to the best path that it is able to learn 
>> within the RREP_WAIT_TIME. If this was the intention, then what is the 
>> rationale behind setting the default RREP_WAIT_TIME to 0 for L = 0? 
>> This would imply that for an RREQ-DODAG that is to be maintained 
>> infinitely long, only the first path to OrigNode learned by TargNode 
>> is considered. In general, why not introduce into the protocol 
>> algorithms for TargNode to update its path when it learns a better 
>> one? This would also require updating RREP propagation, which is again 
>> done only for the first received message (per Sect. 6.4).
>>
>> 4. It is not entirely clear to me how Trickle timers govern 
>> transmissions of multicast RREQ/RREP DIOs. In particular, when the 
>> timers are reset? How is this policy influenced by the fact that, in 
>> line with my previous comments, in principle a node reacts only the 
>> first RREQ/RREP DIOs that cause its joining the corresponding DODAGs. 
>> Perhaps a bit extended discussion of these issues could be provided in 
>> Sect. 8.
>>
>> 5. There is also no discussion in the draft of a situation in which a 
>> node has no resources to join a RREQ- or RREP-DODAG. While in the case 
>> of RPL, this is arguably not that relevant, in the proposed protocol, 
>> there may be many concurrent DODAGs, and hence it is intuitively more 
>> likely that some nodes may lack resources to handle all DODAGs.
>>
>>
>> # Smaller issues / nits:
>>
>> Page 4, definition of "AODV": add a space between "Routing" and 
>> "[RFC3561]".
>>
>> Page 4, definition of "DODAG RREQ-Instance": "control message 
>> transmission" (hard to parse) => "transmission of control messages"
>>
>> Page 4, definition of "DODAG RREP-Instance": the same as above
>>
>> Page 6, text ""RREQ-DIO message" means the DIO message from OrigNode 
>> to TargNode" is confusing as DIO messages are link-local. Changing 
>> this to ""RREQ-DIO message" means a DIO message from OrigNode toward 
>> TargNode" may sound better. The same applies to the next statement.
>>
>> Page 8, definition of "L": "the time" => "time"
>>
>> Page 8, definition of "MaxRank" is confusing. The name would suggest 
>> that this is the maximal allowed value, whereas the text implies that 
>> this is the minimal disallowed value. Perhaps the name "MaxRank" could 
>> be changed to something else, like "RankLimit".
>>
>> Page 8, "Other nodes MUST NOT join RREQ instance if its own Rank would 
>> be" => "Any other node MUST NOT join..."
>>
>> Page 9, definition of "L": "The lifetime of the RREP-Instance MUST be 
>> shorter than the lifetime of the RREQ-Instance to which it is paired. 
>> What if the lifetime of the RREQ-Instance is infinite? In general, why 
>> such a requirement?
>>
>> Page 14, the last paragraph, text starting from "It does this..." is 
>> unclear to me. What happens in the end with MaxUseRank? (This is the 
>> first and only paragraph where this symbol occurs.)
>>
>> Page 18, the last paragraph: term "shift" is somewhat misleading (to 
>> me it describes bit shifts: right shift, left shift). Perhaps "offset" 
>> or "delta" would be better.
>>
>> Page 18, the last paragraph: The text starting with "In RREP-DIO 
>> option, the Shift field..." seems confusing. More specifically, it is 
>> not clear to me what is shifted/offset: (1) does the receiving node 
>> have to offset the RPLInstanceID in the RREP-DIO to obtain the 
>> RPLInstanceId in the RREQ-DIO OR (2) is the RPLInstanceID in the 
>> RREP-DIO equal to the RPLInstanceID in the RREQ-DIO but the receiving 
>> node should offset the former so as to avoid conflicts? I guess it is 
>> (1) but am not sure based on the text. In particular, what "original" 
>> means there?
>>
>> Page 18, the last paragraph: "would prevent intermediate routers to 
>> distinguish" => "would prevent intermediate routers from distinguishing".
>>
>> Page 20, Sect. 6.4.4., "Otherwise In case of an asymmetric route" => 
>> "Otherwise, in case of an asymmetric route"
>>
>> Page 20, Sect. 7, the second paragraph: "is at least as large" as 
>> what? As the sequence number in the RREQ-DIO message?
>>
>> Rather than / in addition to Appendix A, perhaps citing relevant 
>> scientific papers may be informative?
>>
>>
>> That seems all given the time I had. Hope that the review helps.
>>
>> Best,
>