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

[Tengfei Chang <[e-mail]>]

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