Re: [Roll] Semantics of DAO ACK

[Csaba Kiraly <[e-mail]>]

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.
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.
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.

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.

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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/roll
>
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll