Re: [6tisch] MSF Shepherd review
Yasuyuki Tanaka <yasuyuki.tanaka@inria.fr> Fri, 29 November 2019 19:41 UTC
Return-Path: <yasuyuki.tanaka@inria.fr>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7B7120800 for <6tisch@ietfa.amsl.com>; Fri, 29 Nov 2019 11:41:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 h9v0hNnywdjx for <6tisch@ietfa.amsl.com>; Fri, 29 Nov 2019 11:41:26 -0800 (PST)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30FB71200BA for <6tisch@ietf.org>; Fri, 29 Nov 2019 11:41:25 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.69,258,1571695200"; d="scan'208";a="414202183"
Received: from poi92-3-88-190-144-98.fbxo.proxad.net (HELO [192.168.1.29]) ([88.190.144.98]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 29 Nov 2019 20:41:24 +0100
Cc: 6tisch@ietf.org, yasuyuki.tanaka@inria.fr
To: pthubert@cisco.com
References: <MN2PR11MB3565642A73EC6629FA68137DD84A0@MN2PR11MB3565.namprd11.prod.outlook.com> <CAAdgstRhP2aOfekS5swmXPbD1rwnR-bAAm9ToBQnwmv77KCSEw@mail.gmail.com> <27392BE1-0C67-410D-B1BC-1F751CC8656C@cisco.com> <CAAdgstRQGMg0fDUH94T+NZQ+s4JM8Wo=xDb+VMQ-sHDKvh8oiQ@mail.gmail.com> <6F9E85A6-B561-41CD-9E3C-7E6E761349B7@cisco.com>
From: Yasuyuki Tanaka <yasuyuki.tanaka@inria.fr>
Message-ID: <80a20be0-c495-bed6-548c-f909161a7102@inria.fr>
Date: Fri, 29 Nov 2019 20:41:23 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2
MIME-Version: 1.0
In-Reply-To: <6F9E85A6-B561-41CD-9E3C-7E6E761349B7@cisco.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/98Ggwlm7QfjtJCtpg83q4m4q0I0>
Subject: Re: [6tisch] MSF Shepherd review
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.29
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" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Nov 2019 19:41:29 -0000
Hi Pascal, pascal> My problem is that there’s only one preferred parent, but a pascal> node may use several parents for data traffic. This is why we pascal> build dodags in the first place. pascal> pascal> I believe that the node may allocate cells with all of those pascal> “selected parents” if it likes. The use of “preferred parent” pascal> in that text would prevent this. I feel this scenario is outside of the scope of the *minimal* scheduling function. If I remember correctly, such a case hasn't been discussed nor evaluated with implementations. The latest MSF spec may be able to be applied to the multiple parents case without any modification, or may not. We don't know because we'd not taken it into account. Regarding the multiple DODAGs case, a possible solution is having a separate MSF instance per DODAG, using a different SFID. Another idea is using the Metadata field to associate a 6P transaction with a DODAG. In any case, I prefer having "the preferred parent" in the text, although "parent" sounds like a L3 term. L2 doesn't maintain parent-child relationships. My two cents. Best, Yatch On 11/29/2019 4:23 PM, Pascal Thubert (pthubert) wrote: > Please do not call him preferred parent that’s something specific in > RPL, the best parent for forwarding up the dodag. > > Why not just say “the parent “ explaining that the 6P protocol can be > used in parallel with multiple parents? > > > Regards, > > Pascal > >> Le 29 nov. 2019 à 16:19, Tengfei Chang <tengfei.chang@gmail.com> a écrit : >> >> >> Hi Pascal, >> >> For the preferred parent issue: >> >> When running MSF, the node is deal with one parent at a time out of >> the parent set, which we called preferred parent. >> It doesn't mean there is only one parent for each nodes. >> The node may change its preferred parent to other parent, which >> responded in the switching_parent section in MSF. >> >> For the sentence: >> >> It is recommended to set MAX_NUMCELLS value at least 4x of the >> maximum link traffic load of the network with unit of packets per >> slotframe. >> >> >> The following example helps to understand the meaning: >> >> For example, a 2 packets/slotframe traffic load results an average >> 4 cells scheduled, using the value of double number of scheduled >> cells (which is 8) as MAX_NUM_CELLS gives a good resolution on >> cell usage calculation. >> >> Any recommendation on the rephrasing? >> >> Tengfei >> >> >> >> On Wed, Nov 27, 2019 at 10:07 PM Pascal Thubert (pthubert) >> <pthubert@cisco.com <mailto:pthubert@cisco.com>> wrote: >> >> Hello Tengfei >> >> >> Please see below >> >>> Le 27 nov. 2019 à 21:44, Tengfei Chang <tengfei.chang@gmail.com >>> <mailto:tengfei.chang@gmail.com>> a écrit : >>> >>> >>> Thanks a lot for the reviewing, I responded inline: >>> >>> On Mon, Nov 25, 2019 at 6:42 PM Pascal Thubert (pthubert) >>> <pthubert@cisco.com <mailto:pthubert@cisco.com>> wrote: >>> >>> Dear all____ >>> >>> __ __ >>> >>> Please find some comments below: ____ >>> >>> __ __ >>> >>> __ __ >>> >>> __ __ >>> >>> __ __ >>> >>> Please migrate to XML2RFC v3. This will save time in the future. >>> >>> >>> TC: got it! Will used in version 9. >> >> :) >>> >>> ____ >>> >>> __ __ >>> >>> __ __ >>> >>> __ __ >>> >>> ____ >>> >>> However, an implementor MAY implement MSF without >>> implementing____ >>> >>> Minimal 6TiSCH Configuration. ____ >>> >>> __ __ >>> >>> __ __ >>> >>> This is not helpful without explanations. What is the >>> tradeoff? How does the network operates in that case? >>> >>> >>> TC: Yes, the sentence is misleading. What we try to say is MSF >>> can work with other specifications protocols, rather then minimal >>> 6TiSCH configuration, as long as the protocols gives a way to >>> communicate the EB and DIO among the network. >> >> Those words in the draft will make me a happy shepherd... >>> >>> ____ >>> >>> __ __ >>> >>> __ __ >>> >>> __ __ >>> >>> __ __ >>> >>> For example, a Trickle Timer defined in____ >>> >>> [RFC6550 <https://tools.ietf.org/html/rfc6550>] MAY be applied on DIOs. However, this behavior is____ >>> >>> implementation-specific which is out of the scope of MSF.____ >>> >>> __ __ >>> >>> __ __ >>> >>> This is not for this spec to define. RPL already mandates >>> trickle. Suggestion:____ >>> >>> __ __ >>> >>> For example, the Trickle operation defined in [RFC6206]____ >>> >>> is applied on DIO Messages [RFC6550 <https://tools.ietf.org/html/rfc6550>]. This behavior is____ >>> >>> out of the scope of MSF.____ >>> >>> __ >>> >>> TC: agreed! >>> >>> __ >>> >>> __ __ >>> >>> __ __ >>> >>> __ __ >>> >>> __ __ >>> >>> MSF RECOMMENDS the use of 3 slotframes. ____ >>> >>> __ __ >>> >>> Discussion on slotframes and cells comes without an >>> introduction to TSCH. ____ >>> >>> I’d suggest you add a few words on RFC 7554 appendix A and >>> 6TiSCH architecture section 4.3.5. to introduce those >>> concepts.____ >>> >>> They should probably be normative references. >>> >>> >>> TC: I added the following text at beginning of section 2: >>> In a TSCH network, time is sliced up into time slots. >>> The time slots are grouped as one of more slotframes >>> which repeat over time. >>> The TSCH schedule instructs a node what to do at each >>> time slots, such as transmit, receive or sleep <xref >>> target="RFC7554"/>. >>> In case of a slot to transmit or receive, a channel >>> is assigned to the time slot. >>> The tuple (slot, channel) is indicated as a cell of >>> TSCH schedule. >>> MSF is one of the policies defining how to manage the >>> TSCH schedule. >> >> Excellent >>> >>> ____ >>> >>> __ __ >>> >>> __ __ >>> >>> __ __ >>> >>> __ __ >>> >>> Section 4 has numerous SHOULD. Trouble is, when SHOULD is >>> used, the author SHOULD explain the alternate, what if the >>> SHOULD is not followed. ____ >>> >>> Sometimes it’s quite obvious, like when using random in 4.2. >>> But SHOULD use minimal is less obvious. Please consider >>> adding text after the SHOULDs. >>> >>> >>> TC: agreed! I have resolved this SHOULD issues in a new version. >>> either the unnecessaries are removed or alternative explanation >>> is added >> >> I’ll review once you published >>> >>> ____ >>> >>> __ __ >>> >>> __ __ >>> >>> __ __ >>> >>> field it contains, the presence and contents of the IE >>> defined in____ >>> >>> [I-D.richardson-6tisch-join-enhanced-beacon <https://tools.ietf.org/html/draft-ietf-6tisch-msf-08#ref-I-D.richardson-6tisch-join-enhanced-beacon>], or the key used to____ >>> >>> authenticate it.____ >>> >>> __ __ >>> >>> The reference is now draft-ietf.. I agree that it should be >>> normative; no worries the draft is already submitted for >>> publication.____ >>> >>> More important: Please move the reference to >>> 6tisch-dtsecurity-zerotouch-join to informational. This is a >>> DOWNREF today and your draft may be stuck in MISSREF in the >>> future. >>> >>> >>> TC: I have updated *richardson-6tisch-join-enhanced-beacon* to >>> * ietf-6tisch-enrollment-enhanced-beacon.* >>> I didn't get it how "*move the reference to >>> 6tisch-dtsecurity-zerotouch-join to informational*" is done in >>> the draft? >>> >> >> Sorry I was unclear. The draft is currently listed as a normative >> reference. This means that MSF will be held forever in miss ref at >> the RFC editor. Please move the link to the reference in the >> informational references section. >>> >>> ____ >>> >>> __ __ >>> >>> __ __ >>> >>> __ __ >>> >>> After selected a preferred parent, the joined node MUST >>> generate a 6P____ >>> >>> __ __ >>> >>> Grammar: “After selecting” or “once it has selected” sound >>> better. ____ >>> >>> __ >>> >>> TC: the latter sounds better! Thanks! >>> >>> __ >>> >>> __ __ >>> >>> __ __ >>> >>> Section Section 8 <https://tools.ietf.org/html/draft-ietf-6tisch-msf-08#section-8>____ >>> >>> __ __ >>> >>> The <xref …> already generates the word “section”. If you >>> write it too, it becomes duplicated as above. >>> >>> >>> TC: agreed! >>> >>> ____ >>> >>> __ __ >>> >>> __ __ >>> >>> __ __ >>> >>> For a node, this translates into____ >>> >>> monitoring the current usage of the cells it has to its >>> preferred____ >>> >>> parent:____ >>> >>> __ __ >>> >>> This is disturbing. MSF should not be used only with >>> preferred parents. The whole game of doing a DODAG is to have >>> and possibly use multiple parents. ____ >>> >>> A node can for instance send a NSM DAO with multiple transit >>> options to the root. Also, it could be good to clarify that >>> the child manages both directions. ____ >>> >>> Proposal:____ >>> >>> __ __ >>> >>> For a node, this translates into____ >>> >>> monitoring the current usage of the cells it has to the >>> parents it uses____ >>> >>> at this point of time for sending and receiving traffic:____ >>> >>> __ __ >>> >>> Later there a numerous references to “preferred parent” => >>> I’d suggest you use just “selected parent” or “active parent” >>> or something in that vein. >>> >>> TC: I think "preferred parent" is same with "selected parent". >>> it indicates one preferred parent out of multiple. Isn't it right? >> >> My problem is that there’s only one preferred parent, but a node >> may use several parents for data traffic. This is why we build >> dodags in the first place. >> >> I believe that the node may allocate cells with all of those >> “selected parents” if it likes. The use of “preferred parent” in >> that text would prevent this. >> >> Please make sure your text does not limit to one parent... >>> >>> ____ >>> >>> __ __ >>> >>> __ __ >>> >>> Cell installed at initial____ >>> >>> __ __ >>> >>> Not sure this is correct. Maybe “at init time” >>> >>> >>> TC: Applied! >>> >>> ____ >>> >>> __ __ >>> >>> __ __ >>> >>> __ __ >>> >>> __ __ >>> >>> It is recommended to set MAX_NUMCELLS value at____ >>> >>> least 4 times than the maximum link traffic load of the >>> network in____ >>> >>> packets per slotframe.____ >>> >>> __ __ >>> >>> __ __ >>> >>> This does not parse. Can you please rephrase? >>> >>> >>> TC: it's rephrased as "*It is recommended to set MAX_NUMCELLS >>> value at least 4x of the maximum link traffic load of the network >>> with unit of packets per slotframe*." >> >> I still have a hard time >> >> Do you mean “4 times the maximum number of used cells in a slot >> frame in recent history” ? >>> >>> ____ >>> >>> __ __ >>> >>> __ __ >>> >>> __ __ >>> >>> __ __ >>> >>> Section 8 does not try to avoid collisions with autocells. >>> But it’s easy to compute the slot offset of autocells for >>> self and parent and avoids those. Why not do that? >>> >>> >>> TC: agreed! Will apply in the next version. >>> >>> ____ >>> >>> __ __ >>> >>> __ __ >>> >>> __ __ >>> >>> Section 16 will require more attention, either now or during >>> secdir review, probably both. You should start now. Think, >>> say, what if an attacker claims many cells to all its >>> neighbors? Can it attack someone’s autocells to block him? >>> >>> >>> TC: That's a good question! It may have a chance to do so. We >>> need discuss internally on this section. >>> Thanks for belling ahead! >> >> Speaking from experience with secdir. Better be prepared they will >> be coming for you ; ) >> >> Take care >> >> Pascal >>> >>> ____ >>> >>> __ __ >>> >>> __ __ >>> >>> __ __ >>> >>> Voila!____ >>> >>> __ __ >>> >>> Pascal as shepherd.____ >>> >>> __ __ >>> >>> __ __ >>> >>> __ __ >>> >>> __ __ >>> >>> __ __ >>> >>> __ __ >>> >>> _______________________________________________ >>> 6tisch mailing list >>> 6tisch@ietf.org <mailto:6tisch@ietf.org> >>> https://www.ietf.org/mailman/listinfo/6tisch >>> >>> >>> >>> -- >>> —————————————————————————————————————— >>> >>> Dr. Tengfei, Chang >>> Postdoctoral Research Engineer, Inria >>> >>> www.tchang.org/ <http://www.tchang.org/> >>> —————————————————————————————————————— >> >> >> >> -- >> —————————————————————————————————————— >> >> Dr. Tengfei, Chang >> Postdoctoral Research Engineer, Inria >> >> www.tchang.org/ <http://www.tchang.org/> >> —————————————————————————————————————— > > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch >
- [6tisch] MSF Shepherd review Pascal Thubert (pthubert)
- Re: [6tisch] MSF Shepherd review Tengfei Chang
- Re: [6tisch] MSF Shepherd review Pascal Thubert (pthubert)
- Re: [6tisch] MSF Shepherd review Tengfei Chang
- Re: [6tisch] MSF Shepherd review Pascal Thubert (pthubert)
- Re: [6tisch] MSF Shepherd review Pascal Thubert (pthubert)
- Re: [6tisch] MSF Shepherd review Yasuyuki Tanaka
- Re: [6tisch] MSF Shepherd review Pascal Thubert (pthubert)
- Re: [6tisch] MSF Shepherd review Prof. Diego Dujovne
- Re: [6tisch] MSF Shepherd review Yasuyuki Tanaka
- Re: [6tisch] MSF Shepherd review Pascal Thubert (pthubert)
- Re: [6tisch] MSF Shepherd review Tengfei Chang
- Re: [6tisch] MSF Shepherd review Yasuyuki Tanaka
- Re: [6tisch] MSF Shepherd review Tengfei Chang
- Re: [6tisch] MSF Shepherd review Pascal Thubert (pthubert)
- Re: [6tisch] MSF Shepherd review Tengfei Chang