Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs

From: "Anders Brandt" <[email-masked]>
Date: Thu, 8 Apr 2010 11:04:55 +0200

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Roger Alexander
> Sent: Thursday, April 01, 2010 01:04
> To: 'Mukul Goyal'; 'Richard Kelsey'
> Cc: [email-masked]
> Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs
> 
> Hi Mukul,
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > Of Mukul Goyal
> > Sent: Wednesday, March 31, 2010 5:59 PM
> > To: Richard Kelsey
> > Cc: [email-masked]
> > Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs
> > 
> > Richard
> > 
> > >For me there is one big difference, which is that using two
> > instances does not require any changes to the RPL draft.  
> We need to 
> > support multiple instances in any case, so using two instances for 
> > separate up/down routes does not add any new complications.
> > 
> > I am not sure about the comparative overhead of 2 RPL 
> instances versus
> > 1 instance. Are you sure this is not going to be an issue 
> for extreme- 
> > RAM limited devices that can afford to join 1 DAG but not 2?
> > 
> > I guess this is probably not going to be an issue since, 
> even if the 
> > metrics are significantly asymmetrical, a node can simply 
> choose all 
> > its DAO parents as DAG parents but not actually use them for upward 
> > communication.
> > 
> > I guess we need more opinions.
> 
> As indicated in my earlier response to Jonathan, it is 
> possible to consider two instances for separate upward and 
> downward routing but unless the intent is to allow for more 
> diverse objective functions, it may be possible with separate 
> directional metrics to use a single instance and so avoid 
> additional potential state and operational overhead.

+ 1

> 
> > 
> > Thanks
> > Mukul
> > 
> > 
> > > I think the two instance solution would make sense if we 
> stick with 
> > > the current constraint in rpl-07 that DAO parents must be 
> a subset 
> > > of the DAG parents (i.e. all DAO parents are also DAG parents).
> > 
> > Yes.  I am having trouble seeing how DAOs would work if DAO parents 
> > were not also DAG parents.
> > 
> > > Then all we need is a way to specify whether or not an 
> instance is 
> > > building upward routes, downward routes, or both.
> > 
> > I think a better way to put it would be to specify how 
> asymmetric link 
> > metrics are to be combined (downward value only, upward value only, 
> > max of the two, min of the two, average, ...).  I will ask 
> JP to open 
> > a ticket.
> > 
> > > The only other minor issue
> > > is whether we need to think through any cases where coordination 
> > > between the upwards and downwards instances is useful.  
> For example, 
> > > what needs to happen when packet delivery fails on the downward 
> > > route?  Does the error/backtracking happen on the same 
> instance or a 
> > > different instance?  Do we need to specify such behavior 
> in the core 
> > > spec?
> > 
> > Again, I do not see how this is different from other collections of 
> > instances.  What happens when a packet delivery fails on a 
> low-latency 
> > instance?  Does the error get forwarded on that instance or 
> some other 
> > instance?
> > 
> >                               -Richard Kelsey 
> > _______________________________________________
> > Roll mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/roll
> > _______________________________________________
> > Roll mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/roll
> 
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 12 Apr 2010 09:51:48 -0400

>>>>> "Richard" == Richard Kelsey <[email-masked]> writes:
    >> On Mar 31, 2010, at 2:23 PM, Richard Kelsey wrote:
    >> 
    >> > instances does not require any changes to the RPL draft.  We
    >> > need to support multiple instances in any case, so using two
    >> > instances for separate up/down routes does not add any new
    >> > complications.
    >> 
    >> I am not sure about the comparative overhead of 2 RPL instances versus
    >> 1 instance. Are you sure this is not going to be an issue for
    >> extreme-RAM limited devices that can afford to join 1 DAG but not 2?

    Richard> I was thinking more of complications in the spec and in
    Richard> implementations than of RAM usage.  If we are really
    Richard> concerned about devices having enough RAM for only a single
    Richard> instance, then we should work harder on simplifying the
    Richard> basic protocol.

If we can simplify the base protocol by seperating up/down, and that
reduces timers, code and the like, then is having a minimum of 2
acceptable? 

    Richard> In practice, I would expect severly limited devices to be
    Richard> used in constrained situations such that they would not
    Richard> need to implement the full generality of RPL.  In such a
    Richard> situation I do not think that there would be any significant
    Richard> difference in RAM usage between having two instances versus
    Richard> a single instance with multiple ranks, parent sets, and so
    Richard> forth.

Exactly.

- -- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.