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

[Tengfei Chang <[e-mail]>]

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