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

[Tengfei Chang <[e-mail]>]

Hi Pascal,

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

> Hello Tengfei
>
> tions address is correct. Thanks!
>
>
>
>
>
> “
>
>    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.
>
>
>
> 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.
>
> Ø
>
>
>
> 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.




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



> “
> 6P Timeout Value
>
>
>
> “
>
> 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.
>
>
>
> 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.



>
>
> Thanks a lot again for reviewing the draft and the comments!
>
>
>
> That’s a great spec  : )
>
>
>
>
>
> Pascal
>


-- 
Chang Tengfei,
Postdoctoral Research Engineer, Inria