Re: [6tisch] Yatch's review on draft-ietf-6tisch-msf-08 - Re: MSF review

Tengfei Chang <> Wed, 27 November 2019 20:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 324A51209F0 for <>; Wed, 27 Nov 2019 12:05:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sDXR4trhFHTP for <>; Wed, 27 Nov 2019 12:05:19 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2E056120919 for <>; Wed, 27 Nov 2019 12:05:19 -0800 (PST)
Received: by with SMTP id h13so10328357plr.1 for <>; Wed, 27 Nov 2019 12:05:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3DFOzESLZJE7GAlYRT8UW7lC+yfG7+SeLdNppAMieys=; b=Ra+PPXkEt7Vf0TR8zQu2FKEs41jbvdLiULC4rPQ7Nk6HTpBpRWwRIRJUex0UPjwjXE IFEDn7uppZClGPPJFUNo5X17zsa2jYx/Fl6QC+77c3n+iK/wLEOXcJchCa53det19xHu N9HsnZfxejobQ8+s34bFu1BunVLhrDvL1cslqo4m/EDfDeK/1fAka+1DGjeUt2c+G427 XB/sAWq+/nhmlbmxYTcRSykz9XSky9i+IKYert0Ki9ZYeQzWcqt4OoXoUK1+a/+9l9ev cglc+pldVolnD49LtvC4RAWbr/rZoEixPbSRDtTWUsB8bI8nM2KVFD0OxNXFK2pW2GCp MQ5w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3DFOzESLZJE7GAlYRT8UW7lC+yfG7+SeLdNppAMieys=; b=R+vetHjeIHYWUsp8BEH4WxIOs6gtLWAHg1pcPxIT85HfouYzPJu4aMi3EVOmrWBI/d /t4acI5oA0Ee4DBWEA4M1gpKlU8NpNPccoJ++pBSc9/QdkWp/cz5vfx2JgT5zqFIJJ6t 5jeOucQUNfrb+DuKU6t6GemoTWyDVnVEUG2A2S78BqMvFpY5dmXI8UOpJbID3o23l0IY F8kmAWA6db/mOELKXswAmGXdMN3VIU+aiCFVScz9seAqcxwycXkw29m0tvSKtWcwFnx+ 0Wz7D083P5KOVteHM1q5f8y0TrUtQX5WNQraPQe8gRq3gxh6hfCDUuD+YLyIt5k/8M7u gXdA==
X-Gm-Message-State: APjAAAU+P4Yu2HIDoG57iJvQlg5v508O4SGHoAXwhwu4bG3EbfH2XZE6 YC72r/2YKv/4EloZwiU0zEw2XkQz71TIQ77/1h9IML0szwY=
X-Google-Smtp-Source: APXvYqy+eZaNhA25irJrn0pX+vFuUueCBGvTuzPMVpSuIrIIbc5RMLEkhBRRJ2xBHMY5jzXIIX6VAXDSpTwj51FdCqU=
X-Received: by 2002:a17:90a:9604:: with SMTP id v4mr7978380pjo.105.1574885118358; Wed, 27 Nov 2019 12:05:18 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Tengfei Chang <>
Date: Wed, 27 Nov 2019 21:05:06 +0100
Message-ID: <>
To: Yasuyuki Tanaka <>
Cc: 6tisch <>
Content-Type: multipart/alternative; boundary="0000000000000abba605985984ab"
Archived-At: <>
Subject: Re: [6tisch] Yatch's review on draft-ietf-6tisch-msf-08 - Re: MSF 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: Wed, 27 Nov 2019 20:05:22 -0000

Hi Yatch,

Thanks a lot for the comments! I will response inline!

On Tue, Nov 26, 2019 at 3:21 PM Yasuyuki Tanaka <>

> Hi all,
> I reviewed draft-ietf-6tisch-msf-08. Here are my comments;
> * [clarification] Section 1
> draft> the 6 steps described in Section 4.  The end state of the join
> draft> process is that the node is synchronized to the network, has
> draft> mutually authenticated to the network, has identified a
> draft> preferred routing parent, and has scheduled one default
> draft> negotiated cell (defined in Section 5.1) to/from its preferred
> draft> routing parent. After the join
> Here, saying "one negotiated TX cell" would be clearer instead of "one
> default negotiated cell".
TC: Agree!

> * [clarification] Section 2
> draft> ..., while Slotframe 0 is used for the bootstrap traffic as
> draft> defined in the Minimal 6TiSCH Configuration.
> I think this part is misleading. Slotframe 0 has the minimal shared
> cell, which is basically used for all broadcast frames including EBs
> and DIOs. These frames are needed not only for the bootstrap phase.
> Given that, the following part seems a little bit strange as well.
> draft> MSF uses the minimal cell to exchange the following packets:
> draft>
> draft> 1.  Enhanced Beacons (EBs), defined by [IEEE802154-2015].
> draft>     These are broadcast frames.
> draft> 2.  Broadcast DODAG Information Objects (DIOs), defined by
> draft>     [RFC6550].  Unicast DIOs SHOULD NOT be sent on minimal cell.
> Why don't we say just, "the minimal cell is used for broadcast frames
> such as Enhanced Beacons (EBs) and broadcasted DODAG Information
> Objects (DIOs)"? I would add, "Cells scheduled by MSF are meant to be
> used only for unicast frames."

