Re: [6tisch] Benjamin Kaduk's No Objection on draft-ietf-6tisch-msf-16: (with COMMENT)

[Tengfei Chang <[e-mail]>]

Hi Pascal, 

It turns out I missed read Benjamin's suggestion: 

Benjiamin suggested: 

I suggest '''one routing parent; this parent is referred to as the 
"selected parent"'''. 

I miss read it as the suggestion is to replace "one routing parent" by "the selected parent", which I changed it to the "selected routing parent". 
Will correct it and publish a new version. 

Thanks for the catching! 
Tengfei 

Stay Healthy! Stay Optimistic! 

Dr. Tengfei Chang 
Post-doctoral Researcher 
Wireless Networking for Evolving & Adaptive Applications (EVA) 
National Inst. for Research in Comp. Sci. and Automation ( Inria ) 
([phone] 
[e-mail] 
www.tchang.org 
____________________ 

> From: "Pascal Thubert, pthubert" <[e-mail]>
> To: "Tengfei Chang" <[e-mail]>fr>, "Benjamin Kaduk" <[e-mail]>
> Cc: "tengfei chang" <[e-mail]>om>, "iesg" <[e-mail]>rg>,
> "draft-ietf-6tisch-msf" <[e-mail]>rg>, "6tisch"
> <[e-mail]>rg>, "6tisch-chairs" <[e-mail]>
> Sent: Monday, May 11, 2020 6:08:50 PM
> Subject: RE: [6tisch] Benjamin Kaduk's No Objection on draft-ietf-6tisch-msf-16:
> (with COMMENT)

> Hello Benjamin and Tengfei;

> What I did is pick one randomly, and picked this;

> “

> MSF works closely with RPL, specifically the routing parent defined
> in [RFC6550]. This specification only describes how MSF works with
> one routing parent, which is phrased as "selected parent". The

> nit: I suggest '''one routing parent; this parent is referred to as the
> "selected parent"'''.

> “

> Then I looked at 16 and the text is still

> MSF works closely with the IPv6 Routing Protocol for Low-Power and

> Lossy Networks (RPL), specifically the routing parent defined in

> [ [ https://tools.ietf.org/html/rfc6550 | RFC6550 ] ]. This specification only
> describes how MSF works with the

> selected routing parent, which is phrased as "selected parent". The

> activity of MSF towards the single routing parent is called a "MSF

> session". Though the performance of MSF is evaluated only when the

> "selected parent" represents the node's preferred parent, there

> This tells me that the handling of Benjamin’s review is not complete, so I asked
> Tengfei to double check.

> Take care;

> Pascal

> From: Tengfei Chang <[e-mail]>
> Sent: lundi 11 mai 2020 17:00
> To: Pascal Thubert (pthubert) <[e-mail]>
> Cc: tengfei chang <[e-mail]>om>; Benjamin Kaduk <[e-mail]>du>;
> iesg <[e-mail]>rg>; draft-ietf-6tisch-msf <[e-mail]>rg>;
> 6tisch <[e-mail]>rg>; 6tisch-chairs <[e-mail]>
> Subject: Re: [6tisch] Benjamin Kaduk's No Objection on draft-ietf-6tisch-msf-16:
> (with COMMENT)

> Hi Pascal,

> If comparing the comments to draft-ietf-6tisch-msf-12 from another thread
> previously, you will find out they are actually the same.

> Those comments are indeed fixed with the MSF versions after 12, including
> draft-ietf-6tisch-msf-16 .

> Regards,

> Tengfei

> Stay Healthy! Stay Optimistic!

> Dr. Tengfei Chang

> Post-doctoral Researcher

> Wireless Networking for Evolving & Adaptive Applications (EVA)

> National Inst. for Research in Comp. Sci. and Automation ( Inria )

> ([phone]

> [ mailto:[e-mail] | [e-mail] ]

> [ http://www.tchang.org/ | www.tchang.org ]

> ____________________

>> From: "Pascal Thubert, pthubert" < [ mailto:[e-mail] |
>> [e-mail] ] >
>> To: "tengfei chang" < [ mailto:[e-mail] | [e-mail]
>> ] >, "Benjamin Kaduk" < [ mailto:[e-mail] | [e-mail] ] >
>> Cc: "iesg" < [ mailto:[e-mail] | [e-mail] ] >, "draft-ietf-6tisch-msf"
>> < [ mailto:[e-mail] | [e-mail] ] >,
>> "6tisch" < [ mailto:[e-mail] | [e-mail] ] >, "6tisch-chairs" < [
>> mailto:[e-mail] | [e-mail] ] >
>> Sent: Monday, May 11, 2020 4:23:12 PM
>> Subject: RE: [6tisch] Benjamin Kaduk's No Objection on draft-ietf-6tisch-msf-16:
>> (with COMMENT)
>> Hello Tengfei

>> My reading is that the comments below apply to version 16 as the title
>> indicates.

>> I randomly checked the proposed nit fixes and the issues are effectively still
>> left to be fixed.

>> Can you please have a look?

>> Take care,

>> Pascal

>> From: Tengfei Chang < [ mailto:[e-mail] | [e-mail]
>> ] >
>> Sent: lundi 11 mai 2020 14:06
>> To: Benjamin Kaduk < [ mailto:[e-mail] | [e-mail] ] >
>> Cc: The IESG < [ mailto:[e-mail] | [e-mail] ] >; [
>> mailto:[e-mail] | [e-mail] ] ;
>> 6tisch < [ mailto:[e-mail] | [e-mail] ] >; [
>> mailto:[e-mail] | [e-mail] ] ; Pascal Thubert
>> (pthubert) < [ mailto:[e-mail] | [e-mail] ] >
>> Subject: Re: [6tisch] Benjamin Kaduk's No Objection on draft-ietf-6tisch-msf-16:
>> (with COMMENT)

>> Hi Benjamin,

>> Thanks for updating the comments!

>> I believe the change from the current email comparing to previous one is that
>> the DISCUSSION part is removed as we fixed it in another previous thread.

>> The other comments from the current email are actually for old version of MSF,
>> which are all resolved in the latest version MSF-16.

>> For the administration,

>> I want to clarify that the draft-ietf-6tisch-msf-16 has resolved all comments
>> which were discussed.

>> Please advise me if there is any further action required. Thanks a lot!

>> Regards,

>> Tengfei

>> On Fri, Apr 3, 2020 at 5:38 AM Benjamin Kaduk via Datatracker < [
>> mailto:[e-mail] | [e-mail] ] > wrote:

>>> Benjamin Kaduk has entered the following ballot position for
>>> draft-ietf-6tisch-msf-16: No Objection

>>> When responding, please keep the subject line intact and reply to all
>>> email addresses included in the To and CC lines. (Feel free to cut this
>>> introductory paragraph, however.)

>>> Please refer to [ https://www.ietf.org/iesg/statement/discuss-criteria.html |
>>> https://www.ietf.org/iesg/statement/discuss-criteria.html ]
>>> for more information about IESG DISCUSS and COMMENT positions.

>>> The document, along with other ballot positions, can be found here:
>>> [ https://datatracker.ietf.org/doc/draft-ietf-6tisch-msf/ |
>>> https://datatracker.ietf.org/doc/draft-ietf-6tisch-msf/ ]

>>> ----------------------------------------------------------------------
>>> COMMENT:
>>> ----------------------------------------------------------------------

>>> Thanks for clarifying the non-issue nature of my original Discuss points!

>>> Original COMMENT section preserved below (possibly stale).

>>> I support Roman's Discuss -- we need more information for this to be a
>>> useful reference; even what seem to be the official DASFAA 1997
>>> proceedings ( [ https://dblp.org/db/conf/dasfaa/dasfaa97 |
>>> https://dblp.org/db/conf/dasfaa/dasfaa97 ] ) do not have an
>>> associated document).

>>> Basing various scheduling aspects on (a hash of) the EUI64 ties
>>> functionality to a persistent identifier for a device. How significant
>>> a disruption would be incurred if a device periodically changes its
>>> presented EUI64 for anonymization purposes?

>>> There seems to be a general pattern of "if you don't have a
>>> 6P-negotiated Tx cell, install and AutoTxCell to send your one message
>>> and then remove it after sending"; I wonder if it would be easier on the
>>> reader to consolidate this as a general principle and not repeat the
>>> details every time it occurs.

>>> Requirements Language

>>> "NOT RECOMMENDED" is not in the RFC2119 boilerplate (but is a BCP 14 keyword).

>>> Section 1

>>> the 6 steps described in Section 4. The end state of the join
>>> process is that the node is synchronized to the network, has mutually
>>> authenticated to the network, has identified a routing parent, and

>>> nit(?): I guess maybe "mutually authenticated with" is more correct for
>>> the bidirectional operation.

>>> It does so for 3 reasons: to match the link-layer resources to the
>>> traffic, to handle changing parent, to handle a schedule collision.

>>> nit: end the list with "or" (or "and"?).

>>> MSF works closely with RPL, specifically the routing parent defined
>>> in [RFC6550]. This specification only describes how MSF works with
>>> one routing parent, which is phrased as "selected parent". The

>>> nit: I suggest '''one routing parent; this parent is referred to as the
>>> "selected parent"'''.

>>> activity of MSF towards to single routing parent is called as a "MSF

>>> nit: "towards the"

>>> * We added sections on the interface to the minimal 6TiSCH
>>> configuration (Section 2), the use of the SIGNAL command
>>> (Section 6), the MSF constants (Section 14), the MSF statistics
>>> (Section 15).

>>> nit: end the list with "and".

>>> Section 2

>>> In a TSCH network, time is sliced up into time slots. The time slots
>>> are grouped as one of more slotframes which repeat over time. The

>>> nit(?): should this be "one or more"?

>>> channel) is indicated as a cell of TSCH schedule. MSF is one of the
>>> policies defining how to manage the TSCH schedule.

>>> nit: if there is only one such policy active at a given time for a given
>>> network, I suggest "MSF is a policy for managing the TCSH schedule".
>>> (If multiple policies are active simultaneously, no change is needed.)

>>> MSF uses the minimal cell for broadcast frames such as Enhanced
>>> Beacons (EBs) [IEEE802154] and broadcast DODAG Information Objects
>>> (DIOs) [RFC6550]. Cells scheduled by MSF are meant to be used only
>>> for unicast frames.

>>> If this paragraph was moved before the previous paragraph, then EB and
>>> DIO would be defined before their first usage.

>>> bandwidth of minimal cell. One of the algorithm met the rule is the
>>> Trickle timer defined in [RFC6206] which is applied on DIO messages
>>> [RFC6550]. However, any such algorithm of limiting the broadcast

>>> nit(?): "One of the algorithms that fulfills this requirement"?

>>> MSF RECOMMENDS the use of 3 slotframes. MSF schedules autonomous
>>> cells at Slotframe 1 (Section 3) and 6P negotiated cells at Slotframe
>>> 2 (Section 5) , while Slotframe 0 is used for the bootstrap traffic
>>> as defined in the Minimal 6TiSCH Configuration. It is RECOMMENDED to
>>> use the same slotframe length for Slotframe 0, 1 and 2. Thus it is

>>> Perhaps this is just a question of writing style, but if an
>>> implementation is free to use an alternative SF or a variant of MSF,
>>> could we not say that "MSF uses 3 slotframts", "MSF uses the same
>>> slotframe length for", etc.?

>>> Section 3

>>> Is there any risk of unwanted correlation between slot and channel
>>> offsets when using the same hash function and input for both
>>> calculations?

>>> hash function. Other optional parameters defined in SAX determine
>>> the performance of SAX hash function. Those parameters could be
>>> broadcasted in EB frame or pre-configured. For interoperability
>>> purposes, an example how the hash function is implemented is detailed
>>> in Appendix B.

>>> Given the lack of usable reference for [SAX-DASFAA], I assume that the
>>> content in Appendix B is going to be used as a specification, not just
>>> an example.

>>> * The AutoRxCell MUST always remain scheduled after synchronized.

>>> nit: s/synchronized/synchronization/

>>> AutoRxCell. In case of conflicting with a negotiated cell,
>>> autonomous cells take precedence over negotiated cell, which is
>>> stated in [IEEE802154]. However, when the Slotframe 0, 1 and 2 use
>>> the same length value, it is possible for negotiated cell to avoid
>>> the collision with AutoRxCell.

>>> Presumably this factors in to the recommendation to have the three
>>> listed slotframes use the same length, but mentioning it explicitly
>>> (whether here or where the recommendation is made) might be nice.

>>> Section 4

>>> network. Alternative behaviors may involved, for example, when
>>> alternative security solution is used for the network. Section 4.1

>>> nit: singular/plural mismatch "behaviors"/"solution is used"

>>> Section 4.1

>>> A node implementing MSF SHOULD implement the Minimal Security
>>> Framework for 6TiSCH [I-D.ietf-6tisch-minimal-security]. As a

>>> Didn't this get renamed to CoJP?

>>> Section 4.2

>>> I a little bit wonder if there is a better description than "available
>>> frequencies" but don't have one to offer.

>>> Section 4.3

>>> While the exact behavior is implementation-specific, it is
>>> RECOMMENDED that after having received the first EB, a node keeps
>>> listen for at most MAX_EB_DELAY seconds until it has received EBs
>>> from NUM_NEIGHBOURS_TO_WAIT distinct neighbors, which is defined in
>>> [RFC8180].

>>> nit(?): this phrasing implies that only NUM_NEIGHBOURS_TO_WAIT is
>>> defined in RFC 8180, but MAX_EB_DELAY is also defined there.

>>> not-nit: this phrasing is ambiguous as to whether one of MAX_EB_DELAY
>>> and NUM_NEIGHBOURS_TO_WAIT is sufficient to move to the next step or
>>> whether both are required.

>>> Section 4.4

>>> After selected a JP, a node generates a Join Request and installs an
>>> AutoTxCell to the JP. The Join Request is then sent by the pledge to
>>> its JP over the AutoTxCell. The AutoTxCell is removed by the pledge

>>> editorial: I'd suggest s/its JP/its selected JP/

>>> Response is sent out. The pledge receives the Join Response from its
>>> AutoRxCell, thereby learns the keying material used in the network,
>>> as well as other configurations, and becomes a "joined node".

>>> nit: maybe "other configuration values" or "other configuration
>>> settings"?

>>> Section 4.6

>>> Once it has selected a routing parent, the joined node MUST generate
>>> a 6P ADD Request and install an AutoTxCell to that parent. The 6P
>>> ADD Request is sent out through the AutoTxCell with the following
>>> fields:

>>> * CellOptions: set to TX=1,RX=0,SHARED=0
>>> * NumCells: set to 1
>>> * CellList: at least 5 cells, chosen according to Section 8

>>> Is this listing describing the contents of the ADD request or the
>>> AuthTxCell used to send it? (I presume the former, in which case I
>>> suggest to use "containing" or similar in preference to "with".)

>>> Section 5.1

>>> The goal of MSF is to manage the communication schedule in the 6TiSCH
>>> schedule in a distributed manner. For a node, this translates into
>>> monitoring the current usage of the cells it has to the selected
>>> parent:

>>> Is this goal strictly limited to traffic "to the selected parent" vs.
>>> all traffic?

>>> * If the node determines that the number of link-layer frames it is
>>> attempting to exchange with the selected parent per unit of time
>>> is larger than the capacity offered by the TSCH negotiated cells
>>> it has scheduled with it, the node issues a 6P ADD command to that
>>> parent to add cells to the TSCH schedule.
>>> * If the traffic is lower than the capacity, the node issues a 6P
>>> DELETE command to that parent to delete cells from the TSCH
>>> schedule.

>>> As written, this would potentially lead to oscillation when demand is
>>> basically at capacity, due to the quantization of capacity. Perhaps
>>> some provisioning for hysteresis is appropriate?

>>> The cell option of cells listed in CellList in 6P Request frame
>>> SHOULD be either Tx=1 only or Rx=1 only. Both NumCellsElapsed and
>>> NumCellsUsed counters can be used to both type of negotiated cells.

>>> Would this be more clear as "(Tx=1,Rx=0) or (Tx=0,Rx=1)"?

>>> * NumCellsElapsed is incremented by exactly 1 when the current cell
>>> is AutoRxCell.

>>> This holds for all peers/parents we're keeping counters for, so the
>>> AutoRxCell can get "double counted"?

>>> In case that a node booted or disappeared from the network, the cell
>>> reserved at the selected parent may be kept in the schedule forever.
>>> A clean-up mechanism MUST be provided to resolve this issue. The
>>> clean-up mechanism is implementation-specific. It could either be a
>>> periodic polling to the neighbors the nodes have negotiated cells
>>> with, or monitoring the activities on those cells. The goal is to
>>> confirm those negotiated cells are not used anymore by the associated
>>> neighbors and remove them from the schedule.

>>> I'm not sure that "monitoring the activities on those cells" is safe
>>> with the current level of specification; if a node negotiates a 6P
>>> transmit cell to a parent and uses it only sparingly, with the parent
>>> eventually reclaiming it due to inactivity, I don't see a mechanism by
>>> which the node will reliably discover the negotiated cell to be
>>> nonfunctional and fall back to (e.g.) the corresponding AutoTxCell. It
>>> may be most prudent to just not mention that as an example (a "periodic
>>> polling" procedure does not seem to have the same potential for
>>> information skew)

>>> Section 5.3

>>> schedule is executed and the node sends frames to that parent. When
>>> NumTx reaches MAX_NUMTX, both NumTx and NumTxAck MUST be divided by
>>> 2. For example, when MAX_NUMTX is set to 256, from NumTx=255 and
>>> NumTxAck=127, the counters become NumTx=128 and NumTxAck=64 if one
>>> frame is sent to the parent with an Acknowledgment received. This
>>> operation does not change the value of the PDR, but allows the
>>> counters to keep incrementing. The value of MAX_NUMTX is
>>> implementation-specific.

>>> Does MAX_NUMTX need to be a power of two (to avoid errors when the
>>> division occurs)?

>>> 4. For any other cell, it compares its PDR against that of the cell
>>> with the highest PDR. If the difference is larger than
>>> RELOCATE_PDRTHRES, it triggers the relocation of that cell using
>>> a 6P RELOCATE command.

>>> The recommended RELOCATE_PDRTHRES is given as "50 %". Is this
>>> "difference" performed as a subtraction (so that if the highest PDR is
>>> less than 50%, no cells can ever be relocated) or a ratio (a PDR that's
>>> half than the maximum PDR or smaller will trigger relocation)?

>>> Section 7

>>> Maybe reference Section 17.1 where the allocation will occur?

>>> Section 8

>>> * The slotOffset of a cell in the CellList SHOULD be randomly and
>>> uniformly chosen among all the slotOffset values that satisfy the
>>> restrictions above.
>>> * The channelOffset of a cell in the CellList SHOULD be randomly and
>>> uniformly chosen in [0..numFrequencies], where numFrequencies
>>> represents the number of frequencies a node can communicate on.

>>> Do these random selections need to be independent from each other? (I
>>> note that the selection for the autonomous cells are not.)

>>> Section 9

>>> Is there a reference for these three parameters (MAXBE, MAXRETRIES,
>>> SLOTFRAME_LENGTH)? SLOTFRAME_LENGTH seems new in this document and is
>>> listed in the table in Section 14, but the other two are not listed
>>> there.

>>> Section 14

>>> Why is MAX_NUMTX not listed in the table?

>>> Can we really give a recommended NUM_CH_OFFSET value, since this is in
>>> effect dependent on the number of channels available?

>>> KA_PERIOD is defined but not used elsewhere in the document.

>>> What are the considerations in using a power of 10 vs. a power of 2 as
>>> MAX_NUM_CELLS?

>>> Section 16

>>> MSF defines a series of "rules" for the node to follow. It triggers
>>> several actions, that are carried out by the protocols defined in the
>>> following specifications: the Minimal IPv6 over the TSCH Mode of IEEE
>>> 802.15.4e (6TiSCH) Configuration [RFC8180], the 6TiSCH Operation

>>> I'd suggest a brief note that the security considerations of those
>>> protocols continue to apply (even though it ought to be obvious);
>>> reading them could help a reader understand the behavior of this
>>> document as well.

>>> Sublayer Protocol (6P) [RFC8480], and the Minimal Security Framework
>>> for 6TiSCH [I-D.ietf-6tisch-minimal-security]. In particular, MSF

>>> [CoJP again]

>>> prevent it from receiving the join response. This situation should
>>> be detected through the absence of a particular node from the network
>>> and handled by the network administrator through out-of-band means,
>>> e.g. by moving the node outside the radio range of the attacker.

>>> "the radio range of the attacker" is not exactly a fixed constant ...
>>> attackers are not in general bound by legal limits and can increase Tx
>>> power subject only to their equipment and budget.

>>> MSF adapts to traffics containing packets from IP layer. It is
>>> possible that the IP packet has a non-zero DSCP (Diffserv Code Point
>>> [RFC2597]) value in its IPv6 header. The decision whether to hand

>>> RFC 2597 is talking more about specifically assured forwarding PHB groups
>>> than "DSCP codepoint"s per se.

>>> Section 18.1

>>> RFC 6206 seems to only be used as an example (Trickle), and could
>>> probably be informative.

>>> RFC 8505 might also not need to be normative.

>>> Appendix B

>>> In MSF, the T is replaced by the length slotframe 1. String s is

>>> nit: "length of"

>>> 2. sum the value of L_shift(h,l_bit), R_shift(h,r_bit) and ci

>>> Is this addition performed in "infinite precision" integer arithmetic or
>>> limited to the output width of h, e.g., by modular division? (It's not
>>> clear to me whether this is the role T plays or not.)

>>> 8. assign the result of Step 5 to h

>>> The value from step 5 *is* h, so taken literally this says "assign h to
>>> h" and is not needed.

>>> _______________________________________________
>>> 6tisch mailing list
>>> [ mailto:[e-mail] | [e-mail] ]
>>> [ https://www.ietf.org/mailman/listinfo/6tisch |
>>> https://www.ietf.org/mailman/listinfo/6tisch ]
>> --

>> ——————————————————————————————————————

>> Stay healthy, stay optimistic!

>> Dr. Tengfei, Chang

>> Postdoctoral Research Engineer , Inria

>> [ http://www.tchang.org/ | www.tchang.org/ ]

>> ——————————————————————————————————————