Re: [6tsch] Zero Objective Function discussion

Qin Wang <qinwang@berkeley.edu> Wed, 11 September 2013 21:58 UTC

Return-Path: <qinwang@berkeley.edu>
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 A9F2921E80A5 for <6tsch@ietfa.amsl.com>; Wed, 11 Sep 2013 14:58:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.527, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 asvZL+z7BUZW for <6tsch@ietfa.amsl.com>; Wed, 11 Sep 2013 14:58:46 -0700 (PDT)
Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) by ietfa.amsl.com (Postfix) with ESMTP id D8DA121F9B26 for <6tsch@ietf.org>; Wed, 11 Sep 2013 14:58:33 -0700 (PDT)
Received: by mail-ie0-f170.google.com with SMTP id 17so12017303iea.29 for <6tsch@ietf.org>; Wed, 11 Sep 2013 14:58:30 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=haXcoNaJXO+CyrDiaV8yvoRg0OPZyWksHz0ZHK3LkdU=; b=dlzpjUKAj+qd9p5n+IbvlzUmlZhkE82lRwZMjRrEP5VY6UtJOtlOlOTt5tdBRK6zqO yH4Wd0AVEyZx3SQnqxisKaafDiECRQRGUcJXMPmPZXpZofDKGZEu9Tj96iPbMfBlWxns 6Jl6Po90Uajg6hSSWZ9P1sg4HlP7NZfuS6jb/qsaOZxN0j6HFpiBXKvuVfe31XlBFtZt 4Hgo7NgDGlriF8c+ndvj1SDSVK851ztZPBC9sObFCEbz2i64fbiVv7JxhwxVd9dfNTyv 4yBrijnvrKlBYJiX+29rU6cVe5f7l+Z0/UjAmN4XahLxiwb8etUbxZPTDNlgxBJXvxQb IoUQ==
X-Gm-Message-State: ALoCoQmtEVDp4A8a9fpPvMsAZu5RX/KdrgcymcbzuaxcCGwCtAQ1EaSAONKSTDiCYiYNofkq0kNK
MIME-Version: 1.0
X-Received: by 10.50.43.170 with SMTP id x10mr982722igl.45.1378936710030; Wed, 11 Sep 2013 14:58:30 -0700 (PDT)
Received: by 10.64.139.234 with HTTP; Wed, 11 Sep 2013 14:58:29 -0700 (PDT)
In-Reply-To: <E045AECD98228444A58C61C200AE1BD8414615AE@xmb-rcd-x01.cisco.com>
References: <CADJ9OA8vNGCmy-2X901pqnmZuSCQ1d=GPeHPE=SD25JJkfwGgw@mail.gmail.com> <E045AECD98228444A58C61C200AE1BD84145CF1E@xmb-rcd-x01.cisco.com> <CALEMV4aaQgqB9q7ht5XeySmhUOWUHtu2x9phkw3N=r3xqt5Rvg@mail.gmail.com> <E045AECD98228444A58C61C200AE1BD8414615AE@xmb-rcd-x01.cisco.com>
Date: Thu, 12 Sep 2013 05:58:29 +0800
Message-ID: <CAAzoce7Fu4U1wC2YfKF-nUkPimzPeSXJos0TxqtCmwN=vRN83g@mail.gmail.com>
From: Qin Wang <qinwang@berkeley.edu>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Content-Type: multipart/alternative; boundary=089e01176cadc713bd04e622b8ae
Cc: Thomas Watteyne <watteyne@eecs.berkeley.edu>, 6TSCH <6tsch@ietf.org>, "xvilajosana@eecs.berkeley.edu" <xvilajosana@eecs.berkeley.edu>
Subject: Re: [6tsch] Zero Objective Function discussion
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: Wed, 11 Sep 2013 21:59:00 -0000

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