Re: [6tisch] MSF Shepherd review

[Tengfei Chang <[e-mail]>]

Thanks Pascal, just integrated your suggestions to the latest version.

On Sat, Dec 7, 2019 at 12:00 AM Pascal Thubert (pthubert) <
[e-mail]> wrote:

> Very good Tengfei
>
> This addresses my comments.
>
> Note that the uppercase NOT is not a valid BCP14 term by itself. I’d
> reword to say that the distribution of traffic over multiple parents is a
> routing decision that is out of scope for MSF...
>
>
> Regards,
>
> Pascal
>
> Le 6 déc. 2019 à 12:01, Tengfei Chang <[e-mail]> a écrit :
>
> 
> I will add the following text at the intro part of MSF draft:
>
>
>
>
>
>
> *                MSF works closely with RPL, specifically the routing
> parent defined in <xref target="RFC6550" format="default"/>.
>   This specification only describes how MSF works with one routing parent,
> which is phrased as "selected parent".                 The activity of MSF
> towards to single routing parent is called as a "MSF session".
>     Though the performance of MSF is evaluated only when the "selected
> parent" represents node's preferred parent, there should be no restrictions
> to go multiple MSF sessions, one per parent.                 In case that
> traffic goes into multiple parents, MSF is NOT in charge of deciding how
> many traffic to assign or to which parent.                 This should be
> decided by either upper layer or some other entity in charge of traffic
> distributing.*
>
> Then replace the sentence in the draft from "preferred parent" to
> "selected parent".
>
> What are your comments on this, Pascal, Yatch?
>
> On Sat, Nov 30, 2019 at 12:31 AM Pascal Thubert (pthubert) <
> [e-mail]> wrote:
>
>> Hello Yatch
>>
>>
>>
>> > Le 29 nov. 2019 à 22:48, Yasuyuki Tanaka <[e-mail]> a
>> écrit :
>> >
>> > Thank you, Pascal for your comment.
>> >
>> >> On 11/29/2019 9:34 PM, Pascal Thubert (pthubert) wrote:
>> >> RPL underneath is designed to operate with multiple parents, and for a
>> good reason.
>> >
>> > I understand that point.
>> >
>> > My point is, rephrasing the word alone couldn't be enough.
>> >
>> >> 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.
>> >
>> > In general, yes. According to the current text of MSF, the direction is
>> relevant. For a upward neighbor, MSF allocates one negotiated TX cell just
>> after recognizing it. For a downward neighbor, it doesn't.
>> >
>> > On parent switch, the number of negotiated cells is carried over to a
>> new parent. But what if a node has one parents at some point, then it
>> selects an additional parent to handle some portion of traffic? How many
>> negotiated cells should be scheduled with the new (additional) parent? MSF
>> would have no idea.
>> >
>> > To me, this seems a totally new thing to MSF.
>> >
>>
>> Not that new just the logical continuation.
>>
>> If a child has 2 parents a and b these are independent links, each with a
>> number of cells. If it loses one parent a then the traffic on that link is
>> rerouted. The cells on that link have to be moved to other parents which
>> can include b.
>>
>> The existing cells to the parent b are not touched. If some traffic is
>> rerouted to parent b then new cells are allocated there.
>>
>>
>> > Again, having multiple MSF instances could be a solution, which doesn't
>> need the rephrasing.
>>
>> For me instance is related to RPL I do not want to run multiple instances
>> of RPL with one preferred parent each.
>>
>> What I want is to run what the draft describes but several times in
>> parallel once per active parent.
>>
>> That’s what I called session. RPL says that a node can run separate
>> instances like ship in the night and then describes the operw of one
>> instance. Similarly MSF can run multiple sessions one per link as ship in
>> the night. pretty much the draft needs to do is say that in introduction
>> and then say that the rest of the draft describes one session with one
>> parent.
>>
>> >> And it is possible to run an MSF session at L2 with each of them
>> totally independently.
>> >
>> > What do you mean by "MSF session"? If you have multiple MSF instances
>> with different SFIDs or values for the Metadata field, they can be
>> associated with different RPL DODAGsm and they will work independently.
>> >
>>
>> The draft describes a session between a parent and a child. They start
>> the session, allocate resources in unison and when the session is broken
>> they release the resources on each side. This happens within a L2 link.
>> Sessions can live independently on different L2 links.
>>
>>
>>
>> > On 11/29/2019 9:40 PM, Prof. Diego Dujovne wrote:
>> > > Would it be then a neighbour instead of a parent? (Assuming the
>> > > neighbour has joined the network)
>> >
>> > I don't think so.
>> >
>>
>> As Yatch said the draft describes a child handling both sides so the link
>> is directional, there’s a master and a slave.
>>
>> This may become a problem for east west traffic with PDAO. But there’s
>> still a direction so it’s doable just need to agree that the parent is
>> towards the destination.
>>
>> All the best,
>>
>> Pascal
>>
>>
>> > Best,
>> > Yatch
>> >
>> > _______________________________________________
>> > 6tisch mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/6tisch
>> _______________________________________________
>> 6tisch mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/6tisch
>>
>
>
> --
> ——————————————————————————————————————
>
> Dr. Tengfei, Chang
> Postdoctoral Research Engineer, Inria
>
> www.tchang.org/
> ——————————————————————————————————————
>
>

-- 
——————————————————————————————————————

Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria

www.tchang.org/
——————————————————————————————————————