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

["Roger K. Alexander" <roger.alexander at ekasystems.com>]

> -----Original Message-----
> From: roll-bounces at ietf.org [mailto:roll-bounces at ietf.org] On Behalf Of
> JP Vasseur
> Sent: Thursday, November 19, 2009 5:37 AM
> To: Jonathan Hui
> Cc: roll at ietf.org
> Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD)
> 
> 
> On Nov 17, 2009, at 5:38 PM, Jonathan Hui wrote:
> 
> >
> > On Nov 17, 2009, at 8:12 AM, Richard Kelsey wrote:
> >
> >>> From: Roger Alexander <roger.alexander at ekasystems.com>
> >>> Date: Mon, 16 Nov 2009 15:33:33 -0800
> >>>
> >>> Not clear why there is a need to know who records DAOs. In
> >>> response to
> >>> a new child a parent that does maintain state will add itself to
> the
> >>> path information from the child and pass that information to it's
> >>> parent. That information will pass inward towards the root until a
> >>> node is encountered that can store the path information and
> >>> previously
> >>> supported connectivity to the node at the same cost.
> >>
> >
> > [nice example of what DAOs need to be sent]
> >
> >> In the first case a single DAO needs to be sent.  In the
> >> second case D has to send two DAOs and the nodes in its
> >> subdag, just E here, each need to send one.  If only the
> >> root caches DAOs then the first case always applies.  If
> >> other nodes may cache DAOs, then we have to assume that we
> >> are in the second case after every move.
> >
> > I was in the process of creating a similar example.  All I'll add is
> > that, intuitively, the more places state gets "replicated" within
> > the network, the more costly it is to maintain that state and the
> > more you have to deal with inconsistencies between replicated
> > instances.  Of course, the hope in replicating this routing state is
> > that it creates shorter paths and ultimately offsets the cost of
> > maintaining that state.
> >
> > 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.  It seems
> > like a mediocre attempt to optimize point-to-point routing and
> > something that folks wanting P2P support aren't satisfied with.  If
> > that is the end-goal, then we should be developing better
> > mechanisms.  For now, we are focusing on one-to-many and many-to-
> > one.  And, I see more benefits to simply maintaining state at the
> > root.
> >

I think even if the current focus is one-to-many and many-to-one, a default
capability that allows less than optimal one-to-one routing is still
worthwhile. Particularly in the context of larger networks in which nodes
are not state-constrained, there will be latency and traffic benefits by
avoiding always having to loop all traffic through the root. Furthermore,
that default routing comes without the need to, as yet, introduce any
special mechanisms.
  
> 
> 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. 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.
> 
> > --
> > Jonathan Hui
> >
> > _______________________________________________
> > 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