Subject: [6tsch] Zero Objective Function discussion

From: Thomas Watteyne <[email-masked]>
Date: Fri, 6 Sep 2013 09:17:42 -0700

Pascal,

Thank you for presenting the OF0 discussion on the call today. I have a
quick question about the depth penalty. In your example on the call, you
used b=0. Could you detail a case where using a value of b different than 0
is applicable?

Also, do you think there is an alternative to defining our own computation
of Sp? Certainly in the minimal draft, it would be good if we could use a
OF as-is, without introducing anything new.

Thomas

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 6 Sep 2013 17:14:23 +0000

Hello Thomas:

The idea behind RFC 6552 is that we can say nothing if we do not want to specify anything. Node will interoperate and a rather correct network will form as long as devices use a normalized value for Sp(best = 1, good = 3, worst = 9)

We can make the life simpler for implementers by defining that we use ETX and that the normalization process is, say, 2*ETX as in my example; by RFC 6552 standards would mean that good link is ETX = 1.5 and ETX is acceptable up to 4.5

RFC 6719 provides another OF that can be used without a metric container, see section 3.5. In that case, ETX /2 is used. This gives a larger span to the network but means trouble to map in a join priority or a flow label.

I proposed a general formula Sp = a*ETX + b where a is between 1 and 3 and b is between 0 and 2 or 3. If b is not null, the Rank grows faster with the number of hops so deeper networks are not favored. To be honest I'm not convinced that it is a great idea for data instances or to encourage duocast it could be good.

An example of that would be a=1, b=2, which means that each hop incurs an additional penalty equivalent to an ETX of 2. This would mean that ETX is acceptable up to 7.

Probably specififying that we use OF0 with
Rf = 1
Sp = 2* ETX
Sr = 0

Is not a lot of work is it?

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: vendredi 6 septembre 2013 18:18
To: 6TSCH
Subject: [6tsch] Zero Objective Function discussion

Pascal,

Thank you for presenting the OF0 discussion on the call today. I have a quick question about the depth penalty. In your example on the call, you used b=0. Could you detail a case where using a value of b different than 0 is applicable?

Also, do you think there is an alternative to defining our own computation of Sp? Certainly in the minimal draft, it would be good if we could use a OF as-is, without introducing anything new.

Thomas

---

From: Xavier Vilajosana Guillen <[email-masked]>
Date: Tue, 10 Sep 2013 10:52:30 -0700

Hi all,

after some study I agree that we can use the RFC6552 in the minimal 6TiSCH
configuration. I would like to call for approval or more input from others
before I consolidate the text in the draft.

I put here an example following Pascal suggestion:

Given

Rf = 1
Sp = 2* ETX
Sr = 0
minHopRankIncrease = 256 (default in RPL)
ETX=(xmit/ack)

r(n) = r(p) + rank_increase
rank_increase= (Rf*Sp + Sr) * minHopRankIncrease
rank_increase=(512*xmit/ack)

if we take 5 hops (95 are supported) network and r(0)=0 and xmit=100 and
ack=75 for all nodes

r(1)=r(0)+rank_increase = 0+683 with f=0
r(2)=r(1)+683=1366 with f=1
r(3)=r(2)+683=2049 with f=2
r(4)=r(3)+683=2732 with f=2
r(5)=r(4)+683=3415 with f=3
...
etc...

so f is monotonically increasing and the rank function enables more than
enough hops.

Please provide feedback.

cheers!
Xavi

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 10 Sep 2013 19:08:53 +0000

Hello Xavi:

Great!

I'd add the following:

RFC 6550    3.5.1<http://tools.ietf.org/html/rfc6550#section-3.5.1>. Rank Comparison (DAGRank())has:
"

When an Objective Function computes Rank, the Objective Function

   operates on the entire (i.e., 16-bit) Rank quantity.  When Rank is

   compared, e.g., for determination of parent relationships or loop

   detection, the integer portion of the Rank is to be used.  The

   integer portion of the Rank is computed by the DAGRank() macro as

   follows, where floor(x) is the function that evaluates to the

   greatest integer less than or equal to x:

              DAGRank(rank) = floor(rank/MinHopRankIncrease)

   For example, if a 16-bit Rank quantity is decimal 27, and the

   MinHopRankIncrease is decimal 16, then DAGRank(27) = floor(1.6875) =

   1.  The integer part of the Rank is 1 and the fractional part is

   11/16.

"
DAGRank(rank) is what we expect to place in the Flow label and the join priority.
In our case:

r(1)=r(0)+rank_increase = 0+683               => DAGRank(rank) = 2
r(2)=r(1)+683=1366                                         => DAGRank(rank) = 5
r(3)=r(2)+683=2049                                         => DAGRank(rank) = 8
r(4)=r(3)+683=2732                                         => DAGRank(rank) = 10
r(5)=r(4)+683=3415                                         => DAGRank(rank) = 13

We see that the DAGRank() always increases at least by one. This is the desired property so as to ensure that we can detect loop with just one octet in the flow label.
Note that the real 2 octets Rank does not lose the rounding info since the DIP always passes 2 octets.

Cheers,

Pascal

From: Xavier Vilajosana Guillen [mailto:[email-masked]]
Sent: mardi 10 septembre 2013 19:53
To: Pascal Thubert (pthubert)
Cc: Thomas Watteyne; 6TSCH
Subject: Re: [6tsch] Zero Objective Function discussion

Hi all,

after some study I agree that we can use the RFC6552 in the minimal 6TiSCH configuration. I would like to call for approval or more input from others before I consolidate the text in the draft.

Given

Rf = 1
Sp = 2* ETX
Sr = 0

if we take 5 hops (95 are supported) network and r(0)=0 and xmit=100 and ack=75 for all nodes

so f is monotonically increasing and the rank function enables more than enough hops.
Please provide feedback.
cheers!
Xavi

---

From: Qin Wang <[email-masked]>
Date: Thu, 12 Sep 2013 05:58:29 +0800

Hi Pascal,

I agree with your calculation. But, I have a small question.

If you calculate with rank_increase=(2*xmit/ack)*256, instead of
rank_increase=(512*xmit/ack),
then, you will get the result as follows.

r(1)=r(0)+2.66*256 = 2.66*256               => DAGRank(rank) = 2****

r(2)=r(1)+2.66*256= 5.32*256                 => DAGRank(rank) = 5****

r(3)=r(2)+2.66*256=7.98*256                  => DAGRank(rank) = 7**

r(4)=r(3)+2.66*256=10.64*256                => DAGRank(rank) = 10****

r(5)=r(4)+2.66*256=13.30*256                 => DAGRank(rank) = 13

You can see r(3) is different from that in your calculation. Obviously, the
difference comes from different implementation. In another word, following
same OF, different implementation may lead to different Rank value. Then,
my question is if it is Ok while the motes from different vendors work
together in a DAG.

Please point out if I'm wrong.

Thanks

Qin

On Wed, Sep 11, 2013 at 3:08 AM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

>  Hello Xavi:****
>
> ** **
>
> Great!****
>
> ** **
>
> I’d add the following:****
>
> ** **
>
> RFC 6550    3.5.1 <http://tools.ietf.org/html/rfc6550#section-3.5.1>. Rank Comparison (DAGRank())has:****
>
> “****
>
> When an Objective Function computes Rank, the Objective Function****
>
>    operates on the entire (i.e., 16-bit) Rank quantity.  When Rank is****
>
>    compared, e.g., for determination of parent relationships or loop****
>
>    detection, the integer portion of the Rank is to be used.  The****
>
>    integer portion of the Rank is computed by the DAGRank() macro as****
>
>    follows, where floor(x) is the function that evaluates to the****
>
>    greatest integer less than or equal to x:****
>
> ** **
>
>               DAGRank(rank) = floor(rank/MinHopRankIncrease)****
>
> ** **
>
>    For example, if a 16-bit Rank quantity is decimal 27, and the****
>
>    MinHopRankIncrease is decimal 16, then DAGRank(27) = floor(1.6875) =****
>
>    1.  The integer part of the Rank is 1 and the fractional part is****
>
>    11/16.****
>
> ** **
>
> “****
>
> DAGRank(rank) is what we expect to place in the Flow label and the join
> priority.****
>
> In our case:****
>
> ** **
>
> r(1)=r(0)+rank_increase = 0+683               => DAGRank(rank) = 2****
>
> r(2)=r(1)+683=1366                                         =>
> DAGRank(rank) = 5****
>
> r(3)=r(2)+683=2049                                         =>
> DAGRank(rank) = 8****
>
> r(4)=r(3)+683=2732                                         =>
> DAGRank(rank) = 10****
>
> r(5)=r(4)+683=3415                                         =>
> DAGRank(rank) = 13****
>
> ** **
>
> We see that the DAGRank() always increases at least by one. This is the
> desired property so as to ensure that we can detect loop with just one
> octet in the flow label.****
>
> Note that the real 2 octets Rank does not lose the rounding info since the
> DIP always passes 2 octets.****
>
> ** **
>
> Cheers,****
>
> ** **
>
> Pascal****
>
> ** **
>
> *From:* Xavier Vilajosana Guillen [mailto:[email-masked]]
> *Sent:* mardi 10 septembre 2013 19:53
> *To:* Pascal Thubert (pthubert)
> *Cc:* Thomas Watteyne; 6TSCH
> *Subject:* Re: [6tsch] Zero Objective Function discussion****
>
> ** **
>
> Hi all,
>
> minHopRankIncrease = 256 (default in RPL)****
>
> ETX=(xmit/ack)****
>
> ** **
>
> rank_increase= (Rf*Sp + Sr) * minHopRankIncrease ****
>
> enough hops.****
> Please provide feedback.****
>
> cheers!
> Xavi****
>
>  ****
>
> _______________________________________________
> 6tsch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tsch
>
>