Re: [Roll] some comments on draft-thubert-dao-projection-00.txt

["James Pylakutty (mundenma)" <[e-mail]>]

Hi Michael,



Thanks a lot for the comments.



See my responses below.

Thanks

-james

Michael Richardson <[e-mail]<mailto:[e-mail]>>, wrote:



<Chair hat off>



Pascal, thank you for this document.

I especially appreciated your figure 2, the way that you numbered the nodes with their gross rank as the tens part.



You write on page 8:

   The root sends the DAO directly to the last node in the segment,

   which is expected to be able to route to the targets on its own.



It would be good to make it clear which direction one counts the "segment"

to know which one is last.  I don't like "segment" here, I think it's a routing path...  Could you define segment if you think it's the most natural term to use.

(There are also some articles like "the" missing in places, btw)



JP> The term segment may be overloaded, it will be good to use more specific name like 'projected route' instead. We can also use the terms "egress node" and "ingress node", rephrasing the "last node" as "egress node". The root sends the projected DAO to the egress node of the projected route. The DAG root knows that the egress node has  route to the target(s), either because it is a parent in the non-storing DAO received from the targets, or because another projected route was installed by the root from that point, or by some other unspecified means.

JP> The projected route information is then signaled hop by hop upward (like the storing mode DAO) through the nodes of projected route listed in the Via information. The ingress node of the projected route is the node that finally sends the positive DAO-ACK to the root.

JP> The projected DAO is what DAG root sends to egress node, non-storing DAO is what a node sends to DAG root, and storing mode DAO is what gets relayed hop by hop upwards.



Then you write:

   The node strips the last Via Information option which corresponds to

   self, and uses it as source address for the DAO to the predecessor.





I think that what is described, to use the numbering in your example, is that the root would send a message to 41, with a target=51, list of VIAs:11,22,31,41 and *then* 41 would send a DAO to 31, with a list of VIAs 11,22,31, etc.



It's the "then" above part that I *think* is a critical part of the protocol, and is perhaps not clearly spelled out.  I wasn't entirely sure if I read it correctly.


JP> That is correct, as shown in fig 2, but I agree we need to clarify.



In the case where nodes have different downstream and upstream addresses (because, for instance they had different radios), then there might be some confusion and maybe both hops should be listed.  I recall I posted a thread asking about that a year or so ago, but I don't recall what the conclusion was.


JP> The root indicates the sequence of next hop address. These are the addresses that are available on the interface of the child that connects to the parent. The node uses that address as source of its own DAO, which indicates it on which interface to send the DAO.



But, then in the example on page 9, after sending these Via-DAOs to

45 and 46, it says:

   The root

   may then send a DAO to node 35 indicating targets 55 and 56 a Via

   segment (13, 24, 35) to fully optimize that path.



While the root had initially optimized the 45/46 out the routing header with the first set of Via-DOAs (do you have a name for these messages?

Projected-DAOs? maybe), couldn't that set of DOAs have included 13,24 in the list as well?



JP> Yes, that is what is described in the very next paragraph. Let us use the term 'Projected-DAO" for the DAO root sends to egress node of the projected route.



Alternatively, could the root have sent a single Via-DOA with destination

*35* to 24, with the route 13,24?   That would have resulted in a routing

header like:

       ROOT -> 35

since 13 and 24 should be able to reach 35 in a loose source route, and 35 would know how to reach 55 and 56?


JP> That is correct.



****



in section 3.1, the description of the VIA extension, you write:



Option Length:  Variable, depending on whether or not Parent Address

         is present.



JP> Needs to be corrected as "Option Length:  Variable, depending on the length of Child Address field".





But the only variability I saw in the extension was whether the child address was 8 bytes or 16 bytes.  It seems that if you are going to optimize this, you might as well also offer an option for the Child Address to be 2 bytes (the last two bytes).



JP> Yes, we could. Let us look at proposing 6LoPAN compression (RFC 6282) in this case.  If it is necessary to integrate 6LoPAN compressed addresses, we can do that.



**** DAO



I don't fundamentally see a reason why DAO is used.  I guess it has the right properties, but I think that a new message type could be defined equally well (as well as a new ACK), even if it just replicates the exact DAO structure.  It seems that the ACK is mandatory (K=1).



I would prefer that DAOs always flow towards the root, and DIOs away.

It would make analysis of what is going on easier.

These DAOs in some way flow towards a node with root-like storing-like abilities, so I can see why it was elegant to reuse DAO for this.



JP: The positive ACK for projected DAO goes from ingress node of the projected route to the DAG root. It is possible we could use a non-storing mode DAO itself for this ACK purpose. Negative ACK for projected DAO goes from egress node/via node/ingress node to root. As such the mechanism is different from K=1. When K is set to 1, the recipient sends the ACK to the sender of the DAO, which may be different from what we want here.



**** incremental deployment



Use of a new MOP makes deployment of this a flag day.

I don't think that this is necessary, although some niggling doubt going back to the mixed storing/non-storing discussion of 2011 remains...



I think that the DAOs that come from nodes that are able to act as Route Projection nodes could indicate that capability, and furthermore, indicate the number of routing slots they currently have free.



It would be advantageous perhaps to explicitly number the routing slots.

My initial thought is that would permit the subsequent DAOs to perhaps include a count of how many times the Projected route was used: once the DODAG root pushes traffic away from the root with these projected routes, it can no longer count how much traffic is occurring, so it should get reports "from the field" so that it can decide whether to keep those routes.



Explicitly numbering the routing slots could be problematic I agree, but it would allow the DODAG to manage them directly rather than the implicit process that the VIA option's Path Sequence is doing.



The Path Sequence processing needs an example, btw.



JP: It appears that making use of capability is better than defining a new MOP. Possibly we can add an option to the non-storing DAO which can be used by a node to announce the projected DAO capability and to announce the max number of projected routes that can be supported.

Thanks

-james