Subject: [Roll] closing on #27: DAO ACK ?

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 3 May 2010 08:45:25 +0200

Hi:

As you know, the main problem addressed by ticket 27 is the delay caused
by loss of DAO.

I've seen a few voices with a general support for the mechanism, but not
enough to declare a consensus IMHO.

At this point what we can do is:

1)      Reject; no ack for the time being

2)      Adopt, all nodes need to support it. DAO ack request would be an
optional flag in the DAO.

3)      Make it optional controlled by the root so a node can only join
a network as a router if it can ACK DAOs.

Please give us a feeling of the WG intention here by voting 1, 2 or 3
this week!

Thanks for this,

Pascal

From: JP Vasseur [mailto:[email-masked]] 
Sent: Thursday, April 15, 2010 1:57 PM
To: Pascal Thubert (pthubert)
Subject: Fwd: [roll] #27: DAO ACK ?

Salut,

Can you try to close on this one ?

Merci !

JP.

Begin forwarded message:

From: "roll issue tracker" <[email-masked]>

Date: March 10, 2010 1:33:38 PM CEST

To: [email-masked], [email-masked]

Cc: [email-masked]

Subject: [roll] #27: DAO ACK ?

Reply-To: [email-masked]

#27: DAO ACK ?
--------------------------------+---------------------------------------
----
Reporter:  jpv@...               |       Owner:  pthubert@...        
    Type:  task                |      Status:  new               
Priority:  major               |   Milestone:                    
Component:  rpl                 |     Version:                    
Severity:  Active WG Document  |    Keywords:                    
--------------------------------+---------------------------------------
----
WG:

RPL 07 provides means for a node to advertise some reachability using a
DAO mechanism. The DAO can be triggered by the node to match its own
needs. It can also be stimulated by a parent, by incrementing the DTSN,
or
by the root, by setting the T bit that causes the DTSN increment to span
the whole DODAG.

The DTSN was added as a replacement to a single bit because, due to the
nature of an LLN, we thought that the bit might be lost whereas a DTSN
increment must be seen at some point. But the other way around, the DAO
message is not acknowledged so a node might not obtain the service that
it
expects, and a route propagation might be inappropriately delayed.

So the simple question is, should we make the DAO a bit more reliable by
adding an ack?

Pascal.

-- 
Ticket URL: <http://svn.tools.ietf.org/wg/roll/trac/ticket/27>
roll <http://tools.ietf.org/wg/roll/>

---

From: Richard Kelsey <[email-masked]>
Date: Thu, 06 May 2010 08:39:34 -0400

> Date: Mon, 3 May 2010 08:45:25 +0200
> From: "Pascal Thubert (pthubert)" <[email-masked]>
> 

I think we need a way to ACK DAOs (these are lossy networks,
after all) but I am not sure that we need an explicit DAO ACK.

Without local DAO caches ACKs are crucial, because
indivicual DAOs travel multiple hops.  Any source-routed
message serves as a DAO ACK.  Even if the most recent DAO
has been lost, such a message shows that the root has a
working downward path.

With local DAO caches, individual DAOs travel only one hop,
making them more reliable.  On the other hand, receiving a
downward message does not function as a DAO ACK, because it
does not show that the parent has the complete current DAO.

My preference would be a variant of 2):

 - Without DAO caches, treat downward source-routed messages
   as DAO ACKs.  DAOs should be retried at some low rate
   until an ACK is heard.
   
 - With DAO caches, have an explicit DAO ACK that is
   required.  In the interests of simplicity, I would make
   sending a DAO ACK required, with no ACK request flag in
   the DAO.

If no one else votes, do I win?

                             -Richard Kelsey

---

From: Roger Alexander <[email-masked]>
Date: Thu, 6 May 2010 10:05:44 -0700 (PDT)

Hi Richard, 

I think your vote should be considered a win.

Roger

----- Original Message ----
From: Richard Kelsey <[email-masked]>
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: [email-masked]
Sent: Thu, May 6, 2010 8:39:34 AM
Subject: Re: [Roll] closing on #27: DAO ACK ?

[RA] These are lossy networks that can have reliable link layer transfers. Nonetheless, what is considered from the perspective of the RPL protocol is an acknowledgment between the routing (control) entities. In the case of the DAO, this acknowledgment can serve the purpose of confirming the downward routing state between RPL entities. It is in this regard that I favor an explicit DAO ACK.

[RA] Without local DAO caches the communicating (control) RPL entities are the originating node and the root. However, a DAO Parent(s) has to be participating on behalf of a node to ensure that a downward route can be derived to the node. Without DAO ACKs the RPL exchanges between these participating entities (node, DAO Parent(s), root) are all implicit.

[RA] Agreed. In the case of caching nodes the communicating RPL entities are the node and its DAO Parent(s). In this case the model should be one of explicitly acknowledged DAO exchanges.

  

[RA] In the interest of simplicity and compactness I do favor requiring the DAO to be explicitly ACKed without a flag. I support Richard's suggestion of tying the capability to the caching/non-caching mode of operation.   

                             -Richard Kelsey

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 13 May 2010 18:49:22 +0200

Thanks you all

This poll only got positive answers. I asked the authors and got no
negative either. 
Let's include a DAO Ack in 08 then. Hopefully that's very soon.

Pascal

> -----Original Message-----
> From: Roger Alexander [mailto:[email-masked]]
> Sent: Thursday, May 06, 2010 7:06 PM
> To: Richard Kelsey; Pascal Thubert (pthubert)
> Cc: [email-masked]
> > As you know, the main problem addressed by ticket 27 is the delay
> > caused by loss of DAO.
> >
> > I've seen a few voices with a general support for the mechanism, but
> > not enough to declare a consensus IMHO.
> >
> I think we need a way to ACK DAOs (these are lossy networks, after
all) but I
> am not sure that we need an explicit DAO ACK.
> 
> [RA] These are lossy networks that can have reliable link layer
transfers.
> Nonetheless, what is considered from the perspective of the RPL
protocol is
> an acknowledgment between the routing (control) entities. In the case
of
> the DAO, this acknowledgment can serve the purpose of confirming the
> downward routing state between RPL entities. It is in this regard that
I favor
> an explicit DAO ACK.
> 
> Without local DAO caches ACKs are crucial, because indivicual DAOs
travel
> multiple hops.  Any source-routed message serves as a DAO ACK.  Even
if the
> most recent DAO has been lost, such a message shows that the root has
a
> working downward path.
> 
> [RA] Without local DAO caches the communicating (control) RPL entities
are
> the originating node and the root. However, a DAO Parent(s) has to be
> participating on behalf of a node to ensure that a downward route can
be
> derived to the node. Without DAO ACKs the RPL exchanges between these
> participating entities (node, DAO Parent(s), root) are all implicit.
> 
> 
> With local DAO caches, individual DAOs travel only one hop, making
them
> more reliable.  On the other hand, receiving a downward message does
not
> function as a DAO ACK, because it does not show that the parent has
the
> complete current DAO.
> 
> [RA] Agreed. In the case of caching nodes the communicating RPL
entities are
> the node and its DAO Parent(s). In this case the model should be one
of
> explicitly acknowledged DAO exchanges.
> 
> [RA] In the interest of simplicity and compactness I do favor
requiring the
> DAO to be explicitly ACKed without a flag. I support Richard's
suggestion of
> tying the capability to the caching/non-caching mode of operation.
>