Re: [6tisch] MSF Shepherd review

Yasuyuki Tanaka <> Fri, 29 November 2019 21:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CB2511200B3 for <>; Fri, 29 Nov 2019 13:47:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.9
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QYXowOIW99JD for <>; Fri, 29 Nov 2019 13:47:26 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D776C120048 for <>; Fri, 29 Nov 2019 13:47:25 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.69,258,1571695200"; d="scan'208";a="414207257"
Received: from (HELO []) ([]) by with ESMTP/TLS/DHE-RSA-AES128-SHA; 29 Nov 2019 22:47:24 +0100
Cc:, "" <>
To: "Pascal Thubert (pthubert)" <>
References: <> <> <> <> <> <> <>
From: Yasuyuki Tanaka <>
Message-ID: <>
Date: Fri, 29 Nov 2019 22:47:24 +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: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [6tisch] MSF Shepherd review
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" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 29 Nov 2019 21:47:28 -0000

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.

Again, having multiple MSF instances could be a solution, which doesn't 
need the rephrasing.

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

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.