Re: [Roll] updating DAO caches (was Re: Something to ADD)

[Jerald.P.Martocci at jci.com]

Hi Jonathan,

I am conflicted with the idea of discounting
P2P messaging in this document in lieu of some future document.  I
am completely with you that if there will be no attempt to fix the current
P2P in RPL then we should deprecate it.  What RPL currently documents
for P2P communication simply won't meet the requirements specified (at
least within the commercial building market).  On the other hand,
if we pull P2P out of RPL, I'm afraid it will never get defined. 

In Geneva we discussed that as we complete
the MP2P protocol and move it toward true implementations, it will be apparent
that even for this presumably unidirectional protocol, these collection
networks will still need to application ACK the packets to assure that
the packet has been successfully delivered to its destination.  Therefore.
even MP2P networks will need a robust means to move packets outward down
the DAG; and hence, it would be short-sighted to postpone this to a future
draft.

Unless those folks requiring MP2P communication
are willing to use a protocol that does not support guaranteed delivery,
I think we best work this out within the confines of this current document.

Jerry

Jonathan Hui <jhui at archrock.com>
Sent by: roll-bounces at ietf.org

11/17/2009 02:50 PM

To	Roger Alexander <roger.alexander at ekasystems.com>
cc	"roll at ietf.org" <roll at ietf.org>
Subject	Re: [Roll] updating DAO caches (was Re:  Something to ADD)

Hi Roger,

On Nov 17, 2009, at 12:25 PM, Roger Alexander wrote:

> The conclusions drawn are not entirely valid in part due to the  
> particular example given. Quite often the examples used to  
> demonstrate the protocol are of necessity simpler ones but may not
 
> capture the larger variety of connectivity seen particularly in  
> larger multihop networks. I will try to make the case using a  
> slightly more complex network graph which illustrate the benefit of
 
> intermediate state storage and how it might work without explicit
 
> indications of which note are maintaining state.

A fair characterization is that the change in down route state must be
 
reflected up until there is a common ancestor that provides  
connectivity both before and after the change in connectivity *and*  
can store down routes.  In the example that Richard provided, A was
 
the common ancestor and it also happened to be the root.  But it is
 
also true that nodes within the sub-DAG of A must update their DAO  
routing state to reflect the change in topology.  As Richard's example
 
points out, when you allow nodes to chose whether they can store down  
route state, nodes within the sub-DAG must assume the worst case and  
originate their own DAO messages in case nodes between it and the  
common ancestors cannot maintain down routes.

That said, the cost savings of having storage at intermediate nodes  
depends mostly on the depth of the common ancestor - a common ancestor
 
with greater depth will result in less transmissions that propagate  
information towards the root.  Of course, in the worst case, the  
common ancestor will be the root.  An unfortunate edge case with  
hierarchical structures is that the common ancestor of you and your  
neighbor could be the root.

I think it is fair to say that the current DAO caching capabilities  
specified in the RPL doc need quite a bit more thought before I would  
be comfortable with putting it into the base specification.  If there
 
is a way to treat it as an optimization, I would prefer to do so and  
work on that in a separate draft.

--
Jonathan Hui

_______________________________________________
Roll mailing list
Roll at ietf.org
https://www.ietf.org/mailman/listinfo/roll