Re: [6tsch] set DAGRank to Join Priority

Thomas Watteyne <watteyne@eecs.berkeley.edu> Sat, 28 September 2013 19:42 UTC

Return-Path: <twatteyne@gmail.com>
X-Original-To: 6tsch@ietfa.amsl.com
Delivered-To: 6tsch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9DB711E8153 for <6tsch@ietfa.amsl.com>; Sat, 28 Sep 2013 12:42:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.573
X-Spam-Level:
X-Spam-Status: No, score=-1.573 tagged_above=-999 required=5 tests=[AWL=0.404, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ykb2+NM4oB6W for <6tsch@ietfa.amsl.com>; Sat, 28 Sep 2013 12:42:38 -0700 (PDT)
Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id C2BBF11E8159 for <6tsch@ietf.org>; Sat, 28 Sep 2013 12:42:38 -0700 (PDT)
Received: by mail-pd0-f176.google.com with SMTP id q10so3954385pdj.35 for <6tsch@ietf.org>; Sat, 28 Sep 2013 12:42:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=6um7X9JBYx0IH3O1Zlf1mXTAYnNZQrzPnyqMSPuCSpc=; b=qcfl52WpLmvdUd8tL5rf23H99vKcyTAeu5gFDF9iuX5+A2O/mpLfdvpcFW4lW7Mg9O SaTw3/gfprJtIF1hQFy4ME28NiPAN3vqWFmC4SKohc8cVo5B/PDUTIYdyVJDzl7VVVh3 s0Cyuz/baJGl5xNiU/uJA2YA2dcBFr0C/obbMwfgqJRIRVprdcB6LiO5d4WFfq4wjSE0 NYQAXbg8m+CLWEEbxiZ48s/O5+ZkcC4VIgO6dWMzIzMMduuf3K+QZcWsmsEZEAJ4qJs4 82ztSpulAUjwUlF0ehM6XyEjxJMHT6+o/H9ghL8Jeqs/w1GwTOFzu58fh7oWiJzwU8hd AZ3A==
X-Received: by 10.68.171.193 with SMTP id aw1mr14534399pbc.131.1380397358415; Sat, 28 Sep 2013 12:42:38 -0700 (PDT)
MIME-Version: 1.0
Sender: twatteyne@gmail.com
Received: by 10.66.147.193 with HTTP; Sat, 28 Sep 2013 12:42:18 -0700 (PDT)
In-Reply-To: <7BC11E20-73E1-4A12-A227-02558705D01D@cisco.com>
References: <CAAzoce5GiY8zsD4aSaSeWB19Se3fwcTTd8wpqRTC0rAonncUkg@mail.gmail.com> <CALEMV4Zom6wW6ByhB3zMwJRt1NpqmeFbe13NuUbrFSWz=pNGhw@mail.gmail.com> <CAAzoce4zvg0_igrE=U-afgf1iOsGmSUo78kjL-z7tmLVnWRBwg@mail.gmail.com> <CALEMV4Zbc8xy=yQzE7K=RChEWBdC80ommMwqhRxYwfZNt6XypA@mail.gmail.com> <CAAzoce5sWeo6+58jjX6Jax_c=JWiBMEFZR=qJA-oX9MWmqjKSQ@mail.gmail.com> <CALEMV4YExLAh_7Guv9ak5t4j-g-e=Lu3QHDrfr_DiwSKFkgQ_g@mail.gmail.com> <7BC11E20-73E1-4A12-A227-02558705D01D@cisco.com>
From: Thomas Watteyne <watteyne@eecs.berkeley.edu>
Date: Sat, 28 Sep 2013 12:42:18 -0700
X-Google-Sender-Auth: 13ILiMabHouexA11Shn_s_Haagw
Message-ID: <CADJ9OA8-8W+k_pAs2_Yh7T5f=D0CkVpUtUxiQmpOU_3LqAC7Cw@mail.gmail.com>
To: "6tsch@ietf.org" <6tsch@ietf.org>
Content-Type: multipart/alternative; boundary="047d7b67360432858b04e776ce46"
Subject: Re: [6tsch] set DAGRank to Join Priority
X-BeenThere: 6tsch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:6tsch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>
List-Post: <mailto:6tsch@ietf.org>
List-Help: <mailto:6tsch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:6tsch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 28 Sep 2013 19:42:39 -0000

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) <
pthubert@cisco.com> 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" <
> xvilajosana@eecs.berkeley.edu> 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 <qinwang@berkeley.edu> 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 <
>> xvilajosana@eecs.berkeley.edu> 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 <qinwang@berkeley.edu> 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 <
>>>> xvilajosana@eecs.berkeley.edu> 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 <qinwang@berkeley.edu>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
>>>>>> 6tsch@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/6tsch
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>   _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
>
>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
>
>