Re: [Roll] Child count in parent selection

Chenyang JI <chenyang.ji@imt-atlantique.net> Fri, 03 November 2017 17:21 UTC

Return-Path: <chenyang.ji@imt-atlantique.net>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52DB513FF02 for <roll@ietfa.amsl.com>; Fri, 3 Nov 2017 10:21:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=imt-atlantique.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKsNlLKST3Nb for <roll@ietfa.amsl.com>; Fri, 3 Nov 2017 10:21:47 -0700 (PDT)
Received: from zproxy130.enst.fr (zproxy130.enst.fr [IPv6:2001:660:330f:2::c2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0059D13FF01 for <roll@ietf.org>; Fri, 3 Nov 2017 10:21:46 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by zproxy130.enst.fr (Postfix) with ESMTP id 3EE37120694; Fri, 3 Nov 2017 18:21:45 +0100 (CET)
Received: from zproxy130.enst.fr ([IPv6:::1]) by localhost (zproxy130.enst.fr [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id 03QuzjqF8q7l; Fri, 3 Nov 2017 18:21:43 +0100 (CET)
Received: from localhost (localhost [IPv6:::1]) by zproxy130.enst.fr (Postfix) with ESMTP id 9F0F5120A94; Fri, 3 Nov 2017 18:21:43 +0100 (CET)
DKIM-Filter: OpenDKIM Filter v2.10.3 zproxy130.enst.fr 9F0F5120A94
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=imt-atlantique.net; s=6A0CDB44-C782-11E6-82EC-91BDBA474D24; t=1509729703; bh=eIKlxb0sqVp4fJDP0Htagse2ssqyXi26t0AyDlqXoCg=; h=Date:From:To:Message-ID:MIME-Version; b=fPjNvzGcYQ9NRERQG9dJIJGkdfFPkZxv/mUKIuNs3E+TmEpfa1pv3FH1J93K205ov CshPbkRT+sl9b2cXVwpy5trny3AjHIlpuWlOahH5xNLwNSMbl+k4cBB33X6xsFp5EA wTFwXmvYPeyJl8BMLSJwGKvjW0u5ZL1uvi+sBfu8=
X-Virus-Scanned: amavisd-new at zproxy130.enst.fr
Received: from zproxy130.enst.fr ([IPv6:::1]) by localhost (zproxy130.enst.fr [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id CPcPnpEBT6Ib; Fri, 3 Nov 2017 18:21:43 +0100 (CET)
Received: from zmail131.enst.fr (zmail131.enst.fr [137.194.2.203]) by zproxy130.enst.fr (Postfix) with ESMTP id 7F208120694; Fri, 3 Nov 2017 18:21:43 +0100 (CET)
Date: Fri, 03 Nov 2017 18:21:43 +0100
From: Chenyang JI <chenyang.ji@imt-atlantique.net>
To: "Houjianqiang (Derek)" <houjianqiang@huawei.com>, roll <roll@ietf.org>
Message-ID: <544130816.4872551.1509729703443.JavaMail.zimbra@imt-atlantique.net>
In-Reply-To: <DD0A994E4D6B3F4080662703C8C7C086A8C793@DGGEMM506-MBS.china.huawei.com>
References: <DD0A994E4D6B3F4080662703C8C7C086A8C793@DGGEMM506-MBS.china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [2001:660:7301:51:c126:3f76:249e:b974]
X-Mailer: Zimbra 8.7.11_GA_1854 (ZimbraWebClient - FF56 (Linux)/8.7.11_GA_1854)
Thread-Topic: Child count in parent selection
Thread-Index: AdNR5qGs8C64+4nvRem9wuaViXd9zYyJQ2td
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/v3cm415n7hNGs9FoHjccKC22oD0>
Subject: Re: [Roll] Child count in parent selection
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Nov 2017 17:21:50 -0000

Hello,

Thank you for the answer and I apologize for my late response.
Today I realized that you had a new version of draft draft-qasem-roll-rpl-load-balancing-02 and I also have some questions on this.
The description about LB-OF is:

 In LB-OF algorithm, the received DIO from the child node is counted by the preferred parent node. Each DIO contains the IP
 address of the chosen preferred parent as detailed in section 4.3. Thus,for each received DIO, the node matches its own IP 
 address with the preferred parent IP address which is inserted in the DIO message, thenincrements the number of children by 
 ONE for this node if there is a matching.

And the format of DIO metric container object is:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Flags     |P|     CNC       |    CNC_MAX    |               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
       |                                                               |
       +                                                               +
       |                                                               |
       +                        Parent Address                         +
       |                                                               |
       +                                               +-+-+-+-+-+-+-+-+
       |                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

which Parent Address field is optional and is set if 'p'flag is set.
Also,it says that:

Thus, to minimize traffic load, the Parent Address field in the CNC object should not be present in the storing mode.

That means the 'p'flag is set for every DIO message sent in Non-storing mode?

Thank you,
Chenyang ji

https://www.ietf.org/id/draft-qasem-roll-rpl-load-balancing-02.txt

----- Original Message -----
From: "Houjianqiang (Derek)" <houjianqiang@huawei.com>
To: "chenyang ji" <chenyang.ji@imt-atlantique.net>
Cc: "roll" <roll@ietf.org>, "jichenyang920" <jichenyang920@gmail.com>, "Qasem, Mamoun" <M.Qasem@napier.ac.uk>
Sent: Tuesday, October 31, 2017 2:42:19 AM
Subject: Re: [Roll] Child count in parent selection

Hi Chenyang



Many thanks for your interest in our draft. I am happy to answer your questions. Please see my response in line.



Best regards,

Jianqiang Hou (Derek)



Date: Mon, 30 Oct 2017 08:40:02 +0100 (CET)

From: Chenyang JI <chenyang.ji@imt-atlantique.net<mailto:chenyang.ji@imt-atlantique.net>>

To: roll@ietf.org<mailto:roll@ietf.org>

Cc: jichenyang920 <jichenyang920@gmail.com<mailto:jichenyang920@gmail.com>>

Subject: [Roll] Child count in parent selection

Message-ID:

                <961578433.3782382.1509349202587.JavaMail.zimbra@imt-atlantique.net<mailto:961578433.3782382.1509349202587.JavaMail.zimbra@imt-atlantique.net>>

Content-Type: text/plain; charset=utf-8



Hello,



I have some questions about draft-hou-roll-rpl-parent-selection-00 and draft-qasem-roll-rpl-load-balancing-01.

In the draft,it describes a new type of metric which has this format:



CNC: 8 bits. The Child Node Count is encoded in 8 bits in unsigned integer format, expressed in number count, representing the number of child nodes.



MAX_CNC: 8 bits. The Maximum Child Node Count is encoded in 8 bits in unsigned integer format, expressed in number count, representing the maximum number of child nodes allowed in the neighbor cache.



but it does not clarify if this number of child nodes refers to the number of direct child or the subtree size.

[Jianqiang] My mistake... This number of child nodes refers to the number of direct child.



In draft-qasem-roll-rpl-load-balancing-01:



In LB-OF algorithm, the received DIO from the child node is counted by the preferred parent node. Each DIO contains the IP address of the chosen preferred parent as detailed in section 4.3. Thus, for each received DIO, the node matches its own IP address with the preferred parent IP address which is inserted in the DIO message, then increments the number of children by ONE for this node if there is a matching.



My question is if that mean it will store the children's address and if yes,how will the node stores its children.

[Jianqiang] There are two possible ways of storing its children. One is to store the children's address in a new table with extra cache, the other way is to manage the neighbor cache entry (after all the direct children set is a subset of the neighbor set).



The first draft

https://tools.ietf.org/html/draft-hou-roll-rpl-parent-selection-00



The second draft

https://datatracker.ietf.org/doc/html/draft-qasem-roll-rpl-load-balancing



Best regards,

Chenyang Ji