Re: [Roll] Semantics of DAO ACK

> On 09 Nov 2015, at 15:20, Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
> 
> Hello Michael
> 
>> {this was left in my drafts on home desktop folder from before IETF94, sorry for
>> the lack of timelyness}
>> 
>> Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
>>> * We could use the status as an enumeration the way people probably
>>> expect it. But you'll note that we did not create a registry for it.
>> 
>>> * 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.
>> 
>> I think that we need to pick one or the other.
>> I can imagine ways to do both, using some bits for each, but I'm not sure that it's
>> that useful.
>> 
>> I think the question is: what can we reasonably expect downstream (>rank)
>> nodes to do
>> with this information?   I think we should come at this the other way.
>> 
>> Forget what's in the DAOACK right now, and figure out what the downstream
>> node needs to know, and then let's figure out how to either adapt what we
>> have, or extend/replace it.
> 
> Looks good
> 
>> 
>>> 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.
>> 
>> I think we absolutely need to know when a storing node can't accept all the
>> routes.  But then what?  I'm not sure if we can actually split the targets across
>> parents... but well... can we?  I can't think right now of a reason why it wouldn't
>> work.
> 
> In the initial RPL we had the expectation that the nodes are always dimensioned to have sufficient room and that expectation avoided that sort of question; but it made the whole storing mode questionable at the same time. 
> 
> Say there are limits to the memory in a storing mode node that may be hit occasionally. The child that cannot get a route installed via a parent would try via another. 
> 
> Questions
> - what if none of the parents has room? 
> -  what if a common granddad does not have room so there is no way to reach the root? The route will not be installed and the target does not even know. This is where Joakim's recursion comes into play with nested DAO acks (if I understand well). But maybe it would be good that the DIO recursively expresses that the nodes have at least one parent with room for new routes.

Yes, we have a design where DIO include information (metrics container)  about number of neighbors available locally + number of routes free
all the way up to the RPL root. If this is available in DIO’s the joining node can do load-balancing by itself and join where it seems most welcome to
join. (We have an initial implementation of this but have not tested it in large scale yet).

Best regards,
— Joakim Eriksson, SICS

> Take care;
> 
> Pascal
> 
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll