Re: [6tisch] MSF Shepherd review

["Prof. Diego Dujovne" <[e-mail]>]

Would it be then a neighbour instead of a parent? (Assuming the neighbour
has joined the network)
Regards,

            Diego

El vie., 29 de noviembre de 2019 17:34, Pascal Thubert (pthubert) <
[e-mail]> escribió:

> Spot on Yatch
>
> MSF manages the bandwidth over one L2 hop based on the packets that L3
> places on that hop.
>
> Bandwidth allocation doesn’t care what traffic that is or it’s direction.
> It cares about the amount of traffic that needs to circulate over the hop.
>
> The sense of direction came from the design decision that the child makes
> the request in both directions. That’s your design and that’s fine with me.
>
>  But the child can have multiple L2 Links to different parents. Even if
> they use the same radio it is still as many links that live independent
> lives. And it is possible to run an MSF session at L2 with each of them
> totally independently.
>
> Whether you already tested it is another topic. We do not need to test it
> immediately to progress the draft. But a draft that supports only one
> parent is not acceptable because it degrades the routing functionality too
> much. RPL underneath is designed to operate with multiple parents, and for
> a good reason.
>
> Regards,
>
> Pascal
>
> > Le 29 nov. 2019 à 20:41, Yasuyuki Tanaka <[e-mail]> a
> écrit :
> >
> > 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 <[e-mail]> 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) <
> [e-mail] <mailto:[e-mail]>> wrote:
> >>>
> >>>    Hello Tengfei
> >>>
> >>>
> >>>    Please see below
> >>>
> >>>>    Le 27 nov. 2019 à 21:44, Tengfei Chang <[e-mail]
> >>>>    <mailto:[e-mail]>> a écrit :
> >>>>
> >>>>    
> >>>>    Thanks a lot for the reviewing, I responded inline:
> >>>>
> >>>>    On Mon, Nov 25, 2019 at 6:42 PM Pascal Thubert (pthubert)
> >>>>    <[e-mail] <mailto:[e-mail]>> 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
> >>>>        [e-mail] <mailto:[e-mail]>
> >>>>        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
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/6tisch
> _______________________________________________
> 6tisch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6tisch
>