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

Tengfei Chang <tengfei.chang@inria.fr> Mon, 11 May 2020 15:00 UTC

Return-Path: <tengfei.chang@inria.fr>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3E123A005F; Mon, 11 May 2020 08:00:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHHfMcEMnr3a; Mon, 11 May 2020 08:00:29 -0700 (PDT)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E91F3A005B; Mon, 11 May 2020 08:00:26 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.73,380,1583190000"; d="jpg'145?scan'145,208,145,217";a="449154298"
X-MGA-submission: =?us-ascii?q?MDFvezVaKEtZrpzqU+nZYsZjn5Ibt5tTqaWqw/?= =?us-ascii?q?DkId0VqwGqWaOh5RoqY5TIb4C6p0d6lCk61r1KoDmuqvxJ3ZXL338hof?= =?us-ascii?q?1ztNYfR6AaqZLdWtqIkYzIrB4e1p5o1Uf6fXpq7Q55276SDlB1IBTZcq?= =?us-ascii?q?IlEwhuEWQ5v6rtv1OmLG/K5A=3D=3D?=
Received: from zcs-store3.inria.fr ([128.93.142.30]) by mail2-relais-roc.national.inria.fr with ESMTP; 11 May 2020 17:00:24 +0200
Date: Mon, 11 May 2020 17:00:23 +0200 (CEST)
From: Tengfei Chang <tengfei.chang@inria.fr>
To: "Pascal Thubert, pthubert" <pthubert@cisco.com>
Cc: tengfei chang <tengfei.chang@gmail.com>, Benjamin Kaduk <kaduk@mit.edu>, iesg <iesg@ietf.org>, draft-ietf-6tisch-msf <draft-ietf-6tisch-msf@ietf.org>, 6tisch <6tisch@ietf.org>, 6tisch-chairs <6tisch-chairs@ietf.org>
Message-ID: <350915165.1841546.1589209223906.JavaMail.zimbra@inria.fr>
In-Reply-To: <MN2PR11MB35651B029F7998BC4EE7CDBBD8A10@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <158588511619.26351.4149213511250395502@ietfa.amsl.com> <CAAdgstQ8QfXg5TtL30vqL38C=Ey8Qaa0RT2Gzd_at1pBhQOaeA@mail.gmail.com> <MN2PR11MB35651B029F7998BC4EE7CDBBD8A10@MN2PR11MB3565.namprd11.prod.outlook.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_2ca7a1cd-fa86-493c-b1a9-4b8826c5f438"
X-Originating-IP: [77.57.206.159]
X-Mailer: Zimbra 8.7.11_GA_3800 (ZimbraWebClient - GC81 (Win)/8.7.11_GA_3800)
Thread-Topic: Benjamin Kaduk's No Objection on draft-ietf-6tisch-msf-16: (with COMMENT)
Thread-Index: AQHWJ4ybnh6Qi3kpc0am7qSSZwMhPqii39AQ8SgemAk=
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/MmZoo6m0W1ThMp9Iorfgvsr9Sr4>
Subject: Re: [6tisch] Benjamin Kaduk's No Objection on draft-ietf-6tisch-msf-16: (with COMMENT)
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 May 2020 15:00:37 -0000

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 ) 
(+33)1 80 49 41 43 
tengfei.chang@inria.fr 
www.tchang.org 
____________________ 

> From: "Pascal Thubert, pthubert" <pthubert@cisco.com>
> To: "tengfei chang" <tengfei.chang@gmail.com>om>, "Benjamin Kaduk" <kaduk@mit.edu>
> Cc: "iesg" <iesg@ietf.org>rg>, "draft-ietf-6tisch-msf"
> <draft-ietf-6tisch-msf@ietf.org>rg>, "6tisch" <6tisch@ietf.org>rg>, "6tisch-chairs"
> <6tisch-chairs@ietf.org>
> 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 <tengfei.chang@gmail.com>
> Sent: lundi 11 mai 2020 14:06
> To: Benjamin Kaduk <kaduk@mit.edu>
> Cc: The IESG <iesg@ietf.org>rg>; draft-ietf-6tisch-msf@ietf.org; 6tisch
> <6tisch@ietf.org>rg>; 6tisch-chairs@ietf.org; Pascal Thubert (pthubert)
> <pthubert@cisco.com>
> 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:noreply@ietf.org | noreply@ietf.org ] > 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:6tisch@ietf.org | 6tisch@ietf.org ]
>> [ 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/ ]

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