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

[Geoff Mulligan <geoff at proto6.com>]

While I agree that in most networks you would want to store DAOs so that
you can send packets in both directions, I can also see networks that
likely just collect data from sensor end-nodes and DAOs would be
unnecessary.

But I agree with Richard, that for many P2P applications even storing
DAOs will not provide even a "good enough" P2P route and that some other
alternative routing mechanism/protocol is necessary.

	geoff

On Thu, 2009-11-19 at 15:55 +0100, Julien Abeille (jabeille) wrote:
> Hi JP, all,
> 
> I agree that we should keep DAOs in RPL. A routing protocol that
> installs routes in one direction only makes no sense to me. By the way
> if in a deployment some do not want to store DAOs, they can.
> 
> Best,
> Julien
> 
> > -----Original Message-----
> > From: roll-bounces at ietf.org [mailto:roll-bounces at ietf.org] On 
> > Behalf Of JP Vasseur (jvasseur)
> > Sent: jeudi 19 novembre 2009 13:19
> > To: Richard Kelsey
> > Cc: roll at ietf.org
> > Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD)
> > 
> > 
> > On Nov 19, 2009, at 12:01 PM, Richard Kelsey wrote:
> > 
> > >> From: JP Vasseur <jvasseur at cisco.com>
> > >> Date: Thu, 19 Nov 2009 11:36:49 +0100
> > >>
> > >> On Nov 17, 2009, at 5:38 PM, Jonathan Hui wrote:
> > >>
> > >>> I'll have to admit that I'm not yet convinced of the benefits in 
> > >>> storing DAO state as it currently exists in the draft.  [...]
> > >>>
> > >> I do agree with the first statement but not with the second 
> > >> paragraph.
> > >> I do see several deployment cases where no storing DAO 
> > would lead to 
> > >> extremely sub-optimal paths and even more importantly traffic 
> > >> congestion when getting closer to the root of course.
> > >
> > > Can you share these cases with us?  I agree with Jonathan 
> > that storing 
> > > DAO states will typically not provide much improvement in 
> > P2P routing.
> > 
> > Sure. I'll take the example of an inter primary+secondary 
> > substation network (could be the smart metering network) that 
> > supports traffic for various purposes:
> > meter read-out, DA alarms, ... etc. Thus traffic of various nature:  
> > P2MP, MP2P
> > and P2P. There are many such networks where not storing DAO 
> > just does not work since all P2P traffic will have to transit 
> > via the root (unacceptable delays for
> > alarms) and the traffic around the root will be way too high.
> > 
> > This is why I am saying that having an RFC that forms a DAG 
> > that cannot be used for outward traffic is a non-starter.
> > 
> > >
> > >> I do see several deployment cases where no storing DAO 
> > would lead to
> > >> extremely sub-optimal paths and even more importantly traffic
> > >> congestion when getting closer to the root of course. This is true
> > >> with several networks where the amount of P2P traffic may ned up  
> > >> being
> > >> not so negligible. The beauty with the current spec is 
> > that it allows
> > >> both deployment models.
> > >
> > > It claims to allow both, but fails to actually do so.  That
> > > is the point of the example that I gave and the reason I
> > > keep going on about this.  While the draft says that
> > > intermediate nodes can cache DAOs, it doesn't say how those
> > > caches are updated after a node changes parents.  And
> > > however this is done, we need to avoid the cost of sending
> > > cache updates in the absense of any actual caches.
> > 
> > Yes I agree with you on this and this is why DAO packing is also  
> > important.
> > Thus I would propose to all work on this and make it work 
> > while still  
> > allowing
> > some nodes to not store any DAO is they want to of course.
> > 
> > Does that make sense ?
> > 
> > Cheers.
> > 
> > JP.
> > 
> > >
> > >                                 -Richard Kelsey
> > 
> > _______________________________________________
> > Roll mailing list
> > Roll at ietf.org
> > https://www.ietf.org/mailman/listinfo/roll
> > 
> _______________________________________________
> Roll mailing list
> Roll at ietf.org
> https://www.ietf.org/mailman/listinfo/roll