Re: [6tisch] MSF Shepherd review

["Pascal Thubert (pthubert)" <[e-mail]>]

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]<mailto:[e-mail]>> wrote:
Hello Yatch



> Le 29 nov. 2019 à 22:48, Yasuyuki Tanaka <[e-mail]<mailto:[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]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________
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/>
——————————————————————————————————————