Subject: [6tisch] call for review: draft-ietf-6tisch-msf-04

From: Tengfei Chang <[email-masked]>
Date: Tue, 2 Jul 2019 12:57:07 +0200

Dear all,

As you may noticed that a new version of MSF is just published at here:
https://tools.ietf.org/html/draft-ietf-6tisch-msf-04
There are some moderate changes comparing to previous one.

Mainly in two aspects:

1. change the concept of autonomous cell

In the new version, there will be two type of autonomous cells:
- autoTxCell, which is scheduled on demand for just transmitting
-autoTxCell, which is schedule permanently, for just receiving
(the previous version the autonomous cell are used as bidirectional)

More details about how to use those autonomous cell is available in the
draft.

2. re-added the downstream traffic adaptation feature

Though, there are cases that the node doesn't receive packet because of
collision, we assume the influence won't be much to adapt the downstream
traffic.
We will evaluate the performance of this changes.

We are targeting to have a new version before the submission deadline.
During the time, we will evaluate the v4 MSF and would like to have your
comments as well.

Thanks in advance!

Tengfei

-- 
Chang Tengfei,
Postdoctoral Research Engineer, Inria

---

From: Yasuyuki Tanaka <[email-masked]>
Date: Tue, 2 Jul 2019 14:58:28 +0200

Thank you, Tengfei and the other authors, for the update!

Here are my comments:

[Major] Negotiated RX cell (Section 4.6)

https://tools.ietf.org/html/draft-ietf-6tisch-msf-04#section-4.6

If MSF is designed for regular upstream traffic, I don't think we need
the negotiated RX cell that is introduced by this new version.

I presume the purpose of the negotiated RX cell is, to have a
collision-free channel directed from parent to child. The parent may
have collisions on the autonomous TX cell to a node since children of
the node also use the cell to transmit their frames. However, once the
network converges, the children have negotiated TX cells to the
node. The parent of the node will be the only one who uses the
autonomous TX cell until a topological change happens.

I would rather keep unused cells in the slotframe for negotiated TX
cells to handle "regular upstream traffic" instead of using some of
them for negotiated RX cells (to receive frames from the parent).

I'm looking forward to seeing Tengfei's evaluation results, by the way
:-)

[Minor] AutoTxCell usage (Section 3)

https://tools.ietf.org/html/draft-ietf-6tisch-msf-04#section-3

Sorry for bringing this again and again, but *in general*, L2/TSCH
layer has no idea about its upper layers. Although you can implement a
6TiSCH stack in which TSCH is aware of upper layer contents of a frame
to transmit, that may not be always the case. That is, the second
bullet point, starting with "frame is used for...", may not be able to
be implemented.

In this sense, applying "MUST" to the second bullet point seems too
strict.

draft> AutoTxCell is not permanent in the schedule but added/deleted on
draft>    demand when there is a frame to sent.  Throughout the network
draft>    lifetime, nodes MUST maintain the autonomous cells as follows:
draft>
draft>    o  Add an AutoTxCell to the layer 2 source address which is indicated
draft>       in a frame when:
draft>
draft>       *  there is no 6P negotiated Tx cell in schedule for that frame to
draft>          transmit, and
draft>       *  the frame is used for protocol management purposes , such as
draft>          Join Request/Response, 6P Request/Response and any link-local
draft>          communication for RPL routing control.

[Minor] Unprotected frames on negotiated cells? (Section 5.1)

https://tools.ietf.org/html/draft-ietf-6tisch-msf-04#section-5.1

draft>   Both NumCellsElapsed and NumCellsUsed counters can be used to
draft>   negotiated cells with cell option TX=1 or Rx=1.  All the frames used
draft>   for increasing/decreasing the counters MUST be encrypted or
draft>   decryptable with the key get from joining process.

Will we have unprotected frames transmitted on negotiated TX/RX cells,
which are expected to be scheduled with *joined* nodes? I'm not sure
why the last sentence is necessary...

[Minor] Length of CellList (Section 8)

https://tools.ietf.org/html/draft-ietf-6tisch-msf-04#section-8

What should a node do when it receives a CellList shorter than 5?
Return RC_ERR_CELLLIST?

draft> 8.  Rules for CellList
draft>
draft>    MSF uses 2-step 6P Transactions exclusively.  6P Transactions are
draft>    only initiated by a node towards its preferred parent.  As a result,
draft>    the cells to put in the CellList of a 6P ADD command, and in the
draft>    candidate CellList of a RELOCATE command, are chosen by the node
draft>    initiating the 6P Transaction.  In both cases, the same rules apply:
draft>
draft>    o  The CellList SHOULD contain 5 or more cells.

[Trivial] Section 3. Autonomous Cells

https://tools.ietf.org/html/draft-ietf-6tisch-msf-04#section-3

draft>  o  The AutoRxCell MUST always remain scheduled.

*Always* is ambiguous. A node cannot schedule an AutoRxCell until it's
get synchronized, when the length of slotframe 1 is available.

[Trivial] nits / editorial

- "AutoUpCells" is still there
- s/behvaior/behavior/
- s/boostrap/bootstrap/
- s/sheduling/scheduling/
- s/negoitated/negotiated/
- s/neogtiated/negotiated/
- s/transcation/transaction/
- s/calulated/calculated/

That's all!
Yatch

---

From: <[email-masked]>
Date: Thu, 4 Jul 2019 02:15:44 +0000

Thanks for the update, Tengfei.

I think Auto{Tx,Rx}Cells are simpler than Auto{Up,Down}Cells, because
they are independent of parent switching.

Here are my comments.

- Section 3: address for AutoTxCells

msf-04> Autonomous Tx Cell (AutoTxCell), one cell at a
msf-04> [slotOffset,channelOffset] computed as a hash of the layer 2
msf-04> EUI64 source address in the frame to be transmitted
msf-04>
msf-04> ...
msf-04>
msf-04> Add an AutoTxCell to the layer 2 source address which is
msf-04> indicated in a frame when:

The destination address (not source address) of the frame should be
used to calculate the AutoTxCell, shouldn't it?

- Section 3: conflict between autonomous and negotiated cells

msf-04> In case of conflicting with a negotiated cell, autonomous
msf-04> cells take precedence over negotiated cell.

Now that autonomous cells and negotiated cells are in different
slotframes, this statement is a natural result of Section 6.2.6.4 of
IEEE 802.15.4-2015. I think it's a good idea to refer to it here.

- Section 5.1: CellOptions of 6P ADD

There is no specification on CellOptions (Tx/Rx/Shared) of 6P ADD
requests as a result of traffic adaptation. Is it up to implemtation?

- Section 5.2: parent switch

We can now remove items 1. and 2. because we don't have AutoUpCells.

- Section 5.3: counters for handling schedule collision

msf-04> The node MUST maintain the following counters for each managed
msf-04> unicast cell to its preferred parent:

I think the node should maintain the counters for each negotiated Tx
cell to ANY neighbor, not only to the preferred parent. That is
because schedule collision can occur to any Tx cell.

If a node had counters for each neighbor, the paragraph starting with
the following sentance would be unnecessary.

msf-04> Each time the node switches preferred parent (or during the
msf-04> join process when the node selects a preferred parent for the
msf-04> first time), both NumTx and NumTxAck MUST be reset to 0.

Although managing the counters for each neighbor is conceptually
simple, I admit it might be too much overhead for constrainted nodes.

BTW, there are still two occurrences of "managed unicast cell" in the
draft.

Best regards,
Toshio Ito

From: 6tisch <[email-masked]> On Behalf Of Tengfei Chang
Sent: Tuesday, July 02, 2019 7:57 PM
To: [email-masked]
Subject: [6tisch] call for review: draft-ietf-6tisch-msf-04

Dear all,

Mainly in two aspects:

More details about how to use those autonomous cell is available in the draft.

Though, there are cases that the node doesn't receive packet because of collision, we assume the influence won't be much to adapt the downstream traffic.
We will evaluate the performance of this changes.

We are targeting to have a new version before the submission deadline.
During the time, we will evaluate the v4 MSF and would like to have your comments as well.

Thanks in advance!

Tengfei

---

From: Yasuyuki Tanaka <[email-masked]>
Date: Thu, 4 Jul 2019 15:04:09 +0200

Hi Tengfei,

Another minor comment:

https://tools.ietf.org/html/draft-ietf-6tisch-msf-04#section-5.3
draft> 5.3.  Handling Schedule Collisions
draft>
draft> A node implementing MSF SHOULD implement the behavior described in
draft> this section.  The "MUST" statements in this section hence only apply
draft> if the node implements schedule collision handling.

I think some part of the section could be implementation-specific, for
instance, how to manage NumTx and NumTxAck internally.

draft> Each time the node switches preferred parent (or during the join
draft> process when the node selects a preferred parent for the first time),
draft> both NumTx and NumTxAck MUST be reset to 0.  They increment over
draft> time, as the schedule is executed and the node sends frames to its
draft> preferred parent.  When NumTx reaches 256, both NumTx and NumTxAck
draft> MUST be divided by 2.

I'd propose to remove the second sentence in the first paragraph,
which starts with "The "MUST" statements in this section...", and to
alter the section just to demonstrate how we can resolve "schedule
collisions" using 6P RELOCATE command.

Best,
Yatch

> On Jul 2, 2019, at 14:58, Yasuyuki Tanaka <[email-masked]> wrote:
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 4 Jul 2019 15:29:18 +0000

Hello Tengfei

Many thanks for this update : )

Please find some comments below

“
   To ensure there is enough bandwidth available on the minimal cell, a
   node implementing MSF SHOULD enforce some rules for limiting the
   traffic of broadcast frames.  For example, a Trickle Timer defined in
   [RFC6550<https://tools.ietf.org/html/rfc6550>] MAY be applied on DIOs.  However, this behvaior is
   implementation-specific which is out of the scope of MSF.

“
As you point out that text does not really belong here. Maybe just say that the normal operation of this spec requires some bandwidth available, e.g., on the minimal cell.
Typo in behavior

“4.1<https://tools.ietf.org/html/draft-ietf-6tisch-msf-04#section-4.1>.  Start State
“
This phase also includes a 6LoWPAN ND phase to exchange link local addresses with the JP and later with the 6LR. Seems that some implementation bypass that but that’s really not clean. Suggestion to add a reference to https://tools.ietf.org/html/draft-ietf-6tisch-architecture-24#section-4.2 to describe that phase and say that it requires both minimal sec ad 6LoWPAN ND (now RFC 8505).

“

      Autonomous Tx Cell (AutoTxCell), one cell at a

      [slotOffset,channelOffset] computed as a hash of the layer 2 EUI64

      source address in the frame to be transmitted (detailed in

      Section 4.4<https://tools.ietf.org/html/draft-ietf-6tisch-msf-04#section-4.4>).  Its cell options bits are assigned as TX=1, RX=0,

      SHARED=1.
“
You mean the destination address as opposed to source address?

“

   During this step, the pledge MAY synchronize to any EB it receives

   from the network it wishes to join.
“
In TSCH, time creates an event horizon whereby one only hears transmissions that start during guard time around the scheduled Rx time. If the text quoted above means only listen to timeslots that are aligned to the time in the particular EB, then the node will no more hear beacons that are not aligned with this. E.g., an attacker could offset EBs by 2ms from the network and nodes that synchronize will not hear other beacons any more. So a suggestion is that a node that listen to beacons does not synchronize till it has heard the count of beacons it is supposed to get.

“
4.5<https://tools.ietf.org/html/draft-ietf-6tisch-msf-04#section-4.5>.  Step 4 - Acquiring a RPL rank

   Per [RFC6550<https://tools.ietf.org/html/rfc6550>], the joined node receives DIOs, computes its own rank,
   and selects a preferred parent.

“

Suggestion to uppercase Rank like in RFC 6550

“
8<https://tools.ietf.org/html/draft-ietf-6tisch-msf-04#section-8>.  Rules for CellList

“
Maybe add a rule to listen to the cells for a few slotframes to ensure that they are not used by neighbors. This can be done proactively, like the node monitors the 5 randomly chosen cells all the time, even when there is no excess traffic, so a list of empty cells is ready when needed.

“
6P Timeout Value

“
I guess it is per peer? Shouldn’t it evolve like the RTO in RFC 6298 ?

“

   | IANA_6TISCH_SFID_MSF | Minimal Scheduling Function | RFCXXXX     |
   |                      | (MSF)                       | (NOTE:this) |

“

  *   maybe

   | IANA_6TISCH_SFID_MSF | Minimal Scheduling Function | RFC_THIS    |
   |                      | (MSF)                       |             |

All the best,

Pascal

From: 6tisch <[email-masked]> On Behalf Of Tengfei Chang
Sent: mardi 2 juillet 2019 12:57
To: [email-masked]
Subject: [6tisch] call for review: draft-ietf-6tisch-msf-04

Dear all,

Mainly in two aspects:

Thanks in advance!

Tengfei

---

From: Tengfei Chang <[email-masked]>
Date: Mon, 8 Jul 2019 13:49:39 +0200

Thanks a lot Yatch for reviewing the draft. I will reply inline:

> I'm looking forward to seeing Tengfei's evaluation results, by the way

I think the purpose is indeed trying to add support for downstream traffic.
I current doesn't have a strong option on this.

> draft>          communication for RPL routing control.

Hmm, it only requires read access from other layers right? It could be
implemented. But I agree MUST is too strict.  I just removed the MUST from
the sentence.

> why the last sentence is necessary...
Yes, it's removed in the next version.

> draft>    o  The CellList SHOULD contain 5 or more cells.

 Nothing happens actually, the 6P will process with less than 5 candidate
cells.
Though the SHOULD here is a little strong, I changed the SHOULD to
RECOMMENDED, to make it less constrain.

> get synchronized, when the length of slotframe 1 is available.

Yes, changed to " The AutoRxCell MUST always remain scheduled after
synchronized"

> - s/calulated/calculated/

Thanks for the typos list! They will be fixed in the next version.

---

From: Tengfei Chang <[email-masked]>
Date: Mon, 8 Jul 2019 14:05:51 +0200

Hi Toshio,

Thanks for reviewing the draft, let me reply you inline below:

> used to calculate the AutoTxCell, shouldn't it?

Yes, it should. Thanks for indicating it! Will be fixed in next version.

> IEEE 802.15.4-2015. I think it's a good idea to refer to it here.

Yes,  will be added in next version.

> requests as a result of traffic adaptation. Is it up to implemtation?

Yes, it's kind of implied in the draft that it can be Tx=1 only or Rx=1
only.
Will add this statement in the draft next version.

> We can now remove items 1. and 2. because we don't have AutoUpCells.

Removed. Thanks!

> simple, I admit it might be too much overhead for constrainted nodes.

Thanks for the comments! However, along the network time, the node won't
send upper layer packet s to non-parent neighbor.
In case of switching parent, the traffic will go on autoTx cell.

> BTW, there are still two occurrences of "managed unicast cell" in the

Will corrected in next version.

>
>
>
>
> Best regards,
>
> Toshio Ito
>
>
>
> *From:* 6tisch <[email-masked]> *On Behalf Of *Tengfei Chang
> *Sent:* Tuesday, July 02, 2019 7:57 PM
> *To:* [email-masked]
> *Subject:* [6tisch] call for review: draft-ietf-6tisch-msf-04
>
>
>
> Dear all,
>
>
>

---

From: Tengfei Chang <[email-masked]>
Date: Mon, 8 Jul 2019 14:13:27 +0200

Thanks a lot Pascal for reviewing the draft, my replies are inlines:

On Thu, Jul 4, 2019 at 5:30 PM Pascal Thubert (pthubert) <[email-masked]>
wrote:

>    [RFC6550 <https://tools.ietf.org/html/rfc6550>] MAY be applied on
> DIOs.  However, this behvaior is
>
> As you point out that text does not really belong here. Maybe just say
> that the normal operation of this spec requires some bandwidth available,
> e.g., on the minimal cell.
>
> Typo in behavior
>

 I think it's stated in the same meaning.   though, I fixed the typo.

>
>
>
> “4.1 <https://tools.ietf.org/html/draft-ietf-6tisch-msf-04#section-4.1>.
> Start State “
>
> This phase also includes a 6LoWPAN ND phase to exchange link local
> addresses with the JP and later with the 6LR. Seems that some
> implementation bypass that but that’s really not clean. Suggestion to add a
> reference to
> https://tools.ietf.org/html/draft-ietf-6tisch-architecture-24#section-4.2
> to describe that phase and say that it requires both minimal sec ad 6LoWPAN
> ND (now RFC 8505).
>

Thanks for the comments! We added one paragragh in the join process step to
indicate the process of ND. Will be in the next version.

>       Section 4.4 <https://tools.ietf.org/html/draft-ietf-6tisch-msf-04#section-4.4>).  Its cell options bits are assigned as TX=1, RX=0,
>
>       SHARED=1.
>
> “
>

Yes, Destinations address is correct. Thanks!

> In TSCH, time creates an event horizon whereby one only hears
> transmissions that start during guard time around the scheduled Rx time. If
> the text quoted above means only listen to timeslots that are aligned to
> the time in the particular EB, then the node will no more hear beacons that
> are not aligned with this. E.g., an attacker could offset EBs by 2ms from
> the network and nodes that synchronize will not hear other beacons any
> more. So a suggestion is that a node that listen to beacons does not
> synchronize till it has heard the count of beacons it is supposed to get.
>

Thanks a lot for the comments. I have checked the sentence as  what you
suggested.

>
>
>
>
> “
>
> *4.5* <https://tools.ietf.org/html/draft-ietf-6tisch-msf-04#section-4.5>*.
> Step 4 - Acquiring a RPL rank*
>
>
>
>
>
>    Per [RFC6550 <https://tools.ietf.org/html/rfc6550>], the joined node
> receives DIOs, computes its own rank,
>

Will apply  in the next version.

>
>
>
>
> “
> 8 <https://tools.ietf.org/html/draft-ietf-6tisch-msf-04#section-8>.
> Rules for CellList
>
>
>
> “
>
> Maybe add a rule to listen to the cells for a few slotframes to ensure
> that they are not used by neighbors. This can be done proactively, like the
> node monitors the 5 randomly chosen cells all the time, even when there is
> no excess traffic, so a list of empty cells is ready when needed.
>

I think it's not necessary to listen on the cells because when the 6P
transaction starts , those cells should be locked and not be applied for
other 6P transactions.

> I guess it is per peer? Shouldn’t it evolve like the RTO in RFC 6298 ?

I think it's different from the RTO in RFC6298. In stead of traffic
congestion control, the Timeout here is mostly influenced by one hop link
quality.

>    - maybe

Will be applied in the next version!

> All the best,

Thanks a lot again for reviewing the draft and the comments!

> *Sent:* mardi 2 juillet 2019 12:57
> *To:* [email-masked]

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 8 Jul 2019 12:52:06 +0000

Hello Tengfei
tions address is correct. Thanks!

“

Thanks a lot for the comments. I have checked the sentence as  what you suggested.

Ø    The text was not expected to become normative as is; obviously the usual ways apply like time out if some but not all beacons are received and sync to the best.

Ø

 “

“

I think it's not necessary to listen on the cells because when the 6P transaction starts , those cells should be locked and not be applied for other 6P transactions.

  *   The point is that another pair of devices may have negotiated a cell that shows in the list, which you may discover if you screen the cells you want to use before you start using them.
  *   It really depends if you have a pool of cells that you own (e.g., admin) or just grab them pseudorandomly. In the latter case no checking the cells is impolite, and checking them just before using them may miss a partial usage. Listening to a pool of cell even when you do not allocate them is safer.

“
6P Timeout Value

“

I think it's different from the RTO in RFC6298. In stead of traffic congestion control, the Timeout here is mostly influenced by one hop link quality.

Which evolves and your value may track that, else it can be very big.

That’s a great spec  : )

Pascal

---

From: Tengfei Chang <[email-masked]>
Date: Wed, 10 Jul 2019 11:29:35 +0200

Hi Pascal,

On Mon, Jul 8, 2019 at 3:08 PM Pascal Thubert (pthubert) <[email-masked]>
wrote:

> Ø    The text was not expected to become normative as is; obviously the
> usual ways apply like time out if some but not all beacons are received and
> sync to the best.
>
> Ø
>
>
>
> Yes, I agree with what you said, I replied with a wrong typing word. What
I mean is: I have changed the sentence as you suggested:
It's rephrased as:

During this step, the pledge SHOULD NOT synchronize until it received
   enough EB from the network it wishes to join.

>    - The point is that another pair of devices may have negotiated a cell
>    that shows in the list, which you may discover if you screen the cells you
>    want to use before you start using them.
>    - It really depends if you have a pool of cells that you own (e.g.,
>    admin) or just grab them pseudorandomly. In the latter case no checking the
>    cells is impolite, and checking them just before using them may miss a
>    partial usage. Listening to a pool of cell even when you do not allocate
>    them is safer.
>
>
>
>
>
> I think this feature is defined in 6TOP  (RFC8480) with the term locked:

   Nodes A and B MAY support having two transactions going on at the
   same time, one in each direction.  Similarly, a node MAY support
   concurrent 6P Transactions with different neighbors.  In this case,
   the cells involved in an ongoing 6P Transaction MUST be "*locked*"
   until the transaction finishes.  ......

   If the requested cells are locked, it MUST reply to
   that request with a 6P Response with return code RC_ERR_LOCKED (as
   per Figure 38).  The node receiving RC_ERR_BUSY or RC_ERR_LOCKED MAY
   implement a retry mechanism as defined by the SF.

> Which evolves and your value may track that, else it can be very big.

Yes, this value is actually defined according to RFC8480:

3.4.4 <https://tools.ietf.org/html/rfc8480#section-3.4.4>.  6P Timeout

   A timeout occurs when the node that successfully sent a 6P Request
   does not receive the corresponding 6P Response within an amount of
   time specified by the SF.  In a 3-step transaction, a timeout also
   occurs when a node sending the 6P Response does not receive a 6P
   Confirmation.  When a timeout occurs, the transaction MUST be
   canceled at the node where the timeout occurs.  *The value of the 6P
   Timeout should be greater than the longest possible time it takes to
   receive the 6P Response or Confirmation.  The value of the 6P Timeout
   hence depends on the number of cells scheduled between the neighbor
   nodes, the maximum number of link-layer retransmissions, etc.  The SF
   MUST determine the value of the timeout. * The value of the timeout is
   out of scope for this document.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 10 Jul 2019 09:54:43 +0000

Hello Tengfei

I think you missed my points

>    The text was not expected to become normative as is; obviously the usual ways apply like time out if some but not all beacons are received and sync to the best.

Yes, I agree with what you said, I replied with a wrong typing word. What I mean is: I have changed the sentence as you suggested:
It's rephrased as:

Ø    I meant if you are configured to get 10 beacons but after an hour you get only one, will you wait for 1000 years?

Ø  During this step, the pledge SHOULD NOT synchronize until it received

Ø     enough EB from the network it wishes to join or times out trying

And here there should be an idea of a value for a number of beacons and a time out value. IESG reviews will ask that anyway so you better have something meaningful already.

 “

“

   the cells involved in an ongoing 6P Transaction MUST be "locked"

  *   Not the same problem. Think about this, where does the list of free cells come from? How does the parent decided let me propose cells 5, 6, 7 and 10?
  *   One possibility is that the controller has given them away as a chunk of cells that the parent manages, we have text in Archie for that.
  *   The other is that the parent picks them pseudo randomly. Which means that another parent next to him might pick the same. If that is the case they will collide
  *   This is an impolite behavior, the sort why we do CCA / LBT. In TSCH CCA and LBT are useless between synchronized nodes within a cell, but they can be useful before pseudo randomly grabbing a cell to add to the schedule. That cell should be observed using CCA for a while before it is proposed to the child in 6P. IOW there should be a pool of cells that are not used (yet) but observed (CCA) so you know you can allocate them safely later.

That’s a great spec  : )

Pascal

---

From: Esteban Municio <[email-masked]>
Date: Thu, 11 Jul 2019 13:47:56 +0000

Hi Tengfei,

I like the new changes, especially the concept of autonomous cells by
demand and always having by default 1 downlink negotiated cell. 

Here are some minor comments (checking msf-05):

* In Section 5.2, it is not clear for me if the parent switch occurs
before, during or after the 3-step procedure. My intuition says that is
should be after point 2: "the node triggers one or more 6P ADD commands
...". I guess it may be interesting to clarify when the actual parent
switch occurs.

* Also in the same section 5.2, it could be convenient (although maybe
redundant) to say in point 2 that the node has to schedule the same
number "and options" of negotiated cells. This would keep also the
ratio TX/RX with the new parent.

* Maybe out of the scope but, should not be defined here a housekeeping
function that removes unused negotiated cells (TX or RX)? For example
for cells that can't be removed with a 6P transaction (e.g. nodes are
not in range any more).

And some minor edit comments:

- "increaase"
- two "AutoUpCells" are still there
- two "managed unicast cell" are still there
- "it is possible for negotiated cell to avoid the collision with
AutoRxCell." Maybe "for a negotiated"?
- "For burst traffic type, larger value of MAX_NUMCELLS indeed
introduces higher latency." Maybe "a larger value"?

Kind regards,
Esteban

On Tue, 2019-07-02 at 12:57 +0200, Tengfei Chang wrote:
> Though, there are cases that the node doesn't receive packet because
> of collision, we assume the influence won't be much to adapt the
> downstream traffic.
-- 
Esteban Municio
PhD Researcher, IDLab, University of Antwerp, in collaboration with
imec
[email-masked]
The Beacon | Sint-Pietersvliet 7 | 2000 Antwerpen, Belgium

---

From: Yasuyuki Tanaka <[email-masked]>
Date: Wed, 17 Jul 2019 12:03:17 +0200

Hi Esteban,

> for cells that can't be removed with a 6P transaction (e.g. nodes are

It'd be nice to mention something there, at least like this:

  A node may remove negotiated cells scheduled with a neighbor which is
  considered as "unreachable", without having a 6P transaction. In that
  case, the node SHOULD reset the (6P) SeqNum for the neighbor. Specifying
  mechanisms to detect unreachable neighbors is out of scope of this
  document.

We used to have such a mechanism in previous versions, by the way:

https://tools.ietf.org/html/draft-ietf-6tisch-msf-02#section-4.8

I'm not sure what is the best way to do for that purpose when using MSF.

Best,
Yatch

> On Jul 11, 2019, at 15:47, Esteban Municio <[email-masked]> wrote:
> 
> Hi Tengfei,
> 
> ....". I guess it may be interesting to clarify when the actual parent
> switch occurs.
> 
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch

---

From: Tengfei Chang <[email-masked]>
Date: Wed, 17 Jul 2019 15:12:22 +0200

Hi Pascal,

For the synchronization, I agree. It should be listening for a
certain period of time and then choose which EB to use for synchronizing.
Will update in the next version.

For the rule of celllist:

   - > Not the same problem. Think about this, where does the list of free
   cells come from? How does the parent decided let me propose cells 5, 6, 7
   and 10?

Any cells that not being used by the node or marked as "locked" are a
candidate cell in the celllist. The parent just randomly select several
cells from them.

   - > One possibility is that the controller has given them away as a
   chunk of cells that the parent manages, we have text in Archie for that.
   - > The other is that the parent picks them pseudo randomly. Which means
   that another parent next to him might pick the same. If that is the case
   they will collide

Actually I didn't get what you say here about the parent and another parent
, you mean a node has two parents?

The 6P packets are negotiated only with one hop neighbor node, I agree the
same cells could be scheduled  by other links in the same propagation
range, which is the "hidden terminal" issue.  MSF won't trying to resolve
it when choosing cell. It could  later on use the reallocation process to
move the colliding cell to another place as mentioned in
https://tools.ietf.org/html/draft-ietf-6tisch-msf-05#section-5.3

For each node, as long as those cells are free to allocate according to its
own schedule, that's fine.  If there are two on going 6P transactions for
one node with different neighbors, the "locked" feature can resolve it.

   - > This is an impolite behavior, the sort why we do CCA / LBT. In TSCH
   CCA and LBT are useless between synchronized nodes within a cell, but they
   can be useful before pseudo randomly grabbing a cell to add to the
   schedule. That cell should be observed using CCA for a while before it is
   proposed to the child in 6P. IOW there should be a pool of cells that are
   not used (yet) but observed (CCA) so you know you can allocate them safely
   later.

Tengfei

On Wed, Jul 10, 2019 at 11:54 AM Pascal Thubert (pthubert) <
[email-masked]> wrote:

> Ø    I meant if you are configured to get 10 beacons but after an hour
> you get only one, will you wait for 1000 years?
>
>    - Not the same problem. Think about this, where does the list of free
>    cells come from? How does the parent decided let me propose cells 5, 6, 7
>    and 10?
>    - One possibility is that the controller has given them away as a
>    chunk of cells that the parent manages, we have text in Archie for that.
>    - The other is that the parent picks them pseudo randomly. Which means
>    that another parent next to him might pick the same. If that is the case
>    they will collide
>    - This is an impolite behavior, the sort why we do CCA / LBT. In TSCH
>    CCA and LBT are useless between synchronized nodes within a cell, but they
>    can be useful before pseudo randomly grabbing a cell to add to the
>    schedule. That cell should be observed using CCA for a while before it is
>    proposed to the child in 6P. IOW there should be a pool of cells that are
>    not used (yet) but observed (CCA) so you know you can allocate them safely
>    later.
>
>
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 17 Jul 2019 14:02:03 +0000

Hello Tengfei:

You start from a cell list from which a parent can select cells to talk with its children. But where do those cells come from?
Is that all the CDU matrix? Or a chunk off it (see discussion in Archie)? Or just a pseudo-random selection, possibly dependent on that parent’s MAC?

Bottom line is that unless there is a central entity that allocates a non -overlapping chunk for each parent there might be a cell CellA that parent P1 wants to use with child C1 and parent P2 wants to use with child C2. If P1 allocates CellA first, then P2 should discover that and refrain from using it. For that, P2 needs to monitor (CCA) CellA before it allocates it. This is the same idea as listen-before-talk but applied to cell allocation. Ideally, once a parent proposes a cell to a child for parent-> child communication, the child should also listen to the cell before accepting in order to avoid the hidden terminal collision.

The process of discovering later that the cell collisions is long and inefficient. If the cells are not used a lot it will take time. I disagree that it can be the sole procedure to avoid collisions.

All the best,

Pascal

From: Tengfei Chang <[email-masked]>
Sent: mercredi 17 juillet 2019 06:12
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: [email-masked]
Subject: Re: [6tisch] call for review: draft-ietf-6tisch-msf-04

Hi Pascal,

For the synchronization, I agree. It should be listening for a certain period of time and then choose which EB to use for synchronizing. Will update in the next version.

  *   > Not the same problem. Think about this, where does the list of free cells come from? How does the parent decided let me propose cells 5, 6, 7 and 10?

Any cells that not being used by the node or marked as "locked" are a candidate cell in the celllist. The parent just randomly select several cells from them.

  *   > One possibility is that the controller has given them away as a chunk of cells that the parent manages, we have text in Archie for that.
  *   > The other is that the parent picks them pseudo randomly. Which means that another parent next to him might pick the same. If that is the case they will collide

Actually I didn't get what you say here about the parent and another parent , you mean a node has two parents?

The 6P packets are negotiated only with one hop neighbor node, I agree the same cells could be scheduled  by other links in the same propagation range, which is the "hidden terminal" issue.  MSF won't trying to resolve it when choosing cell. It could  later on use the reallocation process to move the colliding cell to another place as mentioned in https://tools.ietf.org/html/draft-ietf-6tisch-msf-05#section-5.3

For each node, as long as those cells are free to allocate according to its own schedule, that's fine.  If there are two on going 6P transactions for one node with different neighbors, the "locked" feature can resolve it.

  *   > This is an impolite behavior, the sort why we do CCA / LBT. In TSCH CCA and LBT are useless between synchronized nodes within a cell, but they can be useful before pseudo randomly grabbing a cell to add to the schedule. That cell should be observed using CCA for a while before it is proposed to the child in 6P. IOW there should be a pool of cells that are not used (yet) but observed (CCA) so you know you can allocate them safely later.

Tengfei

On Wed, Jul 10, 2019 at 11:54 AM Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
Hello Tengfei

>    I meant if you are configured to get 10 beacons but after an hour you get only one, will you wait for 1000 years?

>     enough EB from the network it wishes to join or times out trying

 “

“

That’s a great spec  : )

Pascal

---

From: Tengfei Chang <[email-masked]>
Date: Wed, 17 Jul 2019 16:10:43 +0200

Hi Esteban,

Thanks for the comments, I will answer inline:

> ...". I guess it may be interesting to clarify when the actual parent

TC: The 3-step procedures list in the draft is happened after the parent is
switching.
parent switching is a behavior from routing layer, which MSF won't know in
advance.

> ratio TX/RX with the new parent.

TC: Yes, will add this information in next version.

> for cells that can't be removed with a 6P transaction (e.g. nodes are

TC: The issue need to be resolved in some way. There are several questions
here actually:

TC: 1. neighbor reachablility
TC: We could have a timeout if a cell in schedule doesn't being used for a
while, it expired and send some packet to the neighbor to check whether the
neighbor is there.
TC: We could use keep-alive packet for this purpose what defined in
IEEE802.15.4 is that the keep-alive packet is sent to its time source only.
TC: So, we could send another frame such as sixtop request with COUNT/LIST
packet.
TC: If the neighbor is able to receive ACK from the neighbor, then it's
reachable.
TC: otherwise, it's unreachable.

TC: 2. schedule decision
if it's unreachable, then the node can remove all the cells in its schedule
and reset the SeqNum as said by Yatch.
If it's reachable, then we will need make a decision what to do for that
neighbor.
I don't think the decision should be made by the node as those cells are
not originally managed by itself (The neighbor request those cells.).

TC: This is still an open questions though, I didn't have a good solution
for this issue right now.
TC: It's good that you propose it! Thanks!

> introduces higher latency." Maybe "a larger value"?

TC: Thanks for pointing them out, will be fixed in the next version!

---

From: Tengfei Chang <[email-masked]>
Date: Wed, 17 Jul 2019 17:31:30 +0200

Hi Pascal,

It is good for me to confirm it is about the hidden terminal collision
issue. Great!

For your first question that where those cells come from, it is not
mentioned in the MSF draft, but what I assumed is using the CDU matrix.

I understand what you are saying and agree the collision could happen
without performing CCA.
But with 101 slotframe length and 16 channels,  the chance to choose the
same cell (slot,channel) for two nodes in the same propagation range is
around 1/1616.
Though, along more cells are scheduled, the probability goes higher,  it's
fine with the fact most of the application doesn't have much traffic load
(less than packet / second).

The complexity to introduce CCA to have a collision-free schedule looks for
me not worthy, comparing to use simple, but maybe long discovering process
strategy, according to my opinion.

Tengfei

On Wed, Jul 17, 2019 at 4:02 PM Pascal Thubert (pthubert) <
[email-masked]> wrote:

> Hello Tengfei:
>
>
>
> You start from a cell list from which a parent can select cells to talk
> with its children. But where do those cells come from?
>
> Is that all the CDU matrix? Or a chunk off it (see discussion in Archie)?
> Or just a pseudo-random selection, possibly dependent on that parent’s MAC?
>
>
>
> Bottom line is that unless there is a central entity that allocates a non
> -overlapping chunk for each parent there might be a cell CellA that parent
> P1 wants to use with child C1 and parent P2 wants to use with child C2. If
> P1 allocates CellA first, then P2 should discover that and refrain from
> using it. For that, P2 needs to monitor (CCA) CellA before it allocates it.
> This is the same idea as listen-before-talk but applied to cell allocation.
> Ideally, once a parent proposes a cell to a child for parent-> child
> communication, the child should also listen to the cell before accepting in
> order to avoid the hidden terminal collision.
>
>
>
> The process of discovering later that the cell collisions is long and
> inefficient. If the cells are not used a lot it will take time. I disagree
> that it can be the sole procedure to avoid collisions.
>
>
>
> All the best,
>
>
>
> Pascal
>
>
>
> *From:* Tengfei Chang <[email-masked]>
> *Sent:* mercredi 17 juillet 2019 06:12
> *To:* Pascal Thubert (pthubert) <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [6tisch] call for review: draft-ietf-6tisch-msf-04
>
>
>
> Hi Pascal,
>
>
>
>    - > Not the same problem. Think about this, where does the list of
>    free cells come from? How does the parent decided let me propose cells 5,
>    6, 7 and 10?
>
>
>
>    - > The other is that the parent picks them pseudo randomly. Which
>    means that another parent next to him might pick the same. If that is the
>    case they will collide
>
>
>
> Actually I didn't get what you say here about the parent and another
> parent , you mean a node has two parents?
>
>
>
> For each node, as long as those cells are free to allocate according to
> its own schedule, that's fine.  If there are two on going 6P transactions
> for one node with different neighbors, the "locked" feature can resolve it.
>
>
>
>    - > This is an impolite behavior, the sort why we do CCA / LBT. In
>    TSCH CCA and LBT are useless between synchronized nodes within a cell, but
>    they can be useful before pseudo randomly grabbing a cell to add to the

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 17 Jul 2019 16:51:17 +0000

Hello Tengfei:

When the schedule gets more loaded the chances will become bad. Xavi demonstrated that a half loaded CDU matrix causes the allocation to pretty much never converge.

I do not agree that the schedule will necessarily be lightly used. Note that LBT is a mandatory practice in the ISM bands in Europe - unless you have a very, very low duty cycle. There’s a reason for that. Politeness is important in the ISM band. I do not agree that all nodes will have a very low duty cycle either (think, the root).

In a 6TiSCH network, CCA is useless between synchronized devices because they’ll talk at the same time. So LBT must be done some other way.

The bright side is that the future collision can be detected before it even happens. Doing CCA on cells before allocating them, etc… I think you must provide a method for that. A trade off would be to provide that method in the draft and make it optional.

All the best,

Pascal

From: Tengfei Chang <[email-masked]>
Sent: mercredi 17 juillet 2019 08:32
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: [email-masked]
Subject: Re: [6tisch] call for review: draft-ietf-6tisch-msf-04

Hi Pascal,

It is good for me to confirm it is about the hidden terminal collision issue. Great!

For your first question that where those cells come from, it is not mentioned in the MSF draft, but what I assumed is using the CDU matrix.

I understand what you are saying and agree the collision could happen without performing CCA.
But with 101 slotframe length and 16 channels,  the chance to choose the same cell (slot,channel) for two nodes in the same propagation range is around 1/1616.
Though, along more cells are scheduled, the probability goes higher,  it's fine with the fact most of the application doesn't have much traffic load (less than packet / second).

The complexity to introduce CCA to have a collision-free schedule looks for me not worthy, comparing to use simple, but maybe long discovering process strategy, according to my opinion.

Tengfei

On Wed, Jul 17, 2019 at 4:02 PM Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
Hello Tengfei:

All the best,

Pascal

From: Tengfei Chang <[email-masked]<mailto:[email-masked]>>
Sent: mercredi 17 juillet 2019 06:12
To: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [6tisch] call for review: draft-ietf-6tisch-msf-04

Hi Pascal,

Tengfei

 “

“

That’s a great spec  : )

Pascal

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 22 Jul 2019 18:35:23 +0300

Pascal Thubert (pthubert) writes:
> In a 6TiSCH network, CCA is useless between synchronized devices because
> they’ll talk at the same time. So LBT must be done some other way.

Note, that 802.15.4 do allow doing CCA if TschCca was set on when
MLME-TSCHE-MODE.request primitive is called to turn TSCH mode on. In
that case the node will do CCA at macTsCcaOffset time for macTsCca,
and all this is done before the actual macTsTxOffset happens, i.e.,
before the node is supposed to send its frame. This CCA does not
protect against other nodes in the TSCH, but it will protect against
other users on the same band, thus it should be enough for the legal
LBT requirements.

See figure 6-30 of 802.15.4-2015 in Section 6.5.4.1 and Section
6.2.5.2 covering TSCH CCA algorithm.

> The bright side is that the future collision can be detected before it even
> happens. Doing CCA on cells before allocating them, etc… I think you must
> provide a method for that. A trade off would be to provide that method in the
> draft and make it optional.

Note, that doing CCA on cells is bit pointless, as that will only
detect someone inside the same syncronized network using that slot, it
will not detect anybody else. I think it would be better to get
information of allocated slots from some kind of centralized node,
keeping track of nodes allocated and making sure there is no
collisions inside that one network.

Also, you cannot use the normal TSCH CCA for that, as it is done
BEFORE the actual time for TSCH frame to be sent on the channel. I do
not think there is a good way to do that specified in the 802.15.4. In
theory you could do it by configuring the specific slot for receiving
before starting to use it for transmission, and enabling promiscuous
mode, so you get all frames even when they are not addressed to you.

So requiring such feature to be provided for 6TiSCH to work, might
make it so that not all radios can do this, depending how much of TSCH
is actually implemented on MAC and how much is implemented in upper
layer.
-- 
[email-masked]