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

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

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 <[e-mail]>
Sent: mercredi 17 juillet 2019 08:32
To: Pascal Thubert (pthubert) <[e-mail]>
Cc: [e-mail]
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) <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>>
Sent: mercredi 17 juillet 2019 06:12
To: Pascal Thubert (pthubert) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
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.

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


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

   enough EB from the network it wishes to join.


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


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



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



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

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

That’s a great spec  : )


Pascal



--
Chang Tengfei,
Postdoctoral Research Engineer, Inria


--
Chang Tengfei,
Postdoctoral Research Engineer, Inria