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

[Tengfei Chang <[e-mail]>]

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

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

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

 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.

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

Yes, Destinations 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.

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

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.

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

>
>
>
>
> “
>
>
>
>    | IANA_6TISCH_SFID_MSF | Minimal Scheduling Function | RFCXXXX     |
>
>    |                      | (MSF)                       | (NOTE:this) |
>
>
>
> “
>
>    - maybe
>
>
>
>    | IANA_6TISCH_SFID_MSF | Minimal Scheduling Function | RFC_THIS    |
>
>    |                      | (MSF)                       |             |
>

Will be applied in the next version!

>
>
>
>
> All the best,
>

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

>
>
> Pascal
>
>
>
> *From:* 6tisch <[e-mail]> *On Behalf Of *Tengfei Chang
> *Sent:* mardi 2 juillet 2019 12:57
> *To:* [e-mail]
> *Subject:* [6tisch] call for review: draft-ietf-6tisch-msf-04
>
>
>
> 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
>


-- 
Chang Tengfei,
Postdoctoral Research Engineer, Inria