TC: Agree!  Will update the text accordingly.

> * [clarification] Section 3
> draft> The default slotframe length (SLOTFRAME_LENGTH) is RECOMMENDED
> draft> for Slotframe 0, 1 and 2, although any value can be advertised
> draft> in the EBs.
> Does this mean, these three slotframes can have different lengths? Or,
> the slotframes have the same length, which may be different from
> I don't know why we want to accept the former case, which makes MSF
> more complex.
> A related description is found in the latter part of the section:
> draft> stated in [IEEE802154-2015].  However, when the Slotframe 0, 1
> draft> and 2 use the same length value, it is possible for negotiated
> draft> cell to avoid the collision with AutoRxCell.

TC: for the former case,
the length of slotframe 0 could change the bandwidth of the EB to sent,
which could be helpful to be customizable.
the length of slotframe 1 could influence the hash function performance,
such as reducing the collision.
the length of  slotframe 2 changes application traffic bandwidth resolution.

However, those are out-of-scope of MSF.
The same length of all slotframes avoids the collision of cell allocation,
which benefit the performance of MSF. So it's a recommend way to do.

> * [technical] Section 4.8
> The whole part of this section doesn't seem to be part of the
> bootstrapping process. This describes how to handle unused cells,
> which is part of the "housekeeping".
> More importantly, the idea mentioned here doesn't look good, which is
> not a "SHOULD" thing from my view point.
> What if your child switches its preferred parent from you to another
> node, and a CLEAR request sent by the child doesn't reach you because
> of bad luck? The child loses all the cells scheduled with you, but
> it's still in your communication range. The child will respond to your
> keep-alive message, which prevents you from removing cells which will
> no longer used. Another example is a case where your child reboots and
> selects another node as its preferred parent.
> A relevant discussion on ML:
> So, I would suggest:
> - removing Section 4.8 entirely
> - adding a subsection to Section 5, mentioning a need for a mechanism
>    removing up unused negotiated cells, without proposing a concrete
>    idea
> draft> When a neighbor is declared unreachable, the node MUST remove
> draft> all negotiated cells with that neighbor from its own schedule.
> draft> In addition, it MAY issue a 6P CLEAR to that neighbor (which
> draft> can fail at the link-layer).  The node MAY be removed from the
> draft> neighbor table.
> In addition, the behavior described above, CLEAR from a parent to its
> old child, contradicts what Section 8 says:
> draft> MSF uses 2-step 6P Transactions exclusively.  6P transactions
> draft> are only initiated by a node towards its preferred parent.
> If we want to keep the idea in the text, then I would propose sending
> a COUNT request instead of a (some form of?) keep-alive frame. This
> would cause RC_ERR_SEQNUM in the examples given above, and a CLEAR
> transaction will follows. And, I wouldn't use SHOULD or MUST there,
> leaving it to implementers.

TC: I think the reason why we use the keep-alive is because it's already
explained in the standard and we don't need to redefine anything.
Using 6P COUNT sounds better than the keep-alive, but then we need to
define how often the 6P COUNT is going to send to the neighbor, which may
need additional discussion.

TC: I tend more to state the issue and declare some mechanism to resolve is
required but not provide one. (your first solution.)

> [clarification] Section 5.1
> It is unclear whether we should have separate pairs of
> NumCellsElapsed/NumCellsUsed for negotiated TX cells and negotiated RX
> cells or not.

> If we have NumCellsUsed dedicated for RX, the following text is not
> correct:
> draft> NumCellsUsed: Counts the number of negotiated cells that have
> draft>     been used.This counter is initialized at 0.  NumCellsUsed
> draft>     is incremented by exactly 1 when, during a negotiated cell
> draft>     to the preferred parent, either of the following happens:
> We need to increment NumCellsUsed when receiving a frame on the
> *autonomous* RX cell while there is no negotiated RX cells scheduled
> with the preferred parent. In this case, NumCellsUsed counts how many
> times the *autonomous* RX cell is used. This is not aligned with what
> is described in Section 5.1.
> The same thing is seen in the definition of NumCellsElapse.
> An expected process I believe is:
>    if we have negotiated RX cells scheduled with the preferred parent:
>      - NumCellsElapse: the number of times negotiated RX cells are
>        visited
>      - NumCellsUsed: the number of times negotiated RX cells are used
>    else
>      - NumCellsElapse: the number of times the autonomous RX cell is
>        visited
>      - NumCellsUsed: the number of times the autonomous RX cell is used

TC: this is the desired design, agreed that it's not clear. Will update the

