Re: [Roll] Semantics of DAO ACK

[Joakim Eriksson <[e-mail]>]

> On 01 Oct 2015, at 22:03, Csaba Kiraly <[e-mail]> wrote:
> On 30/09/15 18:06, Joakim Eriksson wrote:
>>> On 30 Sep 2015, at 09:58, Pascal Thubert (pthubert) <[e-mail]> wrote:
>>> * Which hints you that we could also use it as a metric. A scalar degree of unwillingness to serve as a parent, that accounts for stuff like memory, available time slots in a chunk (for 6TiSCH) and/or battery depletion of the node. The status would translate in such things as serving as alternate but not as preferred parent.
>> Not sure that degree of unwillingness can be specified in a clear way so that everybody will interpret it the same way. But
>> sure - it is an option. I have done a “quick hack” and defined 255 as “Root is out of routes”. Because if you get that type of
>> response - there is no immediate need to look for another parent and another path - it will not work anyway… (that is if the
>>  node is desired to get a path all the way to/from root).
> We did some tries with the memory aspect, and it is not bad, but not too good either. The information is simply not coming in at the right moment for a good decision logic. As Joakim said, squeezing it into one byte could also be too tight, and interoperability could be hindered. Would it be an absolute value with equations in the standard? If not, how would I confront the values received from two different implementations? How would I know that they are different and not comparable, in the first place?
> 
> I think it is better to keep the status as an enumeration, but also keeping the high level semantics, like now, so that implementations that do not know the enum have some default behavior. BTW, 127 is specified both for partial and for outright reject in RFC6550. For the enum values, we differentiate 2 cases now, and we have different decision logic for them.
> 
> I think it is a good idea to send the metrics you have described, but a DAO option or some DIO option is a better match.
> 
>>> For more selective stuff, we would have to indicate the problem in the dao-ack per route advertisement that is a problem. This is a step that we did not take with RFC 6550, people advising that the draft was workable and thick enough without it.
>>> 
>> Yes, and we were tired of writing more I guess - and eager to implement ;-)
>> 
>>> The path that is really accepted in storing mode is self as a transit for a given target. Transit can be aggregated for multiple targets. And there can be multiple transits for a target. The DAO Ack could include the pairs (transit/target) that are trouble  and indicate for each what the trouble is. It could in theory aggregate what's aggregatable, but the way the info in the dao ack is aggregated may have to differ from what was placed in the DAO.
>> Yes, the thing with todays RFC is that there is not yet any defined options for the DAO ACK - but that is of course easy to add. One other option
>> would be to add a flag into the DAO that says “all-or-nothing”. If it is set all routes or no-routes should be installed. It is a bit complex possibly but
>> it would be very clear when the DAO sending node gets the ack what happened. < 128 means all routes are installed. >=128 means none was
>> installed.
> I think all-or-nothing flag is a good idea, and relatively easy to implement.
> 
>>> The path control delegates a right to propagate and eventually fan out the advertisement. If the T+T pair is placed in the dao ack, the path control could be used to refuse that right to propagate, so the child would be free to offer that particular pair to an alternate parent. We still have bits in the transit that could indicate stuff if we need it as well.
>> Yes, but I my case I am doing the simple case of just registering with one single parent / one single DAO path per target.
>> 
>> 
>> My current “plan” is to avoid aggregation when doing the regular DAO but possibly aggregate the no-path DAO since that one
>> can not possibly cause out-of-memory or other problems (or?).
>> 
> This reminds me that the status code is not yet defined for No-path, right? It can be interpreted, but the text for 1-127 and 128-255 doesn't really apply. I'm not sure asking for an ACK on a no-path would makes sense, but the option is in the standard, and behavior is unspecified.

I think we do request the ACK on no-path but do not retransmit. I guess the only interpretation is “Yes the no-path was received” so I agree - only the unconditional accept seems like a valid answer. It is also forwarded but no wait for the “end-to-end” no-path before sending the ACK. Retransmitting
no-path might make sense if the packet got lost - just to ensure that the route is fully removed and no “memory leakage” is caused (but if feels that
is not going to happen that often).

Best regards,
— Joakim Eriksson

> Best regards,
> Csaba
> 
>> Best regards,
>> — Joakim
>> 
>>> Thoughts?
>>> 
>>> Pascal
>>> 
>>>> -----Original Message-----
>>>> From: Roll [mailto:[e-mail]] On Behalf Of Cenk Gündogan
>>>> Sent: mardi 29 septembre 2015 23:08
>>>> To: [e-mail]
>>>> Subject: Re: [Roll] Semantics of DAO ACK
>>>> 
>>>> 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
>> 
>> 
> 
> 
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll