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

From: Mukul Goyal <[email-masked]>
Date: Wed, 31 Mar 2010 14:09:29 -0500 (CDT)

Phil,

Cost of unidirectional link A->B may naturally be available at A or B or both depending on the definition of the link cost. A and B may even need information exchange before either determines this cost.

So when B receives a multicast DIO from A, B may know:

1) unidirectional cost A->B only or
2) unidirectional cost B->A only or
3) both or
4) none

So if selection of a DIO/DAO parent depends on the link cost and B does not already have the relevant cost (A->B or B->A) required to decide whether to choose A as DIO/DAO parent, we have a problem.

I think Pascal is saying that B should consider A as a candidate DIO/DAO parent only when B knows (or is willing to assume a value for) the relevant (A->B or B->A) cost for the link between A and B.

Earlier versions of the RPL draft did have some discussion of the distinction between a neighbor and a candidate parent. This discussion is no longer there.

The mechanism used to elevate a neighbor to a candidate parent status is clearly out of scope for the RPL draft. But, the draft should mention the properties that a candidate parent must satisfy. I think this is what Pascal is saying and I agree with it.

Thanks
Mukul

>>>> Mukul’s point stands. Sometimes, the Rank increment for the parent-child link depends on metrics that are available at the parent after communication from the child, so we might have a chicken and an egg problem in the parent selection. I think we need to refine our text on the link evaluation with candidate neighbors that enables a neighbor to become a candidate parent in the first place.   
> 
> 
> 
> 
> [Phil]The child gets to pick the parent. Note that link metrics can persist across DODAG iterations. I'm not sure I understand the problem? 
> 
> 
> 
> 
> [Pascal] If the child needs link metrics that the parent gathers upon messages from the child, then the parent cannot place them in the first mcast DIO. Some unicast communication must come first to assert the link quality and exchange the perceptions from both ends. At that point, the candidate neighbor becomes a candidate parent. In 07 and I think we lost a lot of that discussion and se do not even define what candidate parents and neighbors are. I think we need a few words to explain what we expect from the out-of-scope neighboring mechanism that does a metric aware NUD of some form. 
> 
> 
> I totally agree.

[Phil] I still don't understand. Is the assumption that the only messages used for link metric calculation are RPL messages? How could a node N send unicast RPL messages to a DIO parent P before having an estimate of the link N->P? Such an estimate would have required that N send packets...

This is the basic link metric bootstrapping problem: to measure the link A->B node A must send messages to B (either as unicast or broadcast/multicast). The first transmission has zero knowledge of A->B. Link estimators use a variety of approaches, such as:

 1) A sends broadcasts/multicasts; B sends information on these messages back to A (DeCouto's and Woo's ETX)

 2) A measures B->A and assumes A-B is symmetric; it validates this by using A->B and observing the result (4B link estimator)

 3) A measures B->A and applies a very harsh filter to avoid intermediate links, assuming that an almost-perfect B->A implies A->B is at least very good (many RSSI/chip error approaches)

Your concern seems to be based on assuming 1) is in use? I'd argue we don't want to assume how the link metric estimator works and incorporate that assumption into RPL. It should be the link metric estimator's job to do its job given RPL's traffic, rather than RPL's job to generate traffic to support a link metric estimator. A link metric estimator can always generate its own packets if needed, after all.

Phil

---

From: Philip Levis <[email-masked]>
Date: Wed, 31 Mar 2010 12:22:42 -0700

> The mechanism used to elevate a neighbor to a candidate parent status is clearly out of scope for the RPL draft. But, the draft should mention the properties that a candidate parent must satisfy. I…

What properties are they? This sounds like an implementation decision to me. 

There seems to be a tension between writing the draft to tell coders how to implement the protocol and writing the draft to specify how the protocol works for the purpose of interoperability. I thought a Proposed Standard RFC is the latter? Implementation guidance seems like an informational RFC topic.

Phil

---

From: Michael Richardson <[email-masked]>
Date: Wed, 31 Mar 2010 15:49:54 -0400

>>>>> "Philip" == Philip Levis <[email-masked]> writes:
    >> The mechanism used to elevate a neighbor to a candidate parent
    >> status is clearly out of scope for the RPL draft. But, the draft
    >> should mention the properties that a candidate parent must
    >> satisfy. I think this is what Pascal is saying and I agree with
    >> it. 

    Philip> What properties are they? This sounds like an implementation
    Philip> decision to me.  

    Philip> There seems to be a tension between writing the draft to
    Philip> tell coders how to implement the protocol and writing the
    Philip> draft to specify how the protocol works for the purpose of
    Philip> interoperability. I thought a Proposed Standard RFC is the
    Philip> latter? Implementation guidance seems like an informational
    Philip> RFC topic. 

It's neither one or the other.

If we have done our job right, then the developers will understand
enough from the document to be able to write interoperable
implementations.

-- 
]       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.