Re: [Roll] Semantics of DAO ACK

> On 09 Nov 2015, at 09:27, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
> 
> 
> {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.
> 
>> 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.

The only reason for it not to work is complexity of deciding how to split, etc.
I guess it might add complexity. We did a very basic approach that avoids
aggregating all the DAO’s since all the nodes in between never need to handle
splitting, aggregation, ACKs, etc. The end-to-end ack is in our case very much
driven by the node that needs the downward route (e.g. retransmissions, trying
new-path, etc). There are optimisation that can be made since some nodes 
on the path to Root might have more knowledge about alternative paths, etc. But
I think we need to figure out a specification of this that allow for both simple cases
and non-complex implementation as well as for more complex with aggregation
and splitting of targets across parents, etc. 

Best regards,
— Joakim Eriksson, SICS

> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 
> 
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll