Subject: Re: [6tisch] MSF Shepherd review

From: Tengfei Chang <[email-masked]>
Date: Fri, 6 Dec 2019 21:00:22 +0100

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) <
[email-masked]> wrote:

> Hello Yatch
>
>
>
> > Le 29 nov. 2019 à 22:48, Yasuyuki Tanaka <[email-masked]> 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
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/6tisch
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>

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

Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria

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

---

From: Yasuyuki Tanaka <[email-masked]>
Date: Fri, 6 Dec 2019 21:43:02 +0100

Hi Tengfei,

How do we distinguish multiple MSF sessions?
What if two MSF sessions have a same "selected parent", and then one of 
them selects another selected parent? How many negotiated cells should 
be taken over to the new selected parent?

These are not covered by the current text, and I think they are out of 
the scope of MSF.

> This specification only describes how MSF works with one routing parent, which is phrased as "selected parent".

So, yes, I believe we should have this case only in the text. If we 
mention some other possibilities without concrete ideas to implement, 
they would just confuse future readers.

I think, Pascal has a different opinion.

Best,
Yatch

---

From: Tengfei Chang <[email-masked]>
Date: Fri, 6 Dec 2019 22:30:12 +0100

Hi Yatch,

The session is distinguished by the parent, there is no such case that two
MSF sessions have a 'common parent'.
MSF session to parent is 1 to 1 mapping relationship.
MSF session should be ends as long as a neighbor is un-selected as parent.

In the text, I agree we only details how MSF deal with one parent.
I think Pascal agree with this but just don't want to limit MSF to just one
parent, which is clarified in the paragraph I wrote above.

Tengfei

On Fri, Dec 6, 2019 at 9:43 PM Yasuyuki Tanaka <[email-masked]>
wrote:

> which is phrased as "selected parent".
>

Dr. Tengfei, Chang

www.tchang.org/

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 6 Dec 2019 23:00:03 +0000

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 <[email-masked]> a écrit :

                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".

On Sat, Nov 30, 2019 at 12:31 AM Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
Hello Yatch

> Le 29 nov. 2019 à 22:48, Yasuyuki Tanaka <[email-masked]<mailto:[email-masked]>> a écrit :
>
>> RPL underneath is designed to operate with multiple parents, and for a good reason.
>
> I understand that point.
>
>> 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.
>

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.

> > neighbour has joined the network)

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

> [email-masked]<mailto:[email-masked]>
_______________________________________________
6tisch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tisch

Dr. Tengfei, Chang

www.tchang.org/<http://www.tchang.org/>
——————————————————————————————————————

---

From: Tengfei Chang <[email-masked]>
Date: Sat, 7 Dec 2019 12:48:58 +0100

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

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

> 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
>
>> 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.
>>
>>
>>

Dr. Tengfei, Chang

www.tchang.org/