Re: [Roll] Semantics of DAO ACK

[Csaba Kiraly <[e-mail]>]

On 30/09/15 17:55, Joakim Eriksson wrote:
>> On 30 Sep 2015, at 06:44, Csaba Kiraly <[e-mail]> 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.
This is a compromise to consider for sure. If you look at my 
implementation, you can see that I use the routing table entry to match 
the DAO ACK, and I keep only DAOSequence (SEQ) as extra state. I'm not 
sure it would work in all cases, but it did work for the case I 
considered. I'm keeping only the SEQ, and I think this is a must if you 
have no aggregation, and you want to match in case you forward multiple 
DAOs before getting the ACK or timing out on it. In fact, simply 
enabling ACKs in the original code was messing up the match between DAOs 
and their ACKs because it wasn't even keeping track of the DAO sequence 
numbers.

If you do aggregate ACKs, or you have more complex Target+Transit 
scenarios, the game changes, and I don't know what would be the balance 
between state you have to keep anyway and state you keep just to be able 
to interpret a later ACK correctly. I think it is implementation 
specific, so my suggestion would be a flag to indicate whether you 
request full ACK (bumping back all T+T info for rejected entries in the 
DAO) or a much smaller partial ACK with SEQ and similar IDs only. This 
flag (lets call it F for now), could go right next to K. As the DAO 
propagates, each node could set F based on whether it is able to store 
and/or reproduce info (F not set) or chose to remain stateless (set F ). 
This would exclude aggregation in the DAO-ACK sent down, but still allow 
for aggregation in the DAO sent up.

>
>> 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 mean end-to-end ACK as in non-storing, or end-to-end ACK in the 
sense that it is still addressed to the next hop but you delay ACK till 
you know your parent (and all its parents) ACKed?

>
> Do you have your Contiki code somewhere in the open-source?
I did some cleanup and pushed the clean part of the code to github: 
https://github.com/cskiraly/contiki/tree/DAO-NACK
It is not yet rebased to the latest master, but it should apply. I 
suppose describing it would be too off-topic for the list.
There is also the more experimental part of the code in a PR, if interested.

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