Subject: [Roll] MRHOF draft-07 comments

From: Federico Consoli <[email-masked]>
Date: Wed, 28 Mar 2012 00:07:17 +0200

Hi, I have a doubt about the root's rank with ETX.
Assume I have 2 nodes A and B and I use ETX as metric with MRHOF:
A is root
B is non-root
Link between A and B has a cost of 256 (ETX=2)

A got rank of 256(2*,4*) and will annunce a path_cost of 0(1*,3*) in its 
DIO message in its advertised Rank value(6*).

B will receive a DIO with rank value = 0 so B will set his rank to 
256(7*) and will annunce a path_cost of 256.

But now I got 2 nodes with the same rank value. I think it's not a 
problem with the algorith of DODAG creation but it's not RPL complaint(5*).

(1*) MRHOF - Section 3.1
"Root nodes (Grounded or Floating) set the variable cur_min_path_cost to 
MIN_PATH_COST."
(2*) MRHOF - Section 3.3
"DAG roots set their Rank to MinHopRankIncrease."
(3*) MRHOF - Section 5.
"MIN_PATH_COST: 0. At root, the expected transmission count is 0."
(4*) RPL-RFC Section 17
"DEFAULT_MIN_HOP_RANK_INCREASE has a value of 256"
(5*) RPL-RFC Section 3.4
"the rank of the nodes must monotonically decrease as the DODAG version 
is followed towards the DODAG destination"
(6*) MRHOF Section 3.5.
"If ETX is the selected metric, a node SHOULD NOT advertise it in a 
metric container. Instead, a node MUST advertise an approximation of
its ETX in its advertised Rank value"
(7*) MRHOF Section 3.3
max(256+0,0+1,256-256) -> 256+0 -> 256

-- 
Regards
Consoli Federico

---

From: Philip Levis <[email-masked]>
Date: Wed, 28 Mar 2012 11:56:56 +0200

On Mar 28, 2012, at 12:07 AM, Federico Consoli wrote:

> A got rank of 256(2*,4*) and will annunce a path_cost of 0(1*,3*) in its DIO message in its advertised Rank value(6*).
> 
> B will receive a DIO with rank value = 0 so B will set his rank to 256(7*) and will annunce a path_cost of 256.
> 
> But now I got 2 nodes with the same rank value. I think it's not a problem with the algorith of DODAG creation but it's not RPL complaint(5*).

Good catch.

I think the issue here is the MRHOF draft is not clear: A (a root) should advertise a Rank of 256, and B, following 3.3, would advertise a Rank of 256 + MinHopRankIncrease (case 3 of 3.3).

This does get at a more fundamental issue, one where the rules on Rank and the rules on metrics can diverge. I'd argue that the text saying Root nodes set to MIN_PATH_COST should instead relate to MinHopRankIncrease; 3.3 was designed given the RPL specification, but I think the cur_min_path_cost clause is out of sync with it. What do you think?

Phil

---

From: Federico Consoli <[email-masked]>
Date: Thu, 29 Mar 2012 13:18:08 +0200

> This does get at a more fundamental issue, one where the rules on Rank and the rules on metrics can diverge. I'd argue that the text saying Root nodes set to MIN_PATH_COST should instead relate to…
Hi, thank you for your reply.

I think that if the root node advertise a Rank of 256 it means that it 
got a path_cost to the worst parent of 256 (1*), so it means that it got 
a ETX of 2 to the worst parent.
It's not RPL complaint(2*).
If instead we suppose that root send packet to itself, it means that the 
root can lost packet (ETX=2) to itself.
IMHO, a way to fix that (still assuming that root send packet to itself) 
is that root could advertise a Rank of 128 (ETX=1) so it got no loss to 
itself.
Anyway I don't like this fix.

I think that a goot fix is that a root set it's rank to 
MinHopRankIncrease and (only root) MUST use the metric container to 
carry ETX=0.

I think it's a pretty significant change in MRHOF but I have other 
ideas. What do you think?

(1*) MRHOF - Section 3.4
"...It then calculates the metric it will advertise in
its metric container. This value is the path cost of the member of
the parent set with the highest path cost..."

(2*) RPL-RFC - Section 8.2.1 - Rules 2
"A DODAG root MUST have a DODAG parent set of size zero"

-- 
Regards
Consoli Federico.

---

From: Philip Levis <[email-masked]>
Date: Thu, 29 Mar 2012 19:27:38 +0200

On Mar 29, 2012, at 1:18 PM, Federico Consoli wrote:

> I think that if the root node advertise a Rank of 256 it means that it got a path_cost to the worst parent of 256 (1*), so it means that it got a ETX of 2 to the worst parent.
> If instead we suppose that root send packet to itself, it means that the root can lost packet (ETX=2) to itself.
> IMHO, a way to fix that (still assuming that root send packet to itself) is that root could advertise a Rank of 128 (ETX=1) so it got no loss to itself.
> I think that a goot fix is that a root set it's rank to MinHopRankIncrease and (only root) MUST use the metric container to carry ETX=0.
> 
> I think it's a pretty significant change in MRHOF but I have other ideas. What do you think?
> 
> 
> 
> 
> (1*) MRHOF - Section 3.4

The RPL specification is what says the Rank value a root must advertise.

8.2.2.2 says
   2.  A DODAG root MUST advertise a rank of ROOT_RANK.

To some degree, absolute ETX values do not matter -- what matters is their relative values. If all DODAG Roots advertise a Rank of 256, corresponding to an ETX of 2, then that's what they advertise, and a route with an computed ETX of 5 involves 3 transmissions within the LLN.

I don't think I'm understanding the issue -- could you explain it again?

Phil

---

From: Federico Consoli <[email-masked]>
Date: Thu, 29 Mar 2012 19:55:14 +0200

>     2.  A DODAG root MUST advertise a rank of ROOT_RANK.
Yes. I agree with that. Root nodes got rank=256.
> I don't think I'm understanding the issue -- could you explain it again?
I don't agree that root nodes could advertise a ETX=2.

"Once the preferred parent is selected, the node sets its 
cur_min_path_cost variable to the path cost corresponding to its 
preferred parent. It then calculates the metric it will advertise in its 
metric container. This value is the path cost of the member of the 
parent set with the highest path cost."

Root nodes have parent set of size zero so they got a 
cur_min_path_cost=0 so ETX=0.

Because "a node MUST advertise an approximation of its ETX in its 
advertised Rank value" root nodes must advertise ETX=0.
I agree with the fact that absolute ETX do not matter but I think that 
the root advertisement does not match the definition in the MRHOF draft.

-- 
Regards
Consoli Federico

---

From: Philip Levis <[email-masked]>
Date: Fri, 30 Mar 2012 11:53:55 +0200

On Mar 29, 2012, at 7:55 PM, Federico Consoli wrote:

> "Once the preferred parent is selected, the node sets its cur_min_path_cost variable to the path cost corresponding to its preferred parent. It then calculates the metric it will advertise in its metric container. This value is the path cost of the member of the parent set with the highest path cost."
> 
> Root nodes have parent set of size zero so they got a cur_min_path_cost=0 so ETX=0.
> 
> Because "a node MUST advertise an approximation of its ETX in its advertised Rank value" root nodes must advertise ETX=0.
> I agree with the fact that absolute ETX do not matter but I think that the root advertisement does not match the definition in the MRHOF draft.

Ah, this is a good catch. I'll adjust the text to note this edge case. I chose the word "approximation" carefully there -- but the issues you're pointing out make it clear that the draft should explain what's going on in greater detail. In particular, how would you feel about some text along the lines of

"RPL's Rank advertisement rules can require a DODAG Root to advertise a Rank higher than its corresponding ETX value, as a DODAG Root advertises a Rank of MinHopRankIncrease. Because all DODAG Roots within a DODAG Version advertise the same Rank, this constant value typically does not affect route selection. Nevertheless, it means that if a DODAG Version has a MinHopRankIncrease of M and a path has an advertised ETX of E, then the actual ETX of the path is likely closer to a value of E-M than a value of E."

Phil

---

From: Federico Consoli <[email-masked]>
Date: Fri, 30 Mar 2012 13:42:41 +0200

> "RPL's Rank advertisement rules can require a DODAG Root to advertise a Rank higher than its corresponding ETX value, as a DODAG Root advertises a Rank of MinHopRankIncrease. Because all DODAG Root…
Ok. I agree with you.

I got a question about the PARENT_SET_SIZE.

"PARENT_SET_SIZE: The number of candidate parents, including the 
preferred parent, in the parent set."
  "candidate parents"  = "candidate neighbour"  or are different?

"A node MAY include up to PARENT_SET_SIZE-1 additional candidate 
neighbors in its parent set."
It's a upper bound? Could a node have more than PARENT_SET_SIZE 
additional candidate neighbors in its parents set?

-- 
Regards
Consoli Federico

---

From: Philip Levis <[email-masked]>
Date: Fri, 30 Mar 2012 18:06:19 +0200

On Mar 30, 2012, at 1:42 PM, Federico Consoli wrote:

> "PARENT_SET_SIZE: The number of candidate parents, including the preferred parent, in the parent set."

RFC 6550, 8.2.1:

   RPL's Upward route discovery algorithms and processing are in terms
   of three logical sets of link-local nodes.  First, the candidate
   neighbor set is a subset of the nodes that can be reached via link-
   local multicast.  The selection of this set is implementation and OF
   dependent.  Second, the parent set is a restricted subset of the
   candidate neighbor set.  Finally, the preferred parent is a member of
   the parent set that is the preferred next hop in Upward routes.
   Conceptually, the preferred parent is a single parent; although, it
   may be a set of multiple parents if those parents are equally
   preferred and have identical Rank.

> 
> "A node MAY include up to PARENT_SET_SIZE-1 additional candidate neighbors in its parent set."
> It's a upper bound? Could a node have more than PARENT_SET_SIZE additional candidate neighbors in its parents set?

Yes: there is no MUST NOT or even a SHOULD NOT.

Phil