> This is not well described in the current version.
> Another comment to this section is that, the counters shouldn't be
> updated by invalid frames, because we cannot guarantee the source
> address of an invalid frame is intact. Or, an attacker can trigger
> unnecessary 6P transactions by sending garbage frames over the
> autonomous RX cell of a victim node, although the expression of
> "invalid frame" is ambiguous.

TC: totally agree!

> draft> * The node receives a frame from its preferred parent.  The
> draft>   counter increments regardless of whether the frame is a valid
> draft>   IEEE802.15.4 frame or not.

> [question] Section 5.1
> draft> Meanwhile, the latency won't increase much by using a larger
> draft> value of MAX_NUMCELLS for periodic traffic type.
> Why...? With a larger MAX_NUMCELLS, MSF cannot react traffic increase
> quickly, which could results in many frames wauting in the TX
> queue

TC: Since the MSF installs additional cells for the traffic, which helps
when traffic changes slowly.

> An example is a case when a big sub-tree consisting of many
> nodes moves to you.

TC: The original sentense is saying for periodic traffic type. This is
considered as bursty traffic.

> Incoming traffic increases a lot, but you don't
> have enough cells to handle. Negotiated TX cells are added one by one
> with an interval determined by MAX_NUMCELLS. Then, latency from the
> point of the topological change will get high.
> By the way, the default or recommended value of MAX_NUMCELLS is 8?
> MAX_NUMCELLS is not listed in Figure 3.

TC: 8 is just a value in the example, not recommended. For periodic
traffic, or traffic load changes slowly, a larger MAX_NUMCELLS is preferred.
Some proposal for the recommended value of MAX_NUMCELLS: 64 (power of 2),
or 100.

> [question] Section 5.2
> After a parent switch, which type of the negotiated cell should be
> scheduled first, TX or RX? Any recommendation?

TC: That depends on which has a high priority, the upstream traffic or
downstream traffic.  It should be applications-specific.

> draft> 1.  the node counts the number of negotiated cells it has per
> draft>     slotframe to the old preferred parent
> draft> 2.  the node triggers one or more 6P ADD commands to schedule
> draft>     the same number of negotiated cells with same cell options
> draft>     to the new preferred parent
> [clarification] Section 5.3
> It would be better to mention explicitly RELOCATION for negotiated RX
> cells are not supported. If MSF supports it, we need text describing
> how.

TC: agreed!

> [possible error?] Section 5.3
> draft> preferred parent.  When NumTx reaches 256, both NumTx and
> draft> NumTxAck
> The recommended size of NumTx is 1 byte, the maximum number of which
> is 255. See Section 15.

TC: thanks for pointing this out!

> * [question] Section 6
> draft> 6.  6P SIGNAL command
> draft>
> draft>    The 6P SIGNAL command is not used by MSF.
> Why do we need this section? How about other commands, COUNT and LIST,
> which are not mentioned in the draft at all?

TC: we only mentioned 6P SIGNAL, because that's 6P leaves it to scheduling
function, which must mention how it is used.
TC: For consistency, yes, maybe state COUNT and LIST are not used as well.

> If MSF doesn't support LIST, we don't need Section 8 and the rule for
> RC_EOL. Section 8 is provided for LIST, according to Xavi:
>  > >> What is Section 10, "Rule for Ordering Cells", for...? Why do we
>  > >> need this section?
>  > >>
>  > >
>  > > I'll let other co-authors answer
>  > >
>  >
>  > XV> I think this was though to handle pagination when the LIST
>  > command is received. This is, define what are the cells to return
>  > when a list command is requesting cells from a particular offset.
> See

TC: (personally thought) scheduling function doesn't need to use all the 6P
commands but, when it receives, the node will response still as part of 6P
(not MSF, I agree).
TC: The order of cells in the 6P LIST response, for example, could be
defined by MSF as a certain service. (such as during debugging, I am aware
different SF communicate ends with errors)
TC: I am slightly on keeping it but not strong option.

> [technical] Section 12
> draft> clear: Abort the 6P Transaction.  Issue a 6P CLEAR command to
> draft>     that neighbor (this command may fail at the link layer).
> draft>     Remove all cells scheduled with that neighbor from the
> draft>     local schedule.  Keep that node in the neighbor and routing
> draft>     tables.
> Manipulating the routing table is not a job of MSF nor 6top. I'm not
> sure what exactly the neighbor table is here, but I'd suggest removing
> the last sentence.

TC: agreed!

> * [nits/trivial suggestions]
> - Abstract: s/MSF builds/MSF is built/ ?
> - Section 1: "the root" --> "the DODAG root" or "the RPL DODAG root"
> - Section 3: "time offset" --> "slot offset"
> - Section 3: "the frame to be transmitted" --> a unicast frame ..."
> - Section 5.1: dwonstream --> downstream
> - Section 5.3: remove "(and need to be retransmitted)", it's redundant.
> - WAITDURATION_MIN --> WAIT_DURATION_MIN (for readability)
> - MAX_NUMCELLS --> MAX_NUM_CELLS (for readability)

TC: all accepted! Thanks a lot!

> Best,
> Yatch
> _______________________________________________
> 6tisch mailing list


Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria