Subject: Re: [Roll] [roll] #3: Need Clarification on Candidate Neighbor

From: Jonathan Hui <[email-masked]>
Date: Fri, 20 Nov 2009 08:01:50 -0800

Hi Mathilde,

I think the criteria for choosing as well as the maintenance of  
neighbors and candidate neighbors should be left out of scope of the  
core RPL specification.  While we could say that candidate neighbors  
are based on the set of REACHABLE neighbors, I don't think that really  
clarifies much since it doesn't define what a REACHABLE neighbor is  
and/or implies that it is defined by RFC 4861 which may not be the  
definition we want.

That being said, it might be appropriate to provide some suggestions  
or implementation guidelines within the appendix to identify important  
parameters to consider.  For example, some versions of the draft had  
words saying that both the link quality metric *and* confidence in the  
link quality metric should be considered when choosing candidate  
neighbors.  Confidence is important since link qualities are  
statistical values based on discrete samples over time.

--
Jonathan Hui

On Oct 28, 2009, at 7:51 AM, roll issue tracker wrote:

> #3: Need Clarification on Candidate Neighbor
> -------------------------------- 
> +-------------------------------------------
> Reporter:  jpv@…               |       Owner:  wintert@…
>     Type:  defect              |      Status:  new
> Priority:  major               |   Milestone:
> Component:  rpl                 |     Version:
> Severity:  Active WG Document  |    Keywords:
> -------------------------------- 
> +-------------------------------------------
> Question from Mathilde Durvy:
>
> Hi All,
>
> I'm trying to understand better the need for 'candidate neighbors'.
> My current understanding is that 'candidate parents' (RPL) are a  
> subset of
> 'candidate neighbors' (RPL) which are themselves a subset of  
> 'neighbors'
> (ND).
> My question is, do we really need to maintain 'candidate neighbors' in
> addition to 'neighbors' and 'candidate parents'?
> If yes what should be the data structure and corresponding fields for
> 'candidate neighbors'? Section 5.2.1 gives very little details...
> I have a feeling that 'candidate neighbors' could simply be the set of
> REACHABLE 'neighbors' and be associated with a DAG once they become
> candidate parents.
>
> -- 
> Ticket URL: <https://svn.tools.ietf.org/wg/roll/trac/ticket/3>
> roll <http://tools.ietf.org/wg/roll/>
>
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 20 Nov 2009 20:24:54 +0100

Hi Jonathan and Mathilde

>and/or implies that it is defined by RFC 4861 which may not be the

REACHABLE is a good starting point as long as we base our neighbor loss
detection on NUD. 
At least it is consistent. But we do want to be able to use other
neighboring mechanisms,
in that case the goal would be to have the equivalent of REACHABLE with
that mechanism
as opposed to stick to 4861's REACHABLE, of course.

>statistical values based on discrete samples over time.

We started discussing a companion Informational spec with recommendation
such as FSM.
We figure a number of things today that might be wrong. We made the
draft pretty 
Elastic to enable a large capability of tuning and adaptations to the
needs.

The risk of being too elastic and not enough specific being a lack of
interoperability 
and the possibility to make an implementation that plain does not work.
We are trying
to avoid that of course and I expect that the next rounds of review like
IESG will be
sensitive to that aspect.

Pascal

---

From: Jonathan Hui <[email-masked]>
Date: Fri, 20 Nov 2009 11:47:33 -0800

Hi Pascal,

> as opposed to stick to 4861's REACHABLE, of course.

My point is that 4861 NUD is most likely not what we want to maintain  
the neighbor set.  Just because a single RFC 4861 NUD fails doesn't  
mean we should remove the node as a candidate neighbor, and thus,  
candidate parent.  At the very least, we will need to better define  
what NUD really means in this space.

> sensitive to that aspect.

A large open hole I see today (which I have raised before) is that we  
lack a standard mechanism to estimate link qualities to neighboring  
nodes.  I think it is needed and the discussion hasn't even started  
yet.  But this mechanism should not be specified in the core RPL spec.

--
Jonathan Hui

---

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Sun, 22 Nov 2009 22:59:32 +0100

Hi Jonathan,

NUD is probably not appropriate for RPL neighboring concept. So we just
should use other means, which could by the way make use of NUD, plus
other things. Reachability as far as ND is concerned can also be updated
by external protocols (e.g. a reliable transport, this is from 4861)

Julien

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Jonathan Hui
> Sent: vendredi 20 novembre 2009 20:48
> To: Pascal Thubert (pthubert)
> Cc: [email-masked]
> Subject: Re: [Roll] [roll] #3: Need Clarification on 
> Candidate Neighbor
> 
> 
> Hi Pascal,
> 
> >> are based on the set of REACHABLE neighbors, I don't think that 
> >> really clarifies much since it doesn't define what a REACHABLE 
> >> neighbor is and/or implies that it is defined by RFC 4861 
> which may 
> >> not be the definition we want.
> >
> > REACHABLE is a good starting point as long as we base our neighbor 
> > loss detection on NUD.
> > neighboring mechanisms, in that case the goal would be to have the 
> > equivalent of REACHABLE with that mechanism as opposed to stick to 
> > 4861's REACHABLE, of course.
> 
> My point is that 4861 NUD is most likely not what we want to 
> maintain the neighbor set.  Just because a single RFC 4861 
> NUD fails doesn't mean we should remove the node as a 
> candidate neighbor, and thus, candidate parent.  At the very 
> least, we will need to better define what NUD really means in 
> this space.
> 
> >> or implementation guidelines within the appendix to identify 
> >> important parameters to consider.  For example, some 
> versions of the 
> >> draft had words saying that both the link quality metric *and* 
> >> confidence in the link quality metric should be considered when 
> >> choosing candidate neighbors.  Confidence is important since link 
> >> qualities are statistical values based on discrete samples 
> over time.
> >
> > We started discussing a companion Informational spec with 
> > recommendation such as FSM.
> > draft pretty Elastic to enable a large capability of tuning and 
> > adaptations to the needs.
> >
> > interoperability and the possibility to make an implementation that 
> > plain does not work.
> > We are trying
> > to avoid that of course and I expect that the next rounds of review 
> > like IESG will be sensitive to that aspect.
> 
> 
> A large open hole I see today (which I have raised before) is 
> that we lack a standard mechanism to estimate link qualities 
> to neighboring nodes.  I think it is needed and the 
> discussion hasn't even started yet.  But this mechanism 
> should not be specified in the core RPL spec.
> 
> --
> Jonathan Hui
>