Subject: [Roll] Question about DAO-ACK

From: Ulrich Herberg <[email-masked]>
Date: Wed, 12 Jan 2011 16:32:11 +0100

Hi,

I have a question about the DAO-ACK in non-storing mode. When the root
receives a (unicast) DAO, how can it sent back the (unicast) DAO-ACK to the
node? It is possible that the root has not yet received all other DAOs from
nodes along the path to the node that sent the DAO (e.g. because some of the
DAOs have been lost). What happens then?

Another thing: In section 6.5.3., there are no DAO-ACK options listed. But
shouldn't the padding options be allowed (as mentioned in sections 6.7.2 and
6.7.3)

Thanks
Ulrich

---

From: Matteo Paris <[email-masked]>
Date: Wed, 12 Jan 2011 14:36:50 -0500

Hi Ulrich.  Indeed this happens frequently when starting a new DODAG 
instance in non-storing mode.  Depending on DAO delay and jitter 
settings, it takes a few seconds or more for the first wave of of 
DAOs to come in from the network.  At the time a given DAO arrives, 
the root may not yet have a complete path back out to be able to 
route a DAO-ACK in return.  However this will generally be remedied 
by the time the node in question retries the DAO since the other 
nodes in the network will have had time to send in their first DAO. 
If not, there are always more retries.

The root could store the knowledge that it owes a DAO-ACK, and send 
it out as soon as it has gathered sufficient source-routing 
information, but it's less code to just forget about it and wait for 
the next DAO retry.

Note that you can also play with the DAO delay timing, which is left 
open by the RPL spec.  The typical thing is to set the DAODelay to be 
proportional to rank, so that DAOs from routers closest to the root 
arrive first, which avoids using bandwidth for extra retries.  (This 
is exactly the reverse of the DAODelay optimization suggestion made 
for storing mode in section 9.6, since in that case it is desirable 
for the leaf nodes to send their DAOs first so the information can be 
aggregated more efficiently.)  During DAG formation, the further from 
the root a node is, the longer it takes for the parent set to settle 
down.  So waiting a bit longer also helps avoid an initial 
proliferation of DAOs caused by fluctuating parent sets.  The 
tradeoff is an increase in the amount of time for the root to obtain 
a complete set of downward routes, which may be a concern.

Matteo

At 4:32 PM +0100 1/12/11, Ulrich Herberg wrote:
>Hi,
>
>I have a question about the DAO-ACK in non-storing mode. When the 
>root receives a (unicast) DAO, how can it sent back the (unicast) 
>DAO-ACK to the node? It is possible that the root has not yet 
>received all other DAOs from nodes along the path to the node that 
>sent the DAO (e.g. because some of the DAOs have been lost). What 
>happens then?
>
>Another thing: In section 6.5.3., there are no DAO-ACK options 
>listed. But shouldn't the padding options be allowed (as mentioned 
>in sections 6.7.2 and 6.7.3)
>
>Thanks
>Ulrich
>
>_______________________________________________
>Roll mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/roll

---

From: Ulrich Herberg <[email-masked]>
Date: Fri, 14 Jan 2011 10:56:26 +0100

Hi Matteo,

thanks for your reply! That clarified a few things. I suggest that
this should be specified in the RPL spec.

On Wed, Jan 12, 2011 at 8:36 PM, Matteo Paris <[email-masked]> wrote:
>
> Hi Ulrich.  Indeed this happens frequently when starting a new DODAG instance in non-storing mode.  Depending on DAO delay and jitter settings, it takes a few seconds or more for the first wave of of DAOs to come in from the network.  At the time a given DAO arrives, the root may not yet have a complete path back out to be able to route a DAO-ACK in return.  However this will generally be remedied by the time the node in question retries the DAO since the other nodes in the network will have had time to send in their first DAO. If not, there are always more retries.

Yes, true. However, the RPL spec. says that the number of retries may
be bounded. So it could happen that a node has stopped sending DAOs,
before the root has received any, or before any DAO-ACK has been
sucessfully received by the node (DAO-ACKs could also be lost). Also,
it is unclear to me, how the DAOs are timed, when multiple are sent
(exponential backoff timer? periodic? which interval? That could also
have some relations with the DAODelay, see below).

> The root could store the knowledge that it owes a DAO-ACK, and send it out as soon as it has gathered sufficient source-routing information, but it's less code to just forget about it and wait for the next DAO retry.

Yes, that are two valid possibilities that should be specified in RPL.

> Note that you can also play with the DAO delay timing, which is left open by the RPL spec.  The typical thing is to set the DAODelay to be proportional to rank, so that DAOs from routers closest to the root arrive first, which avoids using bandwidth for extra retries.

True, that may help, but only if no DAOs from nodes with a lower rank
are lost. If some are lost, DAOs from nodes with a higher rank (and
higher DAODelay) could still arrive before the DAOs from nodes with a
lower rank.

> (This is exactly the reverse of the DAODelay optimization suggestion made for storing mode in section 9.6, since in that case it is desirable for the leaf nodes to send their DAOs first so the information can be aggregated more efficiently.)  During DAG formation, the further from the root a node is, the longer it takes for the parent set to settle down.  So waiting a bit longer also helps avoid an initial proliferation of DAOs caused by fluctuating parent sets.  The tradeoff is an increase in the amount of time for the root to obtain a complete set of downward routes, which may be a concern.

Yes, I agree.

Another question: what happens if no DAO-ACKs are used? It could
happen that a node sends several DAOs, but none of them arrives at the
root. When an upper bound for the number of DAOs to send is used, the
node would eventually stop sending DAOs, believing that the root has
received at least one. But neither the root would know about the node
(i.e. would not have a route towards the node), nor would the node
know that the root does not have a route. That seems like a bad
situation.

Thanks
Ulrich

>> I have a question about the DAO-ACK in non-storing mode. When the root receives a (unicast) DAO, how can it sent back the (unicast) DAO-ACK to the node? It is possible that the root has not yet received all other DAOs from nodes along the path to the node that sent the DAO (e.g. because some of the DAOs have been lost). What happens then?
>>
>> Another thing: In section 6.5.3., there are no DAO-ACK options listed. But shouldn't the padding options be allowed (as mentioned in sections 6.7.2 and 6.7.3)
>>
>> Thanks
>> Ulrich
>>

---

From: Ulrich Herberg <[email-masked]>
Date: Fri, 14 Jan 2011 11:28:58 +0100

P.S. another question concerning the time when DAOs are sent: (still
in non-storing mode)

The spec says that DAOs can be sent when "the Path Lifetime is to be
updated (e.g. a refresh or a no-Path)" (section 9.2.1). At what time
exactly does that mean? I assume that a node should keep a timer how
long the target is "fresh", and send a DAO _before_ it expires at the
root. How long before? (note that the DAO could be lost). Is jitter
used? Otherwise, adjacent nodes could periodically send "refresh" DAOs
for their target at the same time, leading to collisions. How many
DAOs are sent at each refresh (in which intervals)?

It would be much clearer for me as implementer if the spec was more
precise in many of these questions. Also, it is difficult to discern
the parts for non-storing mode and for storing mode; they are often
mixed up in section 9, while the mechanisms are quite different (even
though they use a similar message format).

Thanks for the clarifications
Ulrich