> On 30 Sep 2015, at 06:44, Csaba Kiraly <kiraly@fbk.eu> wrote:
> 
> Hello Joakim,
> 
> I have also worked on the Contiki DAO-ACK code, enabling ACKs, implementing fixes to the DAOSequence handling, and looking into multiple targets.

Nice, I have a PR on Contiki now with what we have been doing to get Contiki RPL more scalable (but still only single targets / paths).

> What Cenk is saying sounds a reasonable hack, but the standard itself is in my opinion a bit underspecified for the semantics of DAO-ACK messages in several ways.

Yes, it is underspecified. There is need for clarifications and more details on the DAO / DAO ACK!

> My preferred solution for ACKing DAO messages with multiple targets would be to have support for the same semantics that you would have had with one DAO message per Target, i.e., I would prefer an option field that gives an individual status for each Target.

Yes, but that would require more memory in the sending node to keep track of things or full specification of the target in the response.
I guess it might be solved by allowing multiple DAO ACKs for the same DAO and to have the Target options included in the DAO ACK.

> 
> To give another example of subtle problems with DAO-ACK, it was not clear to me whether I want my implementation to ACK when the Target is added to the routing table, or only when this node itself receives an ACK for the same Target from its parent. Both makes sense, with the former giving a quick one-hop ACK, while the latter works as an end-to-end ACK, ensuring that the path is actually built. Both look conformant to the standard, but I suppose the original author was thinking of the former, and I can easily see interoperability problems arising between two implementations using different semantics.
> 
We did go for the end-to-end ACK to achieve better scalability. There is to me no point having a route to the parent if it is not possible to
get it all the way to root. But I totally agree - this is not obvious from the RPL RFC either.

Do you have your Contiki code somewhere in the open-source?

Best regards,
— Joakim

> Best regards,
> Csaba
> 
> On 29/09/15 23:08, Cenk Gündogan wrote:
>> Hello Joakim,
>> 
>> This is an interesting question and I also couldn't find any answers in RFC 6550.
>> However, my thoughts on this are as follows:
>> Since a sub-set of the announced RPL targets could have been accepted before filling up
>> the routing table (e.g.), I would choose a status code between 1 and 127.
>> I would expect a node to choose another parent if a more aggressive status code is received ([128-255]).
>> But a full routing table can have free space again until the next or any subsequent DAO arrives ..
>> therefore I prefer a "mild rejection" with a status code of [1-127].
>> 
>> To give some feedback to the originator of the DAO, it might be sensible to copy the
>> rejected RPL Target options from the affected DAO to the DAO-ACK, so that the originator is fully
>> aware of which Target prefixes got rejected (and which ones got accepted, implicitly).
>> I would choose this method, because it doesn't require the originator of the DAO to save any extra state
>> about the DAO and its contents.
>> 
>> Nonetheless, everything I wrote is nonconform and I am also interested in the RPL experts' opinions
>> and solutions.
>> 
>> Best,
>> Cenk
>> 
>> On 29.09.2015 21:44, Joakim Eriksson wrote:
>>> Hello All,
>>> 
>>> I have spend quite some time to get a more stable implementation of DAO handling
>>> for Contiki RPL and I am currently looking into DAO aggregation. But I realised that
>>> it is for me not 100% clear what a node that receives a DAO with several prefixes to
>>> be registered but can only accept a sub-set of them. Should it be a DAO_NACK in
>>> this case or is there any other way to handle that case?
>>> 
>>> If each would have been sent separately it is obvious that the receiving node can
>>> do a NACK when the routing table is full and therefore it is possible to get fine-grained
>>> answers. But with aggregation of DAOs this is not the case.
>>> 
>>> Any ideas?
>>> 
>>> Best regards,
>>> — Joakim Eriksson, SICS
>>> _______________________________________________
>>> Roll mailing list
>>> Roll@ietf.org
>>> https://www.ietf.org/mailman/listinfo/roll
>> 
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
> 
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll