Subject: Re: [6tsch] set DAGRank to Join Priority

From: Jonathan Simon <[email-masked]>
Date: Thu, 3 Oct 2013 15:14:22 -0700

Thomas - looking back at the various drafts of the standard, it was changed from 0x00-0xFF to 0x00-0x3F between draft 1 and draft 2.  There are no ballot comments or instructions to the editor to make this change, so it looks like a mistake that I never noticed and corrected.  The intention, if not the letter of the spec, was to use the full byte.

-- 
Jonathan Simon, Ph. D
Director of Systems Engineering
Linear Technology, Dust Networks product group
30695 Huntwood Ave
Hayward, CA 94544-7021
(510) 400-2936
(510) 489-3799 FAX
[email-masked]

**LINEAR TECHNOLOGY CORPORATION** 
*****Internet Email Confidentiality Notice***** 
 This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify me by reply e-mail, or by telephone at (510) 400-2936, and destroy the original transmission and its attachments without reading or saving in any manner. Thank you. 

On Sep 28, 2013, at 12:45 PM, Thomas Watteyne wrote:

> Jonathan,
> 
> A clarifying question from the 6TiSCH group about the join priority field. Any thoughts? I'm copy-pasting the figures in question:
> 
> Here, joinPriority seems to be capped at 0x3f, i.e. forcing two MSb to 0.
> 
> 
> But in the packet, it takes up an entire byte.
> 
> 
> Why capping its internal value to 0x3f if there is space in the packet to carry the complete byte?
> 
> Thanks,
> Thomas
> 
> ---------- Forwarded message ----------
> From: Thomas Watteyne <[email-masked]>
> Date: Sat, Sep 28, 2013 at 12:42 PM
> Subject: Re: [6tsch] set DAGRank to Join Priority
> To: "[email-masked]" <[email-masked]>
> 
> 
> Qin,
> 
> In IEEE802.15.4e, Table 52b indeed shows a range of 0x00-0x3f. Yet, Figure 48ee shows a 1-byte field. I'll go on a little hunt to understand where those 2 bits went, will let you know.
> 
> Thomas
> 
> 
> On Sat, Sep 28, 2013 at 12:08 AM, Pascal Thubert (pthubert) <[email-masked]> wrote:
> Agreed
> 
> Say the rule is as discussed earlier:
> Rank = sigma (etx*2*mh) where mh is 256.
> Thus dagrank <= 2*sigma(etx)
> 
> Let us be honest, even with an etx of 3 this gives us 8 hops, which leaves very little chances to deliver in time.
> 
> For a classical mesh we are shooting at 4 or 5 hops so 3f should be enough.
> 
> For long and static lines, we may resort to hop count though. 
>  
> What do others think?
> 
> Pascal
> 
> Le 27 sept. 2013 à 23:34, "Xavier Vilajosana Guillen" <[email-masked]> a écrit :
> 
>> Hi Qin,
>> 
>> well the rank is 2Byte, what i suggest is to divide it by 256 and take this number as Join Priority (1Byte). If this number is bigger than 0x3F then the Join Priority becomes 0x3F. Of course this if 0x3F is a strict requirement.
>> 
>> regards,
>> Xavi
>> 
>> 
>> On Fri, Sep 27, 2013 at 2:20 PM, Qin Wang <[email-masked]> wrote:
>> Xavi,
>> 
>> You mean:
>> if rank <= 0x3f then JoinPriority=rank else JoinPriority=0x3f
>> 
>> Correct? I think it could be a solution.
>> 
>> Thanks
>> Qin
>> 
>> 
>> On Sat, Sep 28, 2013 at 5:07 AM, Xavier Vilajosana Guillen <[email-masked]> wrote:
>> Hi Qin, 
>> 
>> my suggestion is to use JoinPriority[5:0] = (rank[15:8]&0x3F) or 0x3F if bigger -- having a 0x3F would be like having INFINITE Join Priority as in the case of RPL with ranks>65535.
>> 
>> would that not work?
>> X
>> 
>> 
>> On Fri, Sep 27, 2013 at 1:44 PM, Qin Wang <[email-masked]> wrote:
>> Xavi,
>> 
>> Let's take the example in your draft to see what the problem is. Please point out if I'm wrong.
>> +-------+
>>      |   0   | R(0)=0
>>      |       | DAGRank(R(0)) = 0
>>      +-------+
>>          |
>>          |
>>      +-------+
>>      |   1   | R(1)=R(0)+683=683
>>      |       | DAGRank(R(1)) = 2
>>      +-------+
>>          |
>>          |
>>      +-------+
>>      |   2   | R(2)=R(1)+683=1366
>>      |       | DAGRank(R(2)) = 5
>>      +-------+
>>          |
>>          |
>>      +-------+
>>      |   3   | R(3)=R(2)+683=2049
>>      |       | DAGRank(R(3)) = 8
>>      +-------+
>>          |
>>          |
>>      +-------+
>>      |   4   | R(4)=R(3)+683=2732
>>      |       | DAGRank(R(4)) = 10
>>      +-------+
>>          |
>>          |
>>      +-------+
>>      |   5   | R(5)=R(4)+683=3415
>>      |       | DAGRank(R(5)) = 13
>>      +-------+
>> 
>> From the example, you can see R(n) is a 2-byte integer, and DAGRank is always the higher byte of the 2byte integer, because minHopRankIncrease = 256.
>> 
>> If set JoinPriority = DAGRank, then it is possible JoinPriority> 0x3f (although it unlikely happens often), out of its range. 
>> If set JoinPriority[5:0] = DAGRank[7:2], (Is it your suggestion?), a new node may found many existing nodes with same JoinPriority in received EB. In another word, the JoinPriority can not provide information about preferring joining. Right?
>> 
>> I haven't had good solution for it. So, I hope the range 0x00~0x3f is not a "MUST" in IEEE802.15.4e.
>> 
>> What  do you think?
>> Qin 
>> 
>> 
>> 
>> 
>> On Sat, Sep 28, 2013 at 2:30 AM, Xavier Vilajosana Guillen <[email-masked]> wrote:
>> Hi Qin,
>> 
>> after thinking a little bit on that maybe we can use the higher byte of the rank for that. that is  rank>>8, the higher byte is a monotonically increasing counter. As each hop is <<8 (due to minhopRankIncrease) we can have the sense of higher join priority as higher the rank. 
>> 
>> In addition having if we have the limitation of 0x3F, this means that we will support Join priorities up to 0x3F that translated to ranks are 0x3F<<8 (big number) ..
>> 
>> just thoughts...
>> X
>> 
>> 
>> On Fri, Sep 27, 2013 at 10:30 AM, Qin Wang <[email-masked]> wrote:
>> Hi Thomas,
>> 
>> I think with OF0 the DAGRank is uint8. But, in the Table 52b of IEEE802.15.4e, the range of Join Priority is 0x00~0x3f. If the range is a "MUST", we have to have a function mapping a DAGRank in 0x00~0xff to a JoinPriority in 0x00~0x3f. Correct?
>> 
>> Would you please confirm with some expertise in IEEE802.15.4e if the range 0x00~0x3f is a MUST or not?
>> 
>> Thanks
>> Qin
>> 
>> _______________________________________________
>> 6tsch mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/6tsch
>> 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> 6tsch mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/6tsch
> 
> _______________________________________________
> 6tsch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tsch
> 
> 
> 
> 
> 
> -- 
> Thomas Watteyne, Ph. D
> Sr. Networking Design Engineer
> Dust Networks / Linear Technology
> 30695 Huntwood Ave
> Hayward, CA 94544-7021
> +1 (510) 400-2978
> [email-masked]
> 
> This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify me by reply e-mail, or by telephone at (510) 400-2978, and destroy the original transmission and its attachments without reading or saving in any manner. Thank you.