Thanks a lot Pascal for reviewing the draft, my replies are inlines: On Thu, Jul 4, 2019 at 5:30 PM Pascal Thubert (pthubert) <[email protected]> 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 <[email protected]> *On Behalf Of *Tengfei Chang > *Sent:* mardi 2 juillet 2019 12:57 > *To:* [email protected] > *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
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
