Subject: [Roll] DTSN increment

From: Rahul Jadhav <[email-masked]>
Date: Tue, 11 Oct 2016 12:09:59 +0200

Hi All,

I have specific query regarding handling of DTSN increments. DTSN
increments are handled differently in case of storing mode vs non-storing
mode.

6550 states,
"
   In a Non-Storing mode of operation, a DTSN increment will also cause
   the immediate children of a node to increment their DTSN in turn,
   triggering a set of DAO updates from the entire sub-DODAG.
   Typically, in a Non-Storing mode of operation, only the root would
   independently increment the DTSN when a DAO refresh is needed but a
   global repair (such as by incrementing DODAGVersionNumber) is not
   desired.  Typically, in a Non-Storing mode of operation, all non-root
   nodes would increment their DTSN only when their parent(s) are
   observed to do so.
"

Based on this wordings, in non-storing mode, the DTSN update is controlled
by the root only (having said that, the RFC does not mandate it).

What i don't understand is, why DTSN increment is handled differently for
storing and non-storing mode?
Also when the DTSN is incremented by the child node, isn't it desired that
DIO trickle timer is reseted, since otherwise the DIO (with incremented
DTSN) may be sent out (very) late and thus DAO update may take huge time
(depending upon where the trickle timer rests currently).

Regards,
Rahul

---

From: Cenk Gündoğan <[email-masked]>
Date: Tue, 11 Oct 2016 13:54:40 +0200

Hello Rahul,

see my comments inline:

> storing and non-storing mode?

CG: My 2 cents ..
In Non-Storing MOP, parents are absolutely oblivious to nodes in their
sub-DODAG, while in Storing MOP parents maintain downward routes.

So, if parents in Non-Storing MOP autonomously increment the DTSN, then DAOs
will be forwarded to the root of the DODAG anyways, without actually
affecting any parents in between (no FIB). This is why it makes sense (IMO)
to limit the DTSN handling to the root node only.
In Storing MOP however, parents can detect stale or otherwise erroneous
routes, since they are maintained, and thus should be allowed to
trigger DAOs from their sub-DODAG in order to repair improper routes.

> (depending upon where the trickle timer rests currently).

CG: This is a good hint, I couldn't find anything in the spec regarding this
issue. I assume this is highly use case and implementation specific.
If a use case demands an immediate update of the routes, then a one-shot
DIO after deliberately changing the DTSN would make sense. At the same
time, an implementation might also classify such a circumstance as an
inconsistency, which then leads to a trickle timer reset. Other times,
triggering DAOs might not be that urgent in consistent networks, so that
the next DIO w/ new DTSN might as well be transmitted within the next
trickle interval (hours, days ..).

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

Best,
Cenk

-- 
Cenk Gündoğan

Hamburg University of Applied Sciences
Dept. of Computer Science / Internet Technologies Group
Berliner Tor 7, 20099 Hamburg, Germany
Fon: +49 40 42875 - 8426
Mail: [email-masked]
Web: https://www.inet.haw-hamburg.de/

---

From: Rahul Jadhav <[email-masked]>
Date: Tue, 11 Oct 2016 23:06:35 +0530

Thanks Cenk,

Please find my replies inline.

> On Oct 11, 2016, at 5:24 PM, Cenk Gündoğan <[email-masked]> wrote:
> 
> Hello Rahul,
> 
> see my comments inline:
> 

Yes, it makes sense. Another way to put it would be, 
In storing-mode if a node switches parent, it may have to increment the DTSN and request for the DAO updates from its sub-DODAG. In non-storing mode this (DTSN incr) is not required since the node only needs to send DAO on its own behalf and the route path realignment for the sub-DODAG will be taken care of by root node. 
Isn’t the cost of parent switch too high in case of storing mode of operation? Is there any better way of achieving sub-DODAG route update for this case? 

> trickle interval (hours, days ..).

Triggering DAO might not be urgent but we can’t expect DAO updates to happen after (say) hours of incrementing the DTSN (assuming the only purpose of incrementing DTSN is to initiate DAO updates).
one-shot DIO is very indeterministic and I m afraid if the details are kept implementation specific then we may possibly have a non-interoperable implementations. What if one implementation resets the timer while others do not.
I tried thinking of any use-case where we increment a DTSN and not reset the trickle timer. Do you have any which can be used as an example? Thanks.

>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/roll <https://www.ietf.org/mailman/listinfo/roll>
> 
> 
> Best,
> Cenk
> 
> -- 
> Cenk Gündoğan
> 
> Mail: [email-masked] <mailto:[email-masked]>
> Web: https://www.inet.haw-hamburg.de/ <https://www.inet.haw-hamburg.de/>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/roll <https://www.ietf.org/mailman/listinfo/roll>