Subject: Re: [Roll] New Version Notification -draft-ietf-roll-minrank-hysteresis-of-07.txt

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sun, 8 Apr 2012 19:00:57 +0200

Phil:

It is an implementation decision as long as it does not lead to interop
issue or unwanted behavior, which is probably the case here.
RFC 6550 demands that a node can't stray from the best Rank as computed
amongst parents by more than MaxRankIncrease.
This 3 clauses do not seem to capture this that we are discussing do not
seem to capture this. 
With (my reading of) the text as it stands, it seems that the
implementation has all freedom to select parents and then is given rules
to compute a Rank. 
The resulting Rank could be anything if the parent set as no constraint.

In particular  " The largest  calculated Rank among paths through the
parent set, minus MaxRankIncrease" must be less that the Rank obtained
from the preferred parent, not the final computed Rank.

The node should:
1) Compute the Ranks form its parent set. 
2) Determine a preferred parent as resulting with the lowest Rank (using
the computation described in the previous paragraph)
3) Determine which parents generate a Rank that is between that lowest
Rank and MaxRankIncrease
4) Pick a set of parents between those 

What do you think?

Pascal

-----Original Message-----
From: Philip Levis [mailto:[email-masked]] 
Sent: samedi 7 avril 2012 16:58
To: Pascal Thubert (pthubert)
Cc: Matteo Paris; [email-masked]
Subject: Re: [Roll] New Version Notification
-draft-ietf-roll-minrank-hysteresis-of-07.txt

On Apr 6, 2012, at 11:18 PM, Pascal Thubert (pthubert) wrote:

> The point is that with this clause the node selects its parents first 
> and its Rank second. The spec recommends picking a preferred parent 
> first, computing the Rank based on the preferred parent, and then only

> consider any node with a lower floor as an acceptable parent. I 
> understand that want to allow reversing that operation, but then that 
> should be an option and text should indicate that using it may augment

> the parent set for some nodes but end up reducing it for others.

Don't you think this is an implementation decision? I tried to write the
specification text to be completely neutral on this matter (as some of
the MRHOF discussions have gone into). The input to DIO generation is a
preferred parent and a parent set; how those two are selected is
complete outside the specification with the caveat that it places some
constraints (MaxRankIncrease).

Phil

---

From: Federico Consoli <[email-masked]>
Date: Mon, 09 Apr 2012 09:49:45 +0200

Hi, IMHO I think that if you use MaxRankIncrease it's because you *want* 
a particular behavior of RPLand especially you *want *that:

"If a node's Rank were to be higher than allowed by L + DAGMaxRankIncrease,
when it advertises Rank, it MUST advertise its Rank as INFINITE_RANK."

If you calculate the parent setas you wrote in step 3 you simply avoid 
this (wanted) behavior; in fact I can also say:
"If you use MaxRankIncrease this relation 
MAXRankIncrease>MAX_PATH_COST+MAX_LINK_METRIC must be true." and I 
"fixed" the problem.

I think that if you want to put a constraint on the parent-set it can 
not be MaxRankIncrease but it should be another variable/constraint.

-- 
Regards
Consoli Federico

> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Philip Levis <[email-masked]>
Date: Mon, 9 Apr 2012 08:46:05 -0700

> 4) Pick a set of parents between those 

This is an implementation decision. I can imagine other algorithms, e.g., where if the best Rank and next best Rank differ by more than MaxRankIncrease, the node chooses to advertise a worse Rank than the preferred parent provides.

Phil

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 10 Apr 2012 08:10:29 +0200

Phil:

It's not. 
If I switch a device with another from a different vendor I should
expect the new device to interact properly with existing devices and I
should expect globally a similar behavior in my network. 
That's what standards are for.

RPL 3.7.1 gives strong directions to avoid greediness. You may allow to
stray from that but that must be under control of the admin and you must
give strong recommendations for the default behavior.

Cheers,

Pascal

-----Original Message-----
From: Philip Levis [mailto:[email-masked]] 
Sent: lundi 9 avril 2012 17:46
To: Pascal Thubert (pthubert)
Cc: [email-masked]
Subject: Re: [Roll] New Version Notification

On Apr 8, 2012, at 10:00 AM, Pascal Thubert (pthubert) wrote:

> Phil:
> 
> It is an implementation decision as long as it does not lead to 
> interop issue or unwanted behavior, which is probably the case here.
> RFC 6550 demands that a node can't stray from the best Rank as 
> computed amongst parents by more than MaxRankIncrease.
> This 3 clauses do not seem to capture this that we are discussing do 
> not seem to capture this.
> implementation has all freedom to select parents and then is given 
> rules to compute a Rank.

> 2) Determine a preferred parent as resulting with the lowest Rank 
> (using the computation described in the previous paragraph)

> 4) Pick a set of parents between those

This is an implementation decision. I can imagine other algorithms,
e.g., where if the best Rank and next best Rank differ by more than
MaxRankIncrease, the node chooses to advertise a worse Rank than the
preferred parent provides.

Phil

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 10 Apr 2012 09:06:46 +0200

Hi Frederico :

My scenario is just a high level direction and does not intend to be
Phil's final text. I used that to illustrate the difference between my
expected behavior and my reading of the current text. 

You'll also note that my text mandates that the preferred parent it the
one that results with the lowest resulting rank, which is an OF decision
and could be done differently here.

Semantically speaking, you're probably right. It will be cleaner if the
OF cares to define the max Rank stretch between the least and worst
parent when computing the initial value for L.

I assumed it was simpler to just define the initial computation of L and
then live by the rules. But that could be confusing.

And I agree with your wanted behavior. That's the spirit of section
8.2.2.4 item 3 in RPL. A next sentence could be that if the node is
unhappy with the resulting parent set it may advertise infinite and pick
any parent. 

But that must be exceptional, like for nodes that do not want to be a
router anyway. I trust that if this is generalized then the greedy
misbehavior (see section 3.7.1) will become apparent.

For instance, if we add a router that sees 2 existing routers, with
Ranks far apart, what do we expect?  Does that depend on the metric? 

If the new node bases its Rank on the worst of the 2 existing routers,
it will be mostly unusable as a parent => adding a new node will fail to
improve connectivity for others.

RPL provides hints for that and indicates that the preferred parent
gives the sense of the position in the graph. Though it's up to the OF,
L is naturally the calculated Rank via the preferred parent:

8.2.3.1. DIO Message Processing

<...>

The most preferred parent should be used to restrict which other

nodes may become DODAG parents.

You'll note that the preferred parent does not necessarily mean that it
has the lowest resulting Rank, so it is up to the OF to define something
more complex than my scenario.

Cheers,

Pascal

From: Federico Consoli [mailto:[email-masked]] 
Sent: lundi 9 avril 2012 09:50
To: Pascal Thubert (pthubert)
Cc: [email-masked]
Subject: Re: [Roll] New Version Notification
-draft-ietf-roll-minrank-hysteresis-of-07.txt

Hi, IMHO I think that if you use MaxRankIncrease it's because you want a
particular behavior of RPL and especially you want that: 

"If a node's Rank were to be higher than allowed by L +
DAGMaxRankIncrease, 
when it advertises Rank, it MUST advertise its Rank as INFINITE_RANK."

If you calculate the  parent set as you wrote in step 3 you simply avoid
this (wanted) behavior; in fact I can also say: 
"If you use MaxRankIncrease this relation
MAXRankIncrease>MAX_PATH_COST+MAX_LINK_METRIC must be true." and I
"fixed" the problem.

-- 
Regards
Consoli Federico

Phil:

The node should:
 
What do you think?
 
Pascal
 
-----Original Message-----
From: Philip Levis [mailto:[email-masked]] 
Sent: samedi 7 avril 2012 16:58
To: Pascal Thubert (pthubert)
Cc: Matteo Paris; [email-masked]
Subject: Re: [Roll] New Version Notification

	The point is that with this clause the node selects its parents
first 
	and its Rank second. The spec recommends picking a preferred
parent 
	first, computing the Rank based on the preferred parent, and
then only

	consider any node with a lower floor as an acceptable parent. I 
	understand that want to allow reversing that operation, but then
that 
	should be an option and text should indicate that using it may
augment

 
Phil

---

From: Philip Levis <[email-masked]>
Date: Tue, 10 Apr 2012 11:46:35 -0700

> That's what standards are for.

Disagree -- otherwise there is no room for improvement. What if all TCP implementations had globally a similar behavior to TCP pre-Van Jacobson? The purpose of a standard to specify the behavior that is necessary for correct interoperation, not complete and total behavior. This is ESPECIALLY true in a case where it's a new and growing area; it's a bit of hubris to assume you know and can specify exactly how everything should work.

Phil