[6tisch] Fwd: New Version Notification for draft-ietf-6tisch-msf-18.txt

[Tengfei Chang]

Dear all,

A new version of I-D, draft-ietf-6tisch-msf-18.txt is just posted.
It mainly resolved the comments from Eric.

I believe the current version resolved the all comments posted by the reviewers.
Very much looking forward to the next step action!

Taking care!
Tengfei

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.ch...@inria.fr 
www.tchang.org 


- Forwarded Message -
> From: internet-dra...@ietf.org
> To: "Mališa Vučinić" , "Xavi Vilajosana Guillen" 
> , "Tengfei Chang"
> , "Simon Duquennoy" , 
> "Prof. Diego Dujovne"
> 
> Sent: Saturday, September 12, 2020 9:22:52 PM
> Subject: New Version Notification for draft-ietf-6tisch-msf-18.txt

> A new version of I-D, draft-ietf-6tisch-msf-18.txt
> has been successfully submitted by Tengfei Chang and posted to the
> IETF repository.
> 
> Name: draft-ietf-6tisch-msf
> Revision: 18
> Title:6TiSCH Minimal Scheduling Function (MSF)
> Document date:2020-09-12
> Group:6tisch
> Pages:22
> URL:https://www.ietf.org/id/draft-ietf-6tisch-msf-18.txt
> Status: https://datatracker.ietf.org/doc/draft-ietf-6tisch-msf/
> Html:   https://www.ietf.org/id/draft-ietf-6tisch-msf-18.html
> Htmlized:   https://tools.ietf.org/html/draft-ietf-6tisch-msf-18
> Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-6tisch-msf-18
> 
> Abstract:
>   This specification defines the 6TiSCH Minimal Scheduling Function
>   (MSF).  This Scheduling Function describes both the behavior of a
>   node when joining the network, and how the communication schedule is
>   managed in a distributed fashion.  MSF is built upon the 6TiSCH
>   Operation Sublayer Protocol (6P) and the Minimal Security Framework
>   for 6TiSCH.
> 
> 
>   
>
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Erik Kline's Yes on draft-ietf-6tisch-msf-17: (with COMMENT)

[Tengfei Chang]

Thanks Erik for the review!

I will fix those comments and publish a new version soon.

Tengfei

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.ch...@inria.fr 
www.tchang.org 


- Original Message -
> From: "Erik Kline via Datatracker" 
> To: "iesg" 
> Cc: "draft-ietf-6tisch-msf" , "6tisch-chairs" 
> <6tisch-cha...@ietf.org>, "6tisch"
> <6tisch@ietf.org>, "Pascal Thubert, pthubert" , "Pascal 
> Thubert, pthubert" 
> Sent: Saturday, September 12, 2020 7:45:52 AM
> Subject: Erik Kline's Yes on draft-ietf-6tisch-msf-17: (with COMMENT)

> Erik Kline has entered the following ballot position for
> draft-ietf-6tisch-msf-17: Yes
> 
> 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
> 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/
> 
> 
> 
> --
> COMMENT:
> --
> 
> [[ nits ]]
> 
> [ section 2 ]
> 
> * "to do at each time slots" -> "to do at each time slot"
> 
> * "there is a frame to sent" -> "there is a frame to be sent"
> 
> [ section 4.3 ]
> 
> * "the pledge continue listening" -> "the pledge continues listening"
> 
> [ section 4.4 ]
> 
> * "After selected a JP" ->
>  "After selecting a JP" or "After having selected a JP"
> 
> [ section 4.8 ]
> 
> * "AutRxCell" -> "AutoRxCell"?
> 
> * "for new pledge" -> "for new pledges"?
> 
> [ section 5.1 ]
> 
> * "used to both type of" -> "used for both type of"?
> 
> [ section 8 ]
> 
> * "consequence of randomly cell selection" ->
>  "consequence of random cell selection"?
> 
> [ section 9 ]
> 
> * "define din" -> "defined in"
> 
> [ section 16 ]
> 
> * "considrations" -> "considerations"
> 
> * "to hand that packet" -> "to handle that packet", maybe

All accepted!

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] Fwd: New Version Notification for draft-ietf-6tisch-msf-17.txt

[Tengfei Chang]

Hello all,

A new version of 6TiSCH MSF draft is published. It mainly resolved the comments 
from Donald (cc'ed).
Thanks again for these comments!

Erik, Let me know if there is any further action required from my side to push 
it forward. 
Thanks!

Regards,
Tengfei




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.ch...@inria.fr 
www.tchang.org 


- Forwarded Message -
> From: internet-dra...@ietf.org
> To: "Xavi Vilajosana Guillen" , "Tengfei Chang" 
> , "Mališa Vučinić"
> , "Prof. Diego Dujovne" , 
> "Simon Duquennoy"
> 
> Sent: Monday, August 3, 2020 10:57:08 AM
> Subject: New Version Notification for draft-ietf-6tisch-msf-17.txt

> A new version of I-D, draft-ietf-6tisch-msf-17.txt
> has been successfully submitted by Tengfei Chang and posted to the
> IETF repository.
> 
> Name: draft-ietf-6tisch-msf
> Revision: 17
> Title:6TiSCH Minimal Scheduling Function (MSF)
> Document date:2020-08-03
> Group:6tisch
> Pages:22
> URL:
> https://www.ietf.org/internet-drafts/draft-ietf-6tisch-msf-17.txt
> Status: https://datatracker.ietf.org/doc/draft-ietf-6tisch-msf/
> Htmlized:   https://tools.ietf.org/html/draft-ietf-6tisch-msf-17
> Htmlized:   https://datatracker.ietf.org/doc/html/draft-ietf-6tisch-msf
> Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-6tisch-msf-17
> 
> Abstract:
>   This specification defines the 6TiSCH Minimal Scheduling Function
>   (MSF).  This Scheduling Function describes both the behavior of a
>   node when joining the network, and how the communication schedule is
>   managed in a distributed fashion.  MSF is built upon the 6TiSCH
>   Operation Sublayer Protocol (6P) and the Minimal Security Framework
>   for 6TiSCH.
> 
> 
>   
>
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

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

[Tengfei Chang]

Alright, then I will keep the version 17 unpublished, until it's needed. 

Thanks a lot Pascal! 

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.ch...@inria.fr 
www.tchang.org 
 

> From: "Pascal Thubert, pthubert" 
> To: "Tengfei Chang" 
> Cc: "Benjamin Kaduk" , "tengfei chang" 
> ,
> "iesg" , "draft-ietf-6tisch-msf"
> , "6tisch" <6tisch@ietf.org>, "6tisch-chairs"
> <6tisch-cha...@ietf.org>
> Sent: Wednesday, May 13, 2020 11:08:03 AM
> Subject: Re: [6tisch] Benjamin Kaduk's No Objection on 
> draft-ietf-6tisch-msf-16:
> (with COMMENT)

> Oh that’s cool then we can keep a note for the rfc editor no need for
> republishing

> I’ll ping Alvaro see if the doc can be queued now.

> Take care,

> Pascal

>> Le 13 mai 2020 à 11:03, Tengfei Chang  a écrit :

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

>>> From: "Pascal Thubert, pthubert" 
>>> To: "Tengfei Chang" , "Benjamin Kaduk" 
>>> 
>>> Cc: "tengfei chang" , "iesg" ,
>>> "draft-ietf-6tisch-msf" , "6tisch"
>>> <6tisch@ietf.org>, "6tisch-chairs" <6tisch-cha...@ietf.org>
>>> 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 
>>> Sent: lundi 11 mai 2020 17:00
>>> To: Pascal Thubert (pthubert) 
>>> Cc: tengfei chang ; Benjamin Kaduk ;
>>> iesg ; draft-ietf-6tisch-msf 
>>> ;
>>> 6tisch <6tisch@ietf.org>; 6tisch-chairs <6tisch-cha...@ietf.org>
>>> 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!

>>> D

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

[Tengfei Chang]

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

> From: "Pascal Thubert, pthubert" 
> To: "Tengfei Chang" , "Benjamin Kaduk" 
> 
> Cc: "tengfei chang" , "iesg" ,
> "draft-ietf-6tisch-msf" , "6tisch"
> <6tisch@ietf.org>, "6tisch-chairs" <6tisch-cha...@ietf.org>
> 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 
> Sent: lundi 11 mai 2020 17:00
> To: Pascal Thubert (pthubert) 
> Cc: tengfei chang ; Benjamin Kaduk ;
> iesg ; draft-ietf-6tisch-msf ;
> 6tisch <6tisch@ietf.org>; 6tisch-chairs <6tisch-cha...@ietf.org>
> 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 )

> (+33)1 80 49 41 43

> [ mailto:tengfei.ch...@inria.fr | tengfei.ch...@inria.fr ]

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

> 

>> From: "Pascal Thubert, pthubert" < [ mailto:pthub...@cisco.com |
>> pthub...@cisco.com ] >
>> To: "tengfei chang" < [ mailto:tengfei.ch...@gmail.com | 
>> tengfei.ch...@gmail.com
>> ] >, "Benjamin Kaduk" < [ mailto:ka...@mit.edu | ka...@mit.edu ] >
>> Cc: "iesg" < [ mailto:i...@ietf.org | i...@ietf.org ] >, 
>> "draft-ietf-6tisch-msf"
>> < [ mailto:draft-ietf-6tisch-...@ietf.org | draft-ietf-6tisch-...@ietf.org ] 
>> >,
>> "6tisch" < [ mailto:6tisch@ietf.org | 6tisch@ietf.org ] >, "6tisch-chairs" < 
>> [
>> mailto:6tisch-cha...@ietf.org | 6tisch-cha...@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 < [ mailto:tengfei.ch...@gmail.com | 
>> tengfei.ch...@gmail.com
>> ] &g

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

[Tengfei Chang]

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.ch...@inria.fr 
www.tchang.org 
 

> From: "Pascal Thubert, pthubert" 
> To: "tengfei chang" , "Benjamin Kaduk" 
> 
> Cc: "iesg" , "draft-ietf-6tisch-msf"
> , "6tisch" <6tisch@ietf.org>, "6tisch-chairs"
> <6tisch-cha...@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 
> Sent: lundi 11 mai 2020 14:06
> To: Benjamin Kaduk 
> Cc: The IESG ; draft-ietf-6tisch-...@ietf.org; 6tisch
> <6tisch@ietf.org>; 6tisch-cha...@ietf.org; Pascal Thubert (pthubert)
> 
> 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:nore...@ietf.org | nore...@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 bidirectio

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

[Tengfei Chang]

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
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>


-- 
——
Stay healthy, stay optimistic!

Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria

www.tchang.org/
——
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] MSF traffic adaptation under stress

[Tengfei Chang]

Hi David,

I replied inline:

On Fri, Apr 10, 2020 at 12:27 AM David Hauweele 
wrote:

> Dear 6TiSCH,
>
> In the last few months, we performed a small scale study of the
> behavior of 6TiSCH's minimal scheduling function (MSF) under stress. We
> were especially interested in the dynamics of MSF's automated
> adaptation to traffic load. Some of our conclusions have been
> summarized in a paper that we submitted to IEEE ISCC 2020. A copy of
> the evaluation section of our submission is attached to this mail.
>

Congrats on the published paper!

>
> Among our surprising findings, we observed that
>
> 1) The time required for MSF to adapt to a traffic change depends on
> the current number of cells allocated. To give an example, it takes
> much longer to go from 0 to 10 cells than from 10 to 20 cells. We
> attribute this behavior to the way MSF measures cell occupancy by
> counting the number of used and passed cells. Adaptation only occurs
> when the number of passed cells reaches a maximum. However, with light
> cell allocation, it takes longer to reach that maximum than with higher
> cell allocation.
>

Cool! I have the similar results when evaluate the MSF performance.
There are two things influencing the response time to the traffic changes
1. The value of MAX_NUM_CELLS, which you mentioned. It is configurable. By
setting it to a small value, the  response time can be reduced in case the
traffic load changes frequently.
2.  The number of cells to be added/deleted each time.  In MSF, for the
simplicity, we only add/delete 1 cell every time. An advanced version of
MSF could add/delete cells according the percentage of cell usage.

>
> 2) MSF can lead to severe over-provisioning, which can be harmful in an
> environment where the resources are scarce. We noticed that releasing
> cells was especially hard for MSF due to the fixed hysteresis
> thresholds. Indeed, the estimated cell occupancy must drop below 25%
> for cells to be released.
>

The over-provisioning is designed intentionally to avoid the fluctuation of
6P transactions.
It costs additional 50% cells in average, as a trade-off, it could reduce
the cost of sending 6P frames, and the latency caused by 6P transaction.
No sure if there is a perfect way to cover every aspects?

>
> We already have ideas to improve MSF's traffic adaptation mechanism,
> that we plan to put under test in the coming weeks. We can also provide
> you with more details if you wish. If you see interest in our evaluation
> and proposals, we are eager to discuss this further with the WG.
>

Very interesting to see your approach to improve MSF !
Referring to the MSF standardization process , as said by Pascal, we won't
be able to made big changes.
We can adapt some minor changes.
Unless there is a flaw in the draft, I would prefer to keep the draft as it..

Tengfei


>
> Best regards,
> David, Bruno, Aris and Georgios
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>


-- 
——
Stay healthy, stay optimistic!

Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria

www.tchang.org/
——
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Benjamin Kaduk's Discuss on draft-ietf-6tisch-msf-12: (with DISCUSS and COMMENT)

[Tengfei Chang]

Hi Benjamin,

I missed to update the changes according to the comments on autoTxcell and
autoRxcell collision in versino 15.
I just uploaded version 16 to cover that issues. Thanks for checking!

Tengfei

On Wed, Apr 1, 2020 at 1:57 AM Benjamin Kaduk  wrote:

> Hi Tengfei,
>
> Also inline.
>
> On Mon, Mar 30, 2020 at 01:40:24PM +0200, Tengfei Chang wrote:
> > Hi Ben,
> >
> > I replied inline:
> >
> > On Tue, Mar 24, 2020 at 8:27 PM Benjamin Kaduk  wrote:
> >
> > > Hi Tengfei,
> > >
> > > Also inline.
> > >
> > > On Tue, Mar 24, 2020 at 12:22:02PM +0100, Tengfei Chang wrote:
> > > >Hi Benjamin,
> > > >I replied inline starting with '>'
> > > >Thanks so much those detailed comments!
> > > >On Wed, Mar 11, 2020 at 6:55 PM Benjamin Kaduk via Datatracker
> > > > wrote:
> > > >
> > > >  Benjamin Kaduk has entered the following ballot position for
> > > >  draft-ietf-6tisch-msf-12: Discuss
> > > >
> > > >  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
> > > >  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/
> > > >
> > > >
> > > --
> > > >  DISCUSS:
> > > >
> > > --
> > > >
> > > >  I'm concerned that the scheduling function for autonomous cells
> can
> > > >  cause an infinite loop in the case of hash collision -- Section
> 3
> > > >  specifies that AutoTxCell always takes precedence over
> AutoRxCell,
> > > but
> > > >  if those two cells collide, the corresponding cells on the peer
> in
> > > >  question will also collide.  If both peers try to send at the
> same
> > > time
> > > >  and the hashes collide, they will both attempt to transmit
> > > indefinitely
> > > >  and never be received.
> > > >
> > > >
> > > >>. Notice that the AutoTxCell  is a shared cell, where the
> back-off
> > > >mechanism is applied.
> > > >> In case there is a collision on that cell, a back-off with
> different
> > > >exponent will be used on each side.
> > > >> The cell will be used AutoTxCell on each side at different
> timing.
> > >
> > > Ah, it seems I was misinterpreting "take precedence over" to apply to
> the
> > > entire local scheduling, not merely the case when independent tx and rx
> > > scheduling land on the same cell.  Thanks for clarifying here; is there
> > > anything useful to say in the document about how even if there is a
> > > collision in the assigned slot there's still a Tx backoff, so the cell
> is
> > > usable for Rx some of the time?
> > >
> >
> > * RESPONSE: * We could add the following sentence right after the hashing
> > collision statement:
> >
> > Notice AutoTxCell is a shared type cell which applies back off mechanism.
> > When the AutoTxCell and AutoRxCell are collided,  AutoTxCell takes
> > precedence if there is a packet to transmit.
> > In case in a back-off period, AutoRxCell is used.
>
> That sounds good, thanks.
>
> >
> > > >  There seems to be some "passing the buck" going on with respect
> to
> > > >  rate-limiting unauthenticated (join) traffic:
> > > >  draft-ietf-6tisch-minimal-security (Section 6.1.1) says that
> the SF
> > > >  "SHOULD NOT allocate additional cells as a result of traffic
> with
> > > code
> > > >  point AF43"; this document is implementing a SF, and yet we try
> to
> > > avoid
> > > >  the issue, saying that "[t]he at IPv6 layer SHOULD ensure that
> this
> > > join
> > > >  traffic is rate-limited b

Re: [6tisch] Benjamin Kaduk's Discuss on draft-ietf-6tisch-msf-12: (with DISCUSS and COMMENT)

[Tengfei Chang]

Hi Benjamin,

You may notice that the MSF revision 15 has been created.

It mainly fixed the comments your mentioned in your second response.
Thanks again for your review on MSF draft!

Tengfei

On Mon, Mar 30, 2020 at 1:40 PM Tengfei Chang 
wrote:

> Hi Ben,
>
> I replied inline:
>
> On Tue, Mar 24, 2020 at 8:27 PM Benjamin Kaduk  wrote:
>
>> Hi Tengfei,
>>
>> Also inline.
>>
>> On Tue, Mar 24, 2020 at 12:22:02PM +0100, Tengfei Chang wrote:
>> >Hi Benjamin,
>> >I replied inline starting with '>'
>> >Thanks so much those detailed comments!
>> >On Wed, Mar 11, 2020 at 6:55 PM Benjamin Kaduk via Datatracker
>> > wrote:
>> >
>> >  Benjamin Kaduk has entered the following ballot position for
>> >  draft-ietf-6tisch-msf-12: Discuss
>> >
>> >  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
>> >  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/
>> >
>> >
>> --
>> >  DISCUSS:
>> >
>> --
>> >
>> >  I'm concerned that the scheduling function for autonomous cells can
>> >  cause an infinite loop in the case of hash collision -- Section 3
>> >  specifies that AutoTxCell always takes precedence over AutoRxCell,
>> but
>> >  if those two cells collide, the corresponding cells on the peer in
>> >  question will also collide.  If both peers try to send at the same
>> time
>> >  and the hashes collide, they will both attempt to transmit
>> indefinitely
>> >  and never be received.
>> >
>> >
>> >>. Notice that the AutoTxCell  is a shared cell, where the back-off
>> >mechanism is applied.
>> >> In case there is a collision on that cell, a back-off with
>> different
>> >exponent will be used on each side.
>> >> The cell will be used AutoTxCell on each side at different timing..
>>
>> Ah, it seems I was misinterpreting "take precedence over" to apply to the
>> entire local scheduling, not merely the case when independent tx and rx
>> scheduling land on the same cell.  Thanks for clarifying here; is there
>> anything useful to say in the document about how even if there is a
>> collision in the assigned slot there's still a Tx backoff, so the cell is
>> usable for Rx some of the time?
>>
>
> * RESPONSE: * We could add the following sentence right after the hashing
> collision statement:
>
> Notice AutoTxCell is a shared type cell which applies back off mechanism.
> When the AutoTxCell and AutoRxCell are collided,  AutoTxCell takes
> precedence if there is a packet to transmit.
> In case in a back-off period, AutoRxCell is used.
>
>
>> >  There seems to be some "passing the buck" going on with respect to
>> >  rate-limiting unauthenticated (join) traffic:
>> >  draft-ietf-6tisch-minimal-security (Section 6.1.1) says that the SF
>> >  "SHOULD NOT allocate additional cells as a result of traffic with
>> code
>> >  point AF43"; this document is implementing a SF, and yet we try to
>> avoid
>> >  the issue, saying that "[t]he at IPv6 layer SHOULD ensure that
>> this join
>> >  traffic is rate-limited before it is passed to 6top sublayer where
>> MSF
>> >  can observe it".  I think we need a clear and consistent story
>> about
>> >  where this rate-limiting is supposed to happen.
>> >
>> >> Thanks for the comments! This has been discussed in some  previous
>> >revision of MSF.
>> >> It is not "passing the buck" but a decision based on the scheduling
>> >function and security context.
>> >> In the point of avoiding layer violation, the upper layer
>> information
>> >suppose NOT see-able for linker layer where 6P and MSF are.
>>
>> If we assume strict layiner 

Re: [6tisch] Benjamin Kaduk's Discuss on draft-ietf-6tisch-msf-12: (with DISCUSS and COMMENT)

[Tengfei Chang]

Hi Ben,

I replied inline:

On Tue, Mar 24, 2020 at 8:27 PM Benjamin Kaduk  wrote:

> Hi Tengfei,
>
> Also inline.
>
> On Tue, Mar 24, 2020 at 12:22:02PM +0100, Tengfei Chang wrote:
> >Hi Benjamin,
> >I replied inline starting with '>'
> >Thanks so much those detailed comments!
> >On Wed, Mar 11, 2020 at 6:55 PM Benjamin Kaduk via Datatracker
> > wrote:
> >
> >  Benjamin Kaduk has entered the following ballot position for
> >  draft-ietf-6tisch-msf-12: Discuss
> >
> >  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
> >  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/
> >
> >
> --
> >  DISCUSS:
> >
> --
> >
> >  I'm concerned that the scheduling function for autonomous cells can
> >  cause an infinite loop in the case of hash collision -- Section 3
> >  specifies that AutoTxCell always takes precedence over AutoRxCell,
> but
> >  if those two cells collide, the corresponding cells on the peer in
> >  question will also collide.  If both peers try to send at the same
> time
> >  and the hashes collide, they will both attempt to transmit
> indefinitely
> >  and never be received.
> >
> >
> >>. Notice that the AutoTxCell  is a shared cell, where the back-off
> >mechanism is applied.
> >> In case there is a collision on that cell, a back-off with different
> >exponent will be used on each side.
> >> The cell will be used AutoTxCell on each side at different timing.
>
> Ah, it seems I was misinterpreting "take precedence over" to apply to the
> entire local scheduling, not merely the case when independent tx and rx
> scheduling land on the same cell.  Thanks for clarifying here; is there
> anything useful to say in the document about how even if there is a
> collision in the assigned slot there's still a Tx backoff, so the cell is
> usable for Rx some of the time?
>

* RESPONSE: * We could add the following sentence right after the hashing
collision statement:

Notice AutoTxCell is a shared type cell which applies back off mechanism.
When the AutoTxCell and AutoRxCell are collided,  AutoTxCell takes
precedence if there is a packet to transmit.
In case in a back-off period, AutoRxCell is used.


> >  There seems to be some "passing the buck" going on with respect to
> >  rate-limiting unauthenticated (join) traffic:
> >  draft-ietf-6tisch-minimal-security (Section 6.1.1) says that the SF
> >  "SHOULD NOT allocate additional cells as a result of traffic with
> code
> >  point AF43"; this document is implementing a SF, and yet we try to
> avoid
> >  the issue, saying that "[t]he at IPv6 layer SHOULD ensure that this
> join
> >  traffic is rate-limited before it is passed to 6top sublayer where
> MSF
> >  can observe it".  I think we need a clear and consistent story about
> >  where this rate-limiting is supposed to happen.
> >
> >> Thanks for the comments! This has been discussed in some  previous
> >revision of MSF.
> >> It is not "passing the buck" but a decision based on the scheduling
> >function and security context.
> >> In the point of avoiding layer violation, the upper layer
> information
> >suppose NOT see-able for linker layer where 6P and MSF are.
>
> If we assume strict layiner so that IP information is not visible to the
> link layer where the scheduling function lives, then isn't that a flaw in
> draft-ietf-6tisch-minimal-security to say that the scheduling function
> should do [something relying on IP-layer information]?
>
> >> But regarding to security, it seems it is not avoidable.
> >> IMO, the scheduling function is aiming to provide algorithm to
> >add/remove cell according to traffic.
> >> The traffic could contains unauthenticated  join request from both
> >normal devices and malicious devices.
> >> The function does NOT have e

Re: [6tisch] Éric Vyncke's No Objection on draft-ietf-6tisch-msf-12: (with COMMENT)

[Tengfei Chang]

Hi Eric,

Thanks for your comments!
I have responded inline :

On Tue, Mar 17, 2020 at 3:20 PM Éric Vyncke via Datatracker <
nore...@ietf.org> wrote:

> Éric Vyncke has entered the following ballot position for
> draft-ietf-6tisch-msf-12: 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
> 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/
>
>
>
> --
> COMMENT:
> --
>
> Thank you for the work put into this document.
>
> Please find below some non-blocking COMMENTs and NITs. An answer will be
> appreciated.
>
> I hope that this helps to improve the document,
>
> Regards,
>
> -éric
>
> == COMMENTS ==
>
> As Alissa's comment, please use RFC 8174 boiler plate.
>
> -- Section 3 --
> Suggest to remove "The AutoRxCell MUST always remain scheduled after
> synchronized. *  6P CLEAR MUST NOT erase any autonomous cells." from the
> bulleted list and create a new paragraph for those 2 lines.
>

*RESPONSE*: Will update the text accordingly.

>
> -- Section 4 --
> The whole section seems to assume that the events will work as expected.
> But,
> what if this is not the case? E.g., the JP does not send any reply ?
>

*RESPONSE*: if JP does not send any reply, the node will retransmit another
Join request after a timeout.
However, the whole behavior is actually defined in CoJP. We repeat them
here is to make reader easy to understand the story line of a node once
bootup.

>
> -- Section 5.3 --
> "we necessarily have NumTxAck <= NumTx" is only true is all nodes behave...
>
> "MUST be divided by 2", the example is about 127 divided by 2 giving the
> unexpected value (to me at least) of 64... The text should clarify how
> rounding
> is handled as it is not a plain right shift by 1.
>
> Step 2, is it also applicable to any value of MAX_NUMTX ? Including very
> small
> or very large ones ?
>

*RESPONSE*:  thanks for the comments. We will state that the MAX_NUMTX
needs to be power of 2 to resolve the issue.
Also the recommended value of MAX_NUMTX is added in the draft.

>
> == NITS ==
>
> -- section 5.2 --
> To be checked by a native speaker but s/can have a node switch parent/can
> have
> a node switching parent/ would make the text easier to parse.
>
> -- Section 14 --
> Please order the rows of Figure 2.
>
> *RESPONSE*: it will be ordered as the time it appears in the text in
next version.

>
>
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>


-- 
——

Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria

www.tchang.org/
——
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Alvaro Retana's No Objection on draft-ietf-6tisch-msf-12: (with COMMENT)

[Tengfei Chang]

Hi Alvaro,

I replied in the following starting with " *RESPONSE *", in case ">" is not
well displayed.

On Thu, Mar 12, 2020 at 2:41 PM Alvaro Retana via Datatracker <
nore...@ietf.org> wrote:

> Alvaro Retana has entered the following ballot position for
> draft-ietf-6tisch-msf-12: 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
> 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/
>
>
>
> --
> COMMENT:
> --
>
> (1) I support Roman's DISCUSS.
>

*RESPONSE*: yes, Roman's DISCUSS should be fixed in the next revision.

>
> (2) The datatracker should point at draft-chang-6tisch-msf being replaced
> by
> this document.
>
> (3) §2: "MSF RECOMMENDS the use of 3 slotframes."  Why isn't this
> REQUIRED?
> How does an implementation signal to a neighboring node that a different
> number
> of slotframes are being used (or a different length, which is also
> RECOMMENDED
> later)?  It seems to me that RECOMMENDING may not be enough for an
> interoperable implementation...but I may also be missing something in
> 802.15.4
> or rfc8180 (or somewhere else).  [BTW, the rfc2119 keyword is RECOMMENDED
> (not
> RECOMMENDS).]
>

* RESPONSE *: In RFC8480, the 6P request is able to point out the cell is
to installed/removed on which slotframe, by specifying the slotframe ID.
There is no problem to run multiple slotframe with different length, only
the slot boundary is needed to be aligned, according to IEEE802.15.4.

>
> I think the use of RECOMMENDED (vs REQUIRED) may be related to this text a
> couple of paragraphs before:
>
>A node implementing MSF SHOULD implement the Minimal 6TiSCH
>Configuration [RFC8180], which defines the "minimal cell", a single
>shared cell providing minimal connectivity between the nodes in the
>network.  The MSF implementation provided in this specification is
>based on the implementation of the Minimal 6TiSCH Configuration.
>However, an implementor MAY implement MSF based on other
>specifications as long as the specification defines a way to
>advertise the EB/DIO among the network.
>
> I understand that a configuration other than rfc8180 is possible, but if
> this
> document is based on rfc8180, then it would be clearer if the language was
> stronger (s/SHOULD/MUST) with the understanding that the specification
> refers
> to that case.
>

* RESPONSE: *by using MUST, it will restrict MSF to RFC8180 only.
IMO, the text is able to convey the relationship between MSF and RFC8180.

>
> (4) §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].
>
> rfc8180/§6.2 says that "after having received the first EB, a node MAY
> listen
> for at most MAX_EB_DELAY seconds until it has received EBs from
> NUM_NEIGHBOURS_TO_WAIT distinct neighbors."  The use of RECOMMENDED here
> is not
> consistent with the optional nature of the MAY.
>

*RESPONSE *: thanks for the comment. This paragraph will be revised
according to RFC8180 to be consistent.


>
> (5) Nits...
>
> s/represents node's preferred parent/represents the node's preferred parent
>
> s/no restrictions to go multiple MSF sessions/no restrictions to use (?)
> multiple MSF sessions
>
> s/One of the algorithm met the rule/One of the algorithms that meet the
> rule
>
> s/Alternative behaviors may involved/Alternative behaviors may be involved
>
> s/when alternative security/when an alternative security
>
> s/node keeps listen/node keeps listening
>
> s/pairs of following counters/pairs of the following counters
>

  *RESPONSE*: Those will be reolsved in the next revision.

Tengfei

>
>
>
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>


-- 
——

Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria

www.tchang.org/
——
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Alissa Cooper's No Objection on draft-ietf-6tisch-msf-12: (with COMMENT)

[Tengfei Chang]

Thanks for the comments!

The reference will be updated in next revision!

Tengfei

On Wed, Mar 11, 2020 at 8:54 PM Alissa Cooper via Datatracker <
nore...@ietf.org> wrote:

> Alissa Cooper has entered the following ballot position for
> draft-ietf-6tisch-msf-12: 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
> 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/
>
>
>
> --
> COMMENT:
> --
>
> Please use the RFC 8174 boilerplate rather than the RFC 2119 boilerplate.
>
>
>
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>


-- 
——

Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria

www.tchang.org/
——
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Benjamin Kaduk's Discuss on draft-ietf-6tisch-msf-12: (with DISCUSS and COMMENT)

[Tengfei Chang]

located.
> But it can't tell those cells are link quality bad or because of
collision.
> If all cell PDR is so low, highly chance the routing will be affected and
switch to another neighbor.
> In experiments,  we never encounter highest PDR less 50% all time.

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

> Will add this in next revision.

>
> 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.)
>
> > For channelOffset, they are independently random selected.
> For slotOffset, since once a slotOffset is picked, the next time to
select slotOffset, that one can't be selected.
> This is indicated in the text already as "chosen among all the slotOffset
values *that satisfy the*
*  restrictions above*"


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

> The MAXBE, MAXRETRIES are defined in IEEE802.15.4 standard.
> Their values various on different network systems, according to the size
and density.
> Hence we didn't give a recommended value in this draft.

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

> We give a recommended value as this is a parameter used in the SAX
hashing algorithm.
>  This doesn't provide implementer to use other values.

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

> This is a legacy of MSF draft, which we forgot to remove. Will update in
next revision

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

> We pick power of 10 simply because it's easy for reader to understand.
Nothing specific.
> There is no restriction to use power of 2, such as 128.

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

> Yes, I agree. For action, I will simply remove the example.

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

> Yes, RFC2472 is the one defined the DSCP codepoint. Will update the
reference.

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

> They will be moved to informative reference section

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

> What I know here the sum is used by most of the classic string hashing
functions.
> The deep reason why using sum here is more mathematics question, which I
am not an expertise on it:-(
> The T here used for modular is to make sure the result fall into the
range of slotframe ( to pick slotOffset), or available frequencies ( to
pick channelOffset).

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

>  Yes, this step is removed in next revision.

Thanks so much for your comments. Will prepare revision 13 to resolve them!

>
>
>
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
>

-- 
——

Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria

www.tchang.org/
——
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Mirja Kühlewind's No Objection on draft-ietf-6tisch-msf-12: (with COMMENT)

[Tengfei Chang]

Sorry for the previous incomplete email...

On Wed, Mar 18, 2020 at 12:29 PM Tengfei Chang 
wrote:

> Hello Mirija,
>
> Thanks for the comments on the draft!
> I replied inline starting with '> '
>
> On Wed, Mar 11, 2020 at 2:19 PM Mirja Kühlewind via Datatracker <
> nore...@ietf.org> wrote:
>
>> Mirja Kühlewind has entered the following ballot position for
>> draft-ietf-6tisch-msf-12: 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
>> 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/
>>
>>
>>
>> --
>> COMMENT:
>> --
>>
>> I agree with Roman's discuss that the relation to SAX-DASFAA should be
>> clarified and if this is actually needed for interoperability (as stated
>> at
>> some point in the text) it seems this should be part of the body of the
>> document. Or what are the requirements for interoperability? What can be
>> changed in the "example" algorithm and what not?
>>
>
> > The reference for SAX has been moved into normative reference section as
> suggested by Roman.
> > The requirements for interoperability are the identical parameters for
> the SAX algorithm
> > The proposed recommend values of those parameters are presented in
> the Appendix B.
> > We still believe put those those info in the Appendix B is proper.
> > If we put the SAX algorithm into the main content of the draft, it may
> read like jumping out from the main MSF content and going to a side
> knowledge of it.
> > We believe it is enough to like the reader knowing it's a hashing
> algorithm with node EUI64 address as input, used by MSF.
>
>>
>> Two small technical points:
>> 2) Sec 9; mostly double-checking as you probably know better than me:
>> "6P timeout value is calculated as
>> ((2^MAXBE)-1)*MAXRETRIES*SLOTFRAME_LENGTH"
>> Often you calculate such a value and then multiply by 2 (or something) to
>> be on
>> the safe side, as there could be e.g. processing delays in the receiving
>> node.
>> I assume the assumption here is that you always need to get the response
>> in the
>> same/after one slot (?). If that is true, I guess the calculation is
>> fine. But
>> wanted to check that there cannot be any additional unknown delays here.
>>
>
> > Thanks for the comments. The calculation of TIMEOUT is targeting to the
> worst case, not average.
> > So a multiply with 2 is not necessary.
> > In most case, the 6P response is sent by through the autonomous cell,
> which is the same slot, as you guessed.
>
>>
>> Further, these values come a bit out of nothing. Where are  MAXBE and
>> MAXRETRIES defined? And if you have an exponential backoff that will stop
>> retrying after MAXRETRIES why do you need also a timeout in addition to
>> that?
>>
>
> > When Mote A sent a 6P request to Mote B, the 6P Timeout timer starts on
> Mote A side.
> > On Mote B side, it will try to send out the 6P response within the
> MAXRETRIES.
> > Mote A does not know when the maxretires reached, hence it needs the 6P
> Timeout to be notified.
>
>>
>> 2) Sec 16:
>> "   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
>>over that packet to MAC layer to transmit or to drop that packet
>>belongs to the upper layer and is out of scope of MSF.  As long as
>>the decision is made to hand over to MAC layer to transmit, MSF will
>>take that packet into account when adapting to traffic."
>> Why should a packet be dropped based on it DSCP...? Maybe be a bit more
>> neutral
>> here like: "   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 how to handle
>>belongs to the upper layer and is out of scope of MSF. As long as
>>a decision is made

Re: [6tisch] Mirja Kühlewind's No Objection on draft-ietf-6tisch-msf-12: (with COMMENT)

[Tengfei Chang]

1:
> - Maybe expand RPL on first occurrence.
> - s/is called as a "MSF session"/is called a "MSF session"/
>

> will integrate into next revision.

>
> 2) Sec 2
> - s/one of more slotframes/one or more slotframes/
>

> will integrate into next revision.

>
> 3) Sec 4.4
> - Please expand JRC on first occurrence. Maybe add a glossary at the
> beginning?
>

> will integrate into next revision.

>
> 4) Sec 5.1.
> "   A node implementing MSF MUST implement the behavior described in this
>section."
> Not sure if that sentence brings any additional value because that's what
> specs
> are for. But I guess it also doesn't hurt. And respectively I find the
> statement in 5.3 rather confusing "   A node implementing MSF SHOULD
> implement
> the behavior described in
>this section.  The "MUST" statements in this section hence only apply
>if the node implements schedule collision handling."
> I'm not fully sure what this even means now. Can you explain? Can you maybe
> rather provide some text to explain when it could/MAY be appropriate to not
> implement it?
>

> Yes, we agree it is not clear.
> The 'SHOULD' in the text is trying to state that the handling schedule
collisions algorithm proposed in MSF draft is one of  those algorithms.
> Any implementer can choose other algorithm to handle the collision as an
alternative.
> The 'MUST' in the text is trying to state, if the implementer decides to
implement the algorithm proposed in the draft, it must follow the
description in the section.
> I agree the 'MUST' in this case sounds redundant.

The text will be replaced as following:


> 5) Sec 16:
> "The implementation at IPv6 layer
>SHOULD ensure that this join traffic is rate-limited before it is
>passed to 6top sublayer where MSF can observe it. "
> Maybe be less indirect here:
> "The implementation at IPv6 layer
>SHOULD rate-limited join traffic before it is
>passed to 6top sublayer where MSF can observe it."
>
> Also this wording is a bit unclear:
> " How this rate limit is set is out of scope of MSF."
> Maybe
> " How this rate limit is implemented is out of scope of MSF.
>
> 6) "Appendix A.  Contributors" -> Usually Contributors is an own section
> in the
> body of the document and not part of the appendix but I'm sure the RFC
> editor
> will advise you correctly.
>
>
>
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>


-- 
——

Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria

www.tchang.org/
——
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] Roman Danyliw's Discuss on draft-ietf-6tisch-msf-12: (with DISCUSS and COMMENT)

[Tengfei Chang]

Hello Roman, 

Thanks for the comments on the draft! 
I replied inline starting with '> ' 

=== 
Roman Danyliw has entered the following ballot position for 
draft-ietf-6tisch-msf-12: Discuss 

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


-- 
DISCUSS: 
-- 

Section 3. Can the normative reference for the SAX algorithm be clarified. 
The text cites [SAX-DASFAA], but this is an informative reference (and an 
academic paper with no URL). Appendix B, appears to also describe an algorithm 
but the introduction describes the text as “an example implementation SAX hash 
function”. 

> Considering the interoperability, the SAX algorithm MUST be implemented which 
> indicates SAX is a normative reference. 
> So to your question, yes. 
> The Appendix B describes how the SAX algorithm works also it defines the 
> value of parameters used 
> In SAX, for interoperability consideration as well. 
> The DOI of this SAX paper is at https://doi.org/10.1142/9789812819536_0023 
> For action, we will move the SAX citation to normative reference along with 
> the DOI address. 

-- 
COMMENT: 
-- 

** Section 4.2. of RFC8480 outlines requirements for a specification of an SF. 
One of those it that the SF “SHOULD clearly state the application domain the SF 
is created for.” Is there one for this draft? 

> Yes, in Section 1, the application domain is declared as wide range of domain 
> but optimized for applications with upstream traffic (from the nodes to the 
> DODAG root). 

MSF is designed to operate in a wide range of application domains.
   It is optimized for applications with regular upstream traffic (from
   the nodes to the DODAG root). 


** Section 5.1. Per “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.”, is 
there an implicit DDoS being described here where rogue nodes could boot up and 
hold cells before the clean-up mechanism activates? 

> For this paragraph, we are actually trying to describe more generic situation 
> such as: 
> The maintainer of the network manually switched off the node and on later or 
> just because out of battery. 
> The clean-up mechanism happens on the parent of the node who is booted or 
> disappeared. 

> May I understand it wrong, but when a node boots up, its schedule should be 
> reset as well, hence it won't be 
> hold the previous cells to the parent. 

** Appendix B. Per step #8, what does this do? h should already have the 
final value of Step 4 assigned to h. 

> Yes, that's a redundant step. It will be removed from next re-version of MSF. 
> Thanks for pointing out! 

** Editorial Nits: 
-- Section 4.4. Typo. s/Neighbor Dicovery/Discovery/ 

> Will be fixed in next re-version, 

-- Section 16. Typos. s/MSF adapts to traffics containing packets from IP 
layer/MSF adapts to traffic containing packet from the IP layer/ 

> Will be fixed in next re-version , 

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] I-D Action: draft-ietf-6tisch-msf-12.txt

[Tengfei Chang]

Dear all,

The version 12 of MSF draft is released.
It resolves the IANA concern, which indicates that

*IANA_6TISCH_SFID_MSF is chosen from range 0-127, which is used for IETF
Review or IESG Approval.*

Tengfei



On Sat, Mar 7, 2020 at 9:45 AM  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the IPv6 over the TSCH mode of IEEE 802.15.4e
> WG of the IETF.
>
> Title   : 6TiSCH Minimal Scheduling Function (MSF)
>     Authors : Tengfei Chang
>   Malisa Vucinic
>   Xavier Vilajosana
>   Simon Duquennoy
>   Diego Dujovne
> Filename: draft-ietf-6tisch-msf-12.txt
> Pages   : 21
> Date: 2020-03-07
>
> Abstract:
>This specification defines the 6TiSCH Minimal Scheduling Function
>(MSF).  This Scheduling Function describes both the behavior of a
>node when joining the network, and how the communication schedule is
>managed in a distributed fashion.  MSF is built upon the 6TiSCH
>Operation Sublayer Protocol (6P) and the Minimal Security Framework
>for 6TiSCH.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-6tisch-msf/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-6tisch-msf-12
> https://datatracker.ietf.org/doc/html/draft-ietf-6tisch-msf-12
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-6tisch-msf-12
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>


-- 
——

Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria

www.tchang.org/
——
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] I-D Action: draft-ietf-6tisch-msf-11.txt

[Tengfei Chang]

Dear all,

A new version of MSF draft: draft-ietf-6tisch-msf-11.txt is just released.
Comparing to last version, it  specifically resolves the comments
from GENART last-call review.

Tengfei

On Fri, Feb 28, 2020 at 11:49 AM  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the IPv6 over the TSCH mode of IEEE 802.15.4e
> WG of the IETF.
>
> Title   : 6TiSCH Minimal Scheduling Function (MSF)
>     Authors : Tengfei Chang
>   Malisa Vucinic
>   Xavier Vilajosana
>   Simon Duquennoy
>   Diego Dujovne
> Filename: draft-ietf-6tisch-msf-11.txt
> Pages   : 21
> Date: 2020-02-28
>
> Abstract:
>This specification defines the 6TiSCH Minimal Scheduling Function
>(MSF).  This Scheduling Function describes both the behavior of a
>node when joining the network, and how the communication schedule is
>managed in a distributed fashion.  MSF is built upon the 6TiSCH
>Operation Sublayer Protocol (6P) and the Minimal Security Framework
>for 6TiSCH.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-6tisch-msf/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-6tisch-msf-11
> https://datatracker.ietf.org/doc/html/draft-ietf-6tisch-msf-11
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-6tisch-msf-11
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>


-- 
——

Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria

www.tchang.org/
——
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Genart last call review of draft-ietf-6tisch-msf-10

[Tengfei Chang]

Thanks for the suggestion! I will apply those changes in next the version
of MSF.

Tengfei

On Sat, Feb 15, 2020 at 11:07 PM Vijay Gurbani 
wrote:

> Dear Tengfei: Thank you for getting back to me and your time to address my
> review.
>
> The paragraph you suggest is very much improved, with one small change
> that will make it even better, as described next.
>
> In the last sentence of your proposed change, s/The algorithm of limiting
> the/However, any such algorithm of limiting the/
>
> Once again, thanks.
>
> - vijay
>
> On Sat, Feb 15, 2020 at 7:35 AM Tengfei Chang 
> wrote:
>
>> H Vijay,
>>
>> Thanks a lot for the review!
>>
>> For the major comment, what we want to explain here is that there are
>> multiple way to limit traffic to lighten the collisions.
>> Trickle timer is one of those algorithm for that purpose.
>> What "*This behavior is out of the scope for MSF*." means here actually
>> is that we don't want to limit the various ways of limiting traffic by just
>> using Trickle timer.
>> The implementer can  design their own algorithm to mitigate the traffic
>> collisions on minimal cell.
>>
>> The paragraph is rephrased as following:
>>
>> *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, the overall broadcast traffic among the node and its
>> neighbors **SHOULD NOT exceed 1/3 of the 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]. *
>> *The algorithm of limiting the broadcast traffic to meet those rules is
>> implementation-specific and is out of the scope of MSF.*
>>
>> Does this version sound clear for you?
>>
>> Tengfei
>>
>>
>>
>> On Fri, Feb 14, 2020 at 5:43 PM Vijay Gurbani via Datatracker <
>> nore...@ietf.org> wrote:
>>
>>> Reviewer: Vijay Gurbani
>>> Review result: Almost Ready
>>>
>>> I am the assigned Gen-ART reviewer for this draft. The General Area
>>> Review Team (Gen-ART) reviews all IETF documents being processed
>>> by the IESG for the IETF Chair.  Please treat these comments just
>>> like any other last call comments.
>>>
>>> For more information, please see the FAQ at
>>>
>>> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>>>
>>> Document: draft-ietf-6tisch-msf-10
>>> Reviewer: Vijay K. Gurbani
>>> Review Date: 2020-02-14
>>> IETF LC End Date: 2020-02-27
>>> IESG Telechat date: Not scheduled for a telechat
>>>
>>> Summary: The draft is almost ready to be published as a Proposed
>>> Standard.
>>>
>>> Major issues: 1
>>>
>>> Minor issues: 0
>>>
>>> Nits/editorial comments: 1
>>>
>>> Sn below stands for "Section n".
>>>
>>> Major:
>>>
>>> - S2, paragraph 4: The text says that "...a node implementing MSF SHOULD
>>> enforce
>>>   some rules for limiting the traffic broadcast frames...".  It goes
>>> ahead and
>>>   gives an example of the "Trickle" operation, but in the very next
>>> sentence, it
>>>   says, "This behavior is out of the scope for MSF."  I am confused
>>> since the
>>>   paragraph does not seem self consistent.
>>>
>>>   The paragraph is asking the implementor to use normative strength
>>> (SHOULD) to
>>>   enforce "some" rules, but does not enumerate the rules.  To be fair,
>>> the
>>>   paragraph gives one example of such a rule, but immediately
>>> invalidates that
>>>   example!  What would an implementor do?  Where would he or she go to
>>> get an
>>>   idea of "some" rules that can be used to limit the traffic of broadcast
>>>   frames? Perhaps some reference could be provided to a document that
>>> contains
>>>   these rules?
>>>
>>> Nits:
>>>
>>>  - S6: s/It is calculated/The timeout value is calculated/
>>>
>>> Thank you.
>>>
>>> ___
>>> 6tisch mailing list
>>> 6tisch@ietf.org
>>> https://www.ietf.org/mailman/listinfo/6tisch
>>>
>>
>>
>> --
>> ——
>>
>> Dr. Tengfei, Chang
>> Postdoctoral Research Engineer, Inria
>>
>> www.tchang.org/
>> ——
>>
>

-- 
——

Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria

www.tchang.org/
——
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Genart last call review of draft-ietf-6tisch-msf-10

[Tengfei Chang]

H Vijay,

Thanks a lot for the review!

For the major comment, what we want to explain here is that there are
multiple way to limit traffic to lighten the collisions.
Trickle timer is one of those algorithm for that purpose.
What "*This behavior is out of the scope for MSF*." means here actually is
that we don't want to limit the various ways of limiting traffic by just
using Trickle timer.
The implementer can  design their own algorithm to mitigate the traffic
collisions on minimal cell.

The paragraph is rephrased as following:

*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, the overall broadcast traffic among the node and its
neighbors **SHOULD NOT exceed 1/3 of the 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]. *
*The algorithm of limiting the broadcast traffic to meet those rules is
implementation-specific and is out of the scope of MSF.*

Does this version sound clear for you?

Tengfei



On Fri, Feb 14, 2020 at 5:43 PM Vijay Gurbani via Datatracker <
nore...@ietf.org> wrote:

> Reviewer: Vijay Gurbani
> Review result: Almost Ready
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
>
> For more information, please see the FAQ at
>
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>
> Document: draft-ietf-6tisch-msf-10
> Reviewer: Vijay K. Gurbani
> Review Date: 2020-02-14
> IETF LC End Date: 2020-02-27
> IESG Telechat date: Not scheduled for a telechat
>
> Summary: The draft is almost ready to be published as a Proposed Standard..
>
> Major issues: 1
>
> Minor issues: 0
>
> Nits/editorial comments: 1
>
> Sn below stands for "Section n".
>
> Major:
>
> - S2, paragraph 4: The text says that "...a node implementing MSF SHOULD
> enforce
>   some rules for limiting the traffic broadcast frames...".  It goes ahead
> and
>   gives an example of the "Trickle" operation, but in the very next
> sentence, it
>   says, "This behavior is out of the scope for MSF."  I am confused since
> the
>   paragraph does not seem self consistent.
>
>   The paragraph is asking the implementor to use normative strength
> (SHOULD) to
>   enforce "some" rules, but does not enumerate the rules.  To be fair, the
>   paragraph gives one example of such a rule, but immediately invalidates
> that
>   example!  What would an implementor do?  Where would he or she go to get
> an
>   idea of "some" rules that can be used to limit the traffic of broadcast
>   frames? Perhaps some reference could be provided to a document that
> contains
>   these rules?
>
> Nits:
>
>  - S6: s/It is calculated/The timeout value is calculated/
>
> Thank you.
>
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>


-- 
——

Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria

www.tchang.org/
——
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] draft-ietf-6tisch-ietf-msf-10 is published

[Tengfei Chang]

Hi all,

As you may notice that, the MSF version 10 is just published!
https://tools.ietf.org/html/draft-ietf-6tisch-msf-10

It resolved the comments pointed out by Yatch and Pascal.
The main content doesn't change from version 09.

This version is intended to replace 09 for proposed standard.
Thanks for handling this!

Regards,
Tengfei


-- 
——

Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria

www.tchang.org/
——
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] I-D Action: draft-ietf-6tisch-msf-10.txt

[Tengfei Chang]

Hi all,

The MSF version 10 is just published!
It resolved the comments pointed out by Yatch and Pascal.
The main content doesn't change from version 09.

Regards,
Tengfei

On Fri, Dec 13, 2019 at 4:03 PM  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the IPv6 over the TSCH mode of IEEE 802.15.4e
> WG of the IETF.
>
> Title   : 6TiSCH Minimal Scheduling Function (MSF)
>     Authors : Tengfei Chang
>   Malisa Vucinic
>   Xavier Vilajosana
>   Simon Duquennoy
>   Diego Dujovne
> Filename: draft-ietf-6tisch-msf-10.txt
> Pages   : 21
> Date: 2019-12-13
>
> Abstract:
>This specification defines the 6TiSCH Minimal Scheduling Function
>(MSF).  This Scheduling Function describes both the behavior of a
>node when joining the network, and how the communication schedule is
>managed in a distributed fashion.  MSF is built upon the 6TiSCH
>Operation Sublayer Protocol (6P) and the Minimal Security Framework
>for 6TiSCH.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-6tisch-msf/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-6tisch-msf-10
> https://datatracker.ietf.org/doc/html/draft-ietf-6tisch-msf-10
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-6tisch-msf-10
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>


-- 
——

Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria

www.tchang.org/
——
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] WGLC on draft-ietf-6tisch-msf-09

[Tengfei Chang]

Yatch,

>2.  For example, when MAX_NUMTX is set to 256, from NumTx=255 and
--> "..., when MAX_NUMTX is set to 255, ..."

For the whole sentence,

*"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."*

In this case, MAX_NUMTX should be set to 256.

Even NumTx is recommended to use 1 byte later,  when comparing NumTx and
MAX_NUMTX, a casting can be applied and doesn't break 1 byte storage of
NumTx.

Tengfei

On Fri, Dec 13, 2019 at 9:57 AM Tengfei Chang 
wrote:

> Thanks Yatch!  I will have those comments integrated into next version.
>
>
>
>  Original message 
> From: Yasuyuki Tanaka 
> Date: Fri, Dec 13, 2019, 12:01 AM
> To: Tengfei Chang 
> Cc: 6tisch@ietf.org, yasuyuki.tan...@inria.fr
> Subject: Re: [6tisch] WGLC on draft-ietf-6tisch-msf-09
>
> Hi Tengfei,
>
> Thank you for the updates. The new version addresses my comments. Here
> are a couple of trivial comments:
>
> > (Section 5.1)
> >The node MUST maintain the following counters for the selected parent
> >on both negotiated Tx and Rx cells:
>
> To my understanding, we have separate pairs of NumCellsElapsed and
> NumCellsUsed for the negotiated TX cell and the negotiated RX cell. It
> would be better to modify the sentence a little bit like:
>
> --> "The node MUST maintain the following counters for each of the
> negotiated Tx cells, and the negotiated RX cells, that are scheduled
> with the selected parent."
>
> > (Section 5.3)
> >2.  For example, when MAX_NUMTX is set to 256, from NumTx=255 and
>
> --> "..., when MAX_NUMTX is set to 255, ..."
>
> Best,
> Yatch
>
>

-- 
——

Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria

www.tchang.org/
——
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] WGLC on draft-ietf-6tisch-msf-09

[Tengfei Chang]

Thanks Yatch!  I will have those comments integrated into next version.  Original message From: Yasuyuki Tanaka Date: Fri, Dec 13, 2019, 12:01 AMTo: Tengfei Chang Cc: 6tisch@ietf.org, yasuyuki.tan...@inria.frSubject: Re: [6tisch] WGLC on draft-ietf-6tisch-msf-09Hi Tengfei,Thank you for the updates. The new version addresses my comments. Here are a couple of trivial comments:> (Section 5.1)>    The node MUST maintain the following counters for the selected parent>    on both negotiated Tx and Rx cells:To my understanding, we have separate pairs of NumCellsElapsed and NumCellsUsed for the negotiated TX cell and the negotiated RX cell. It would be better to modify the sentence a little bit like:--> "The node MUST maintain the following counters for each of the negotiated Tx cells, and the negotiated RX cells, that are scheduled with the selected parent."> (Section 5.3)>    2.  For example, when MAX_NUMTX is set to 256, from NumTx=255 and--> "..., when MAX_NUMTX is set to 255, ..."Best,Yatch___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] hepherd write up for draft-ietf-6tisch-msf: IPR statement

[Tengfei Chang]

I am not aware of IPR that applies to this draft.Regards, Tengfei Original message From: Xavi Vilajosana Guillen Date: Fri, Dec 13, 2019, 7:57 AMTo: Mališa Vučinić Cc: "Pascal Thubert (pthubert)" , "Prof. Diego Dujovne" , tisch <6tisch@ietf.org>Subject: Re: [6tisch] hepherd write up for draft-ietf-6tisch-msf: IPR statementI am not aware of IPR that applies to this draft.regardsXaviMissatge de Mališa Vučinić  del dia dj., 12 de des. 2019 a les 18:34:I’m not aware of any IPR that applies to this draft.MališaOn 12 Dec 2019, at 18:32, Prof. Diego Dujovne  wrote:“I’m not aware of any IPR that applies to this draft”Le jeu. 12 déc. 2019 à 14:31, Pascal Thubert (pthubert)  a écrit :Dear all It is time to publish draft-ietf-6tisch-msf, and as part of the process I need to confirm whether there is IPR on this specification. Authors: please confirm whether any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. You may for instance answer with “I’m not aware of any IPR that applies to this draft” or indicate a link to an IETF disclosure. Others: If you are aware of IPR that encumbers this draft, please reply to this mail with relevant information. Note that there’s oner disclosure against the draft already (https://datatracker.ietf.org/ipr/3270/). The title of the IPR disclosure is "Cisco's Statement about IPR related to draft-ietf-6tisch-msf" Many thanks Pascal -- DIEGO DUJOVNEProfesor AsociadoEscuela de Informática y TelecomunicacionesFacultad de Ingeniería - Universidad Diego Portales - Chilewww.ingenieria.udp.cl(56 2) 676 8125___6tisch mailing list6tisch@ietf.orghttps://www..ietf.org/mailman/listinfo/6tisch___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch
-- Dr. Xavier VilajosanaWireless Networks LabInternet Interdisciplinary Institute (IN3)Professor(+34) 646 633 681xvilajosana@uoc.eduhttp://xvilajosana.orghttp://wine.rdi.uoc.eduParc Mediterrani de la Tecnologia Av Carl Friedrich Gauss 5, B3 Building08860 Castelldefels (Barcelona). Catalonia. Spain  ­


INFORMACIÓ SOBRE PROTECCIÓ DE DADES DE LA UNIVERSITAT OBERTA DE CATALUNYA (UOC)Us informem que les vostres dades identificatives i les contingudes en els missatges electrònics i fitxers adjunts es poden incorporar a les nostres bases de dades amb la finalitat de gestionar les relacions i comunicacions vinculades a la UOC, i que es poden conservar mentre es mantingui la relació. Si ho voleu, podeu exercir el dret a accedir a les vostres dades, rectificar-les i suprimir-les i altres drets reconeguts normativament adreçant-vos a l'adreça de correu emissora o a fuoc...@uoc.edu.Aquest missatge i qualsevol fitxer que porti adjunt, si escau, tenen el caràcter de confidencials i s'adrecen únicament a la persona o entitat a qui s'han enviat.Així mateix, posem a la vostra disposició un delegat de protecció de dades que no només s'encarregarà de supervisar tots els tractaments de dades de la nostra entitat, sinó que us podrà atendre per a qualsevol qüestió relacionada amb el tractament de dades. La seva adreça de contacte és d...@uoc.edu.INFORMACIÓN SOBRE PROTECCIÓN DE DATOS DE LA UNIVERSITAT OBERTA DE CATALUNYA (UOC)Os informamos de que vuestros datos identificativos y los contenidos en los mensajes electrónicos y ficheros adjuntos pueden incorporarse a nuestras bases de datos con el fin de gestionar las relaciones y comunicaciones vinculadas a la UOC, y de que pueden conservarse mientras se mantenga la relación. Si lo deseáis, podéis ejercer el derecho a acceder a vuestros datos, rectificarlos y suprimirlos y otros derechos reconocidos normativamente dirigiéndoos a la dirección de correo emisora o a fuoc...@uoc.edu.Este mensaje y cualquier fichero que lleve adjunto, si procede, tienen el carácter de confidenciales y se dirigen únicamente a la persona o entidad a quien se han enviado.Así mismo, ponemos a vuestra disposición a un delegado de protección de datos que no solo se encargará de supervisar todos los tratamientos de datos de nuestra entidad, sino que podrá atenderos para cualquier cuestión relacionada con el tratamiento de datos. Su dirección de contacto es d...@uoc.edu.UNIVERSITAT OBERTA DE CATALUNYA (UOC) DATA PROTECTION INFORMATIONYour personal data and the data contained in your email messages and attached files may be stored in our databases for the purpose of maintaining relations and communications linked to the UOC, and the data may be stored for as long as these relations and communications are maintained. If you so wish, you can exercise your rights to access, rectification and erasure of your data, and any other legally held rights, by writing to the sender’s email address or to fuoc...@uoc.edu.This message and, where applicable, any attachme

[6tisch] WGLC on draft-ietf-6tisch-msf-09

[Tengfei Chang]

Hi All,

As you may notice that the  draft-ietf-6tisch-msf-09  is just published.
We believe it resolved the comments mostly from Yatch and Pascal's review.
(Thanks a lot for those comments again!)

Yatch, Pascal, could you confirm they does resolve the issues?
Also anyone else is more than welcome to review and put comments!

Regards,
Tengfei



-- 
——

Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria

www.tchang.org/
——
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] MSF adapts to traffic only for secured packets

[Tengfei Chang]

ah... I agree with you .

Just submitted the current version though. Will correct it in next version.

On Thu, Dec 12, 2019 at 6:04 PM Pascal Thubert (pthubert) <
pthub...@cisco.com> wrote:

> A nit Tengfei :
>
>
>
> « *before it is  passed to MSF. “*
>
> Would be
>
> *“before it is passed to the 6top sublayer where MSF can observe it.” Or
> something similar?*
>
>
>
> Otherwise, all good!
>
>
>
> Pascal
>
>
>
> *From:* 6tisch <6tisch-boun...@ietf.org> *On Behalf Of *Tengfei Chang
> *Sent:* jeudi 12 décembre 2019 17:51
> *To:* 6tisch <6tisch@ietf.org>
> *Subject:* Re: [6tisch] MSF adapts to traffic only for secured packets
>
>
>
> All,
>
>
>
> The following is our internal discuss about this issue.
>
>
>
> We will add the following text in "Security Consideration " section in
> MSF-09:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *   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 handover
> that packet to MAC layer to transmit or to drop that packetbelongs to
> the upper layer and is out of scope of MSF.  As long asthe decision is
> made to hand over to MAC layer to transmit, MSF willtake that packet
> into account when adapting to traffic.Note that non-zero DSCP value may
> imply that the traffic isoriginated at unauthenticated pledges,
> referring to[I-D.ietf-6tisch-minimal-security].  The implementation at
> IPv6 layerSHOULD ensure that this join traffic is rate-limited before
> it ispassed to MSF.  In case there is no rate limit for join traffic,
>  intermediate nodes in the 6TiSCH network may be prone to a resource
>  exhaustion attack, with the attacker injecting unauthenticatedtraffic
> from the network edge.  The assumption is that the ratelimiting
> function is aware of the available bandwidth in the 6top L3bundle(s)
> towards a next hop, not directly from MSF, but from aninteraction with
> the 6top sublayer that manages ultimately thebundles under MSF's
> guidance.  How this rate limit is set is out of*
>
> *   scope of MSF. *
>
>
>
>
>
>
>
>
>
> On Thu, Dec 12, 2019 at 5:26 PM Tengfei Chang 
> wrote:
>
> Thanks for the confirmation Yatch!
>
>
>
> I will forward our discuss back to the mailing list for information.
>
>
>
>
>
>
>
> On Thu, Dec 12, 2019 at 5:22 PM Yasuyuki Tanaka 
> wrote:
>
> Thank you, all.
>
> The proposed text looks very good to me. It resolves my concerns.
>
> Best,
> Yatch
>
> On 12/12/2019 6:01 AM, Tengfei Chang wrote:
> > Cool!  Thanks for the additional info! Integrated as well!
> >
> > On Thu, Dec 12, 2019 at 4:55 PM Pascal Thubert (pthubert)
> > mailto:pthub...@cisco.com>> wrote:
> >
> > Hello again
> >
> >
> >  > Note that non-zero DSCP value may imply that the traffic is
> > originated at unauthenticated pledges, see {{minimal-security}}.
> >  > The implementation at IPv6 layer SHOULD ensure that this join
> > traffic is rate-limited before it is passed to MSF.
> >  > In case there is no rate limit for join traffic, intermediate
> > nodes in the 6TiSCH network may be prone to a resource exhaustion
> > attack, with the attacker injecting unauthenticated traffic from the
> > network edge.
> >  > How this rate limit is set is out of scope of MSF.
> >
> > This would be a nice addition to the security section : )
> >
> > Note that the upper layer can only do load control if it is aware of
> > the amount of bandwidth that the current bundles provide. 6top
> > knows. So either 6top does the whole rate limiting, or there is an
> > interface between the IP layer and 6top, that is not described, even
> > in the architecture.
> >
> > The idea was to describe all this in
> > https://tools.ietf.org/html/draft-wang-6tisch-6top-sublayer but that
> > will probably not happen anytime soon.
> >
> > So maybe complementing Malisa's text as follows:
> >
> > ."
> > Note that non-zero DSCP value may imply that the traffic is
> > originated at unauthenticated pledges, see {{minimal-security}}.
> > The implementation at IPv6 layer SHOULD ensure that this join
> > traffic is rate-limited before it is passed to MSF.
> > In case there is no rate limit for join tra

Re: [6tisch] MSF adapts to traffic only for secured packets

[Tengfei Chang]

All,

The following is our internal discuss about this issue.

We will add the following text in "Security Consideration " section in
MSF-09:





















*   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   over
that packet to MAC layer to transmit or to drop that packet   belongs to
the upper layer and is out of scope of MSF.  As long as   the decision is
made to hand over to MAC layer to transmit, MSF will   take that packet
into account when adapting to traffic.   Note that non-zero DSCP value may
imply that the traffic is   originated at unauthenticated pledges,
referring to   [I-D.ietf-6tisch-minimal-security].  The implementation at
IPv6 layer   SHOULD ensure that this join traffic is rate-limited before it
is   passed to MSF.  In case there is no rate limit for join traffic,
 intermediate nodes in the 6TiSCH network may be prone to a resource
 exhaustion attack, with the attacker injecting unauthenticated   traffic
from the network edge.  The assumption is that the rate   limiting function
is aware of the available bandwidth in the 6top L3   bundle(s) towards a
next hop, not directly from MSF, but from an   interaction with the 6top
sublayer that manages ultimately the   bundles under MSF's guidance.  How
this rate limit is set is out of*
*   scope of MSF. *




On Thu, Dec 12, 2019 at 5:26 PM Tengfei Chang 
wrote:

> Thanks for the confirmation Yatch!
>
> I will forward our discuss back to the mailing list for information.
>



>
> On Thu, Dec 12, 2019 at 5:22 PM Yasuyuki Tanaka 
> wrote:
>
>> Thank you, all.
>>
>> The proposed text looks very good to me. It resolves my concerns.
>>
>> Best,
>> Yatch
>>
>> On 12/12/2019 6:01 AM, Tengfei Chang wrote:
>> > Cool!  Thanks for the additional info! Integrated as well!
>> >
>> > On Thu, Dec 12, 2019 at 4:55 PM Pascal Thubert (pthubert)
>> > mailto:pthub...@cisco.com>> wrote:
>> >
>> > Hello again
>> >
>> >
>> >  > Note that non-zero DSCP value may imply that the traffic is
>> > originated at unauthenticated pledges, see {{minimal-security}}.
>> >  > The implementation at IPv6 layer SHOULD ensure that this join
>> > traffic is rate-limited before it is passed to MSF.
>> >  > In case there is no rate limit for join traffic, intermediate
>> > nodes in the 6TiSCH network may be prone to a resource exhaustion
>> > attack, with the attacker injecting unauthenticated traffic from the
>> > network edge.
>> >  > How this rate limit is set is out of scope of MSF.
>> >
>> > This would be a nice addition to the security section : )
>> >
>> > Note that the upper layer can only do load control if it is aware of
>> > the amount of bandwidth that the current bundles provide. 6top
>> > knows. So either 6top does the whole rate limiting, or there is an
>> > interface between the IP layer and 6top, that is not described, even
>> > in the architecture.
>> >
>> > The idea was to describe all this in
>> > https://tools.ietf.org/html/draft-wang-6tisch-6top-sublayer but
>> that
>> > will probably not happen anytime soon.
>> >
>> > So maybe complementing Malisa's text as follows:
>> >
>> > ."
>> > Note that non-zero DSCP value may imply that the traffic is
>> > originated at unauthenticated pledges, see {{minimal-security}}.
>> > The implementation at IPv6 layer SHOULD ensure that this join
>> > traffic is rate-limited before it is passed to MSF.
>> > In case there is no rate limit for join traffic, intermediate nodes
>> > in the 6TiSCH network may be prone to a resource exhaustion attack,
>> > with the attacker injecting unauthenticated traffic from the network
>> > edge.
>> > The assumption is that the rate limiting function is aware of the
>> > available bandwidth in the 6top L3 bundle(s) towards a next hop, not
>> > directly from MSF, but from an interaction with the 6top sublayer
>> > that manages ultimately the bundles under MSF's guidance. How this
>> > rate limit is set is out of scope of MSF.
>> > "
>> >
>> > Pascal
>> >
>> >
>> > On Wed, Dec 11, 2019 at 6:03 PM Yasuyuki Tanaka
>> > <mailto:yasuyuki.tan...@inria.fr <mailto:yasuyuki.tan...@inria.fr>&

Re: [6tisch] MSF Shepherd review

[Tengfei Chang]

Thanks Pascal, just integrated your suggestions to the latest version.

On Sat, Dec 7, 2019 at 12:00 AM Pascal Thubert (pthubert) <
pthub...@cisco.com> wrote:

> Very good Tengfei
>
> This addresses my comments.
>
> Note that the uppercase NOT is not a valid BCP14 term by itself. I’d
> reword to say that the distribution of traffic over multiple parents is a
> routing decision that is out of scope for MSF...
>
>
> Regards,
>
> Pascal
>
> Le 6 déc. 2019 à 12:01, Tengfei Chang  a écrit :
>
> 
> I will add the following text at the intro part of MSF draft:
>
>
>
>
>
>
> *MSF works closely with RPL, specifically the routing
> parent defined in .
>   This specification only describes how MSF works with one routing parent,
> which is phrased as "selected parent". The activity of MSF
> towards to single routing parent is called as a "MSF session".
> Though the performance of MSF is evaluated only when the "selected
> parent" represents node's preferred parent, there should be no restrictions
> to go multiple MSF sessions, one per parent. In case that
> traffic goes into multiple parents, MSF is NOT in charge of deciding how
> many traffic to assign or to which parent. This should be
> decided by either upper layer or some other entity in charge of traffic
> distributing.*
>
> Then replace the sentence in the draft from "preferred parent" to
> "selected parent".
>
> What are your comments on this, Pascal, Yatch?
>
> On Sat, Nov 30, 2019 at 12:31 AM Pascal Thubert (pthubert) <
> pthub...@cisco.com> wrote:
>
>> Hello Yatch
>>
>>
>>
>> > Le 29 nov. 2019 à 22:48, Yasuyuki Tanaka  a
>> écrit :
>> >
>> > Thank you, Pascal for your comment.
>> >
>> >> On 11/29/2019 9:34 PM, Pascal Thubert (pthubert) wrote:
>> >> RPL underneath is designed to operate with multiple parents, and for a
>> good reason.
>> >
>> > I understand that point.
>> >
>> > My point is, rephrasing the word alone couldn't be enough.
>> >
>> >> Bandwidth allocation doesn’t care what traffic that is or it’s
>> direction. It cares about the amount of traffic that needs to circulate
>> over the hop.
>> >
>> > In general, yes. According to the current text of MSF, the direction is
>> relevant. For a upward neighbor, MSF allocates one negotiated TX cell just
>> after recognizing it. For a downward neighbor, it doesn't.
>> >
>> > On parent switch, the number of negotiated cells is carried over to a
>> new parent. But what if a node has one parents at some point, then it
>> selects an additional parent to handle some portion of traffic? How many
>> negotiated cells should be scheduled with the new (additional) parent? MSF
>> would have no idea.
>> >
>> > To me, this seems a totally new thing to MSF.
>> >
>>
>> Not that new just the logical continuation.
>>
>> If a child has 2 parents a and b these are independent links, each with a
>> number of cells. If it loses one parent a then the traffic on that link is
>> rerouted. The cells on that link have to be moved to other parents which
>> can include b.
>>
>> The existing cells to the parent b are not touched. If some traffic is
>> rerouted to parent b then new cells are allocated there.
>>
>>
>> > Again, having multiple MSF instances could be a solution, which doesn't
>> need the rephrasing.
>>
>> For me instance is related to RPL I do not want to run multiple instances
>> of RPL with one preferred parent each.
>>
>> What I want is to run what the draft describes but several times in
>> parallel once per active parent.
>>
>> That’s what I called session. RPL says that a node can run separate
>> instances like ship in the night and then describes the operw of one
>> instance. Similarly MSF can run multiple sessions one per link as ship in
>> the night. pretty much the draft needs to do is say that in introduction
>> and then say that the rest of the draft describes one session with one
>> parent.
>>
>> >> And it is possible to run an MSF session at L2 with each of them
>> totally independently.
>> >
>> > What do you mean by "MSF session"? If you have multiple MSF instances
>> with different SFIDs or values for the Metadata field, they can be
>> associated with different RPL DODAGsm and they will work independently.
>> >
>>
>> Th

Re: [6tisch] MSF adapts to traffic only for secured packets

[Tengfei Chang]

On Fri, Dec 6, 2019 at 9:31 PM Yasuyuki Tanaka 
wrote:

> Hi Pascal, Tengfei,
>
> On 12/6/2019 6:48 PM, Tengfei Chang wrote:
> > Yes, MSF indeed aware of the routing information such as RPL parent, I
> > consider this is like an information stored at IPv6 layer that MSF can
> > read it from without touching the frame L2 payload.
> > In such sense, I could consider the DSCP value can be another
> > information stored at upper layer that MSF have read access to it..
>
> I think these two are different things...
>

I agree, I am  only referring Pascal's reply before. What you discussed
with Malisa is another thing.


>
> Handling DSCP value will be a per-packet process. Can we pass DCSP value
> to the TSCH layer using the interface for transmission defined by
> IEEE802.15.4? I don't think so.
>

TC: Not sure this is a standard way to do so. For implementing, tut this
value or a flag could have a default value.
TC: If this value is not given, i.e. frame from IEEE802.15.4 layer, just
use the default value.

>
> I don't see any problem in allocating additional cells for "acceptable"
> amount of traffic including relayed join requests. To prevent
> application packet drops, such allocations could be a good thing.
>

I get your point from your previous  comments.
I think the key point is the during the join phase, the JP can't
distinguish the traffic from:
-pledge or
- an attacker

Another way of thinking of security, if we didn't adapt the unauthorized
traffic, the attacker can still send lots of "fake" join request,
Instead of occupying the bandwidth, it delays or drops the join request
from pledge, which is an security issue as well.

I think the compromise solution is allowing MSF adapt the traffic but
report if there is unusually mount of join traffic detected.


> Rather than giving some L3 information to L2, the L3 may need L2
> information, like available bandwidth (cells) for a certain link. For
> the MSF case, if the IPv6 layer on an intermediate node limits outgoing
> traffic of relayed join requests below 20% of available bandwidth,
> undesired cell allocations could be avoided, assuming
> LIM_NUMCELLSUSED_HIGH is 75% and the link has almost the perfect link PDR..
>
> Best,
> Yatch
>


-- 
——

Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria

www.tchang.org/
——
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] MSF Shepherd review

[Tengfei Chang]

Hi Yatch,

The session is distinguished by the parent, there is no such case that two
MSF sessions have a 'common parent'.
MSF session to parent is 1 to 1 mapping relationship.
MSF session should be ends as long as a neighbor is un-selected as parent.

In the text, I agree we only details how MSF deal with one parent.
I think Pascal agree with this but just don't want to limit MSF to just one
parent, which is clarified in the paragraph I wrote above.

Tengfei



On Fri, Dec 6, 2019 at 9:43 PM Yasuyuki Tanaka 
wrote:

> Hi Tengfei,
>
> How do we distinguish multiple MSF sessions?
> What if two MSF sessions have a same "selected parent", and then one of
> them selects another selected parent? How many negotiated cells should
> be taken over to the new selected parent?
>
> These are not covered by the current text, and I think they are out of
> the scope of MSF.
>
> > This specification only describes how MSF works with one routing parent,
> which is phrased as "selected parent".
>
> So, yes, I believe we should have this case only in the text. If we
> mention some other possibilities without concrete ideas to implement,
> they would just confuse future readers.
>
> I think, Pascal has a different opinion.
>
> Best,
> Yatch
>


-- 
——

Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria

www.tchang.org/
——
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] MSF Shepherd review

[Tengfei Chang]

I will add the following text at the intro part of MSF draft:






*MSF works closely with RPL, specifically the routing
parent defined in .
This specification only describes how MSF works with one routing parent,
which is phrased as "selected parent".The activity of MSF
towards to single routing parent is called as a "MSF session".
Though the performance of MSF is evaluated only when the "selected
parent" represents node's preferred parent, there should be no restrictions
to go multiple MSF sessions, one per parent.In case that
traffic goes into multiple parents, MSF is NOT in charge of deciding how
many traffic to assign or to which parent.This should be
decided by either upper layer or some other entity in charge of traffic
distributing.*

Then replace the sentence in the draft from "preferred parent" to "selected
parent".

What are your comments on this, Pascal, Yatch?

On Sat, Nov 30, 2019 at 12:31 AM Pascal Thubert (pthubert) <
pthub...@cisco.com> wrote:

> Hello Yatch
>
>
>
> > Le 29 nov. 2019 à 22:48, Yasuyuki Tanaka  a
> écrit :
> >
> > Thank you, Pascal for your comment.
> >
> >> On 11/29/2019 9:34 PM, Pascal Thubert (pthubert) wrote:
> >> RPL underneath is designed to operate with multiple parents, and for a
> good reason.
> >
> > I understand that point.
> >
> > My point is, rephrasing the word alone couldn't be enough.
> >
> >> Bandwidth allocation doesn’t care what traffic that is or it’s
> direction. It cares about the amount of traffic that needs to circulate
> over the hop.
> >
> > In general, yes. According to the current text of MSF, the direction is
> relevant. For a upward neighbor, MSF allocates one negotiated TX cell just
> after recognizing it. For a downward neighbor, it doesn't.
> >
> > On parent switch, the number of negotiated cells is carried over to a
> new parent. But what if a node has one parents at some point, then it
> selects an additional parent to handle some portion of traffic? How many
> negotiated cells should be scheduled with the new (additional) parent? MSF
> would have no idea.
> >
> > To me, this seems a totally new thing to MSF.
> >
>
> Not that new just the logical continuation.
>
> If a child has 2 parents a and b these are independent links, each with a
> number of cells. If it loses one parent a then the traffic on that link is
> rerouted. The cells on that link have to be moved to other parents which
> can include b.
>
> The existing cells to the parent b are not touched. If some traffic is
> rerouted to parent b then new cells are allocated there.
>
>
> > Again, having multiple MSF instances could be a solution, which doesn't
> need the rephrasing.
>
> For me instance is related to RPL I do not want to run multiple instances
> of RPL with one preferred parent each.
>
> What I want is to run what the draft describes but several times in
> parallel once per active parent.
>
> That’s what I called session. RPL says that a node can run separate
> instances like ship in the night and then describes the operw of one
> instance. Similarly MSF can run multiple sessions one per link as ship in
> the night. pretty much the draft needs to do is say that in introduction
> and then say that the rest of the draft describes one session with one
> parent.
>
> >> And it is possible to run an MSF session at L2 with each of them
> totally independently.
> >
> > What do you mean by "MSF session"? If you have multiple MSF instances
> with different SFIDs or values for the Metadata field, they can be
> associated with different RPL DODAGsm and they will work independently.
> >
>
> The draft describes a session between a parent and a child. They start the
> session, allocate resources in unison and when the session is broken they
> release the resources on each side. This happens within a L2 link. Sessions
> can live independently on different L2 links.
>
>
>
> > On 11/29/2019 9:40 PM, Prof. Diego Dujovne wrote:
> > > Would it be then a neighbour instead of a parent? (Assuming the
> > > neighbour has joined the network)
> >
> > I don't think so.
> >
>
> As Yatch said the draft describes a child handling both sides so the link
> is directional, there’s a master and a slave.
>
> This may become a problem for east west traffic with PDAO. But there’s
> still a direction so it’s doable just need to agree that the parent is
> towards the destination.
>
> All the best,
>
> Pascal
>
>
> > Best,
> > Yatch
> >
> >

Re: [6tisch] MSF adapts to traffic only for secured packets

[Tengfei Chang]

Pascal,

Yes, MSF indeed aware of the routing information such as RPL parent, I
consider this is like an information stored at IPv6 layer that MSF can read
it from without touching the frame L2 payload.
In such sense, I could consider the DSCP value can be another information
stored at upper layer that MSF have read access to it.

Thinking in this way, it seems OK for me.
Do you agree such interpreting?

Tengfei

On Thu, Dec 5, 2019 at 5:50 PM Pascal Thubert (pthubert) 
wrote:

> Hello Tengfei
>
>
>
> Architecturally speaking, MSF right now is used to allocate cells in the
> L3 bundle with a parent.
>
>
>
> “
>
>
>
> Layer-2 vs. Layer-3 bundle:
>
> Bundles are associated for either Layer-2 (switching) or Layer-3 (routing)
> forwarding operations. A pair of Layer-3 bundles (one for each direction)
> maps to an IP Link with a neighbor, whereas a set of Layer-2 bundles (of an
> "arbitrary" cardinality and direction) corresponds to the relation of one
> or more incoming bundle(s) from the previous-hop neighbor(s) with one or
> more outgoing bundle(s) to the next-hop neighbor(s) along a Track as part
> of the switching role, which may include replication and elimination
>
>
>
>
>
> “
>
>
>
> So even if it is operating under IP, it is working for IP. Even the notion
> that the neighbor is a parent is an IP layer consideration. So MSF is
> IPv6-aware.
>
> IOW the IP layer passes an IP packet to the lower layer (6top), and 6top
> needs to assign the packet to a bundle. Once that is done, if the bundle is
> managed by MSF, then MSF observes the transmission. Same goes for incoming
> traffic.
>
>
>
> Do you want me to provide the sentences or do you feel safe about putting
> your own words?
>
>
>
>
>
> *From:* 6tisch <6tisch-boun...@ietf.org> *On Behalf Of *Tengfei Chang
> *Sent:* jeudi 5 décembre 2019 08:18
> *To:* 6tisch <6tisch@ietf.org>
> *Subject:* [6tisch] MSF adapts to traffic only for secured packets
>
>
>
> Hi All,
>
>
>
> For securing the MSF, (comments from minimal security, thanks for the
> input!)
>
>
>
> In the next version of MSF, we need to add sentence saying MSF only adapts
> the traffic which is secured, practically by checking the DSCP value set
> with zero or no, which is in IPv6 header.
>
>
>
> In other hands, MSF is a link layer protocol, it doesn't suppose to know
> the frame is a IPv6 packet or not. no need to say a field value.
>
>
>
> I would like to have some suggestions/comments on this issue.
>
> Does anyone know other way to make the SF not adapt to unsecured traffic
> without knowing upper layer field?
>
>
>
> Thanks!
>
> Tengfei
>
> --
>
> ——
>
>
>
> Dr. Tengfei, Chang
>
> Postdoctoral Research Engineer, Inria
>
>
>
> www.tchang.org/
>
> ——
>


-- 
——

Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria

www.tchang.org/
——
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] MSF adapts to traffic only for secured packets

[Tengfei Chang]

Hi All,

For securing the MSF, (comments from minimal security, thanks for the
input!)

In the next version of MSF, we need to add sentence saying MSF only adapts
the traffic which is secured, practically by checking the DSCP value set
with zero or no, which is in IPv6 header.

In other hands, MSF is a link layer protocol, it doesn't suppose to know
the frame is a IPv6 packet or not. no need to say a field value.

I would like to have some suggestions/comments on this issue.
Does anyone know other way to make the SF not adapt to unsecured traffic
without knowing upper layer field?

Thanks!
Tengfei
-- 
——

Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria

www.tchang.org/
——
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] MSF Shepherd review

[Tengfei Chang]

Hi Pascal,

For the preferred parent issue:

When running MSF, the node is deal with one parent at a time out of the
parent set, which we called preferred parent.
It doesn't mean there is only one parent for each nodes.
The node may change its preferred parent to other parent, which responded
in the switching_parent section in MSF.

For the sentence:

It is recommended to set MAX_NUMCELLS value at least 4x of the maximum link
traffic load of the network with unit of packets per slotframe.


The following example helps to understand the meaning:

For example, a 2 packets/slotframe traffic load results an average 4 cells
scheduled, using the value of double number of scheduled cells (which is 8)
as MAX_NUM_CELLS gives a good resolution on cell usage calculation.

Any recommendation on the rephrasing?

Tengfei



On Wed, Nov 27, 2019 at 10:07 PM Pascal Thubert (pthubert) <
pthub...@cisco.com> wrote:

> Hello Tengfei
>
>
> Please see below
>
> Le 27 nov. 2019 à 21:44, Tengfei Chang  a écrit :
>
> 
> Thanks a lot for the reviewing, I responded inline:
>
> On Mon, Nov 25, 2019 at 6:42 PM Pascal Thubert (pthubert) <
> pthub...@cisco.com> wrote:
>
>> Dear all
>>
>>
>>
>> Please find some comments below:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Please migrate to XML2RFC v3. This will save time in the future.
>>
>
> TC: got it! Will used in version 9.
>
>
> :)
>
>
>>
>>
>>
>>
>>
>>However, an implementor MAY implement MSF without implementing
>>
>>Minimal 6TiSCH Configuration.
>>
>>
>>
>>
>>
>> This is not helpful without explanations. What is the tradeoff? How does
>> the  network operates in that case?
>>
>
> TC: Yes, the sentence is misleading. What we try to say is MSF can work
> with other specifications protocols, rather then minimal 6TiSCH
> configuration, as long as the protocols gives a way to communicate the EB
> and DIO among the network.
>
>
>
> Those words in the draft will make me a happy shepherd...
>
>
>>
>>
>>
>>
>>
>>
>>
>> For example, a Trickle Timer defined in
>>
>> [RFC6550 <https://tools.ietf.org/html/rfc6550>] MAY be applied on DIOs. 
>> However, this behavior is
>>
>> implementation-specific which is out of the scope of MSF.
>>
>>
>>
>>
>>
>> This is not for this spec to define. RPL already mandates trickle.
>> Suggestion:
>>
>>
>>
>> For example, the Trickle operation defined in [RFC6206]
>>
>> is applied on DIO Messages [RFC6550 <https://tools.ietf.org/html/rfc6550>]. 
>> This behavior is
>>
>> out of the scope of MSF.
>>
>>
>>
>> TC: agreed!
>
>>
>>
>>
>>
>>
>>
>>
>>
>> MSF RECOMMENDS the use of 3 slotframes.
>>
>>
>>
>> Discussion on slotframes and cells comes without an introduction to TSCH..
>>
>> I’d suggest you add a few words on RFC 7554 appendix A and 6TiSCH
>> architecture section 4.3.5. to introduce those concepts.
>>
>> They should probably be normative references.
>>
>
> TC: I added the following text at beginning of 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 TSCH schedule instructs a node what to do at each time
> slots, such as transmit, receive or sleep .
> In case of a slot to transmit or receive, a channel is
> assigned to the time slot.
> The tuple (slot, channel) is indicated as a cell of TSCH
> schedule.
> MSF is one of the policies defining how to manage the TSCH
> schedule.
>
>
> Excellent
>
>
>>
>>
>>
>>
>>
>>
>>
>> Section 4 has numerous SHOULD. Trouble is, when SHOULD is used, the
>> author SHOULD explain the alternate, what if the SHOULD is not followed.
>>
>> Sometimes it’s quite obvious, like when using random in 4.2. But SHOULD
>> use minimal is less obvious. Please consider adding text after the SHOULDs.
>>
>
> TC: agreed!  I have resolved this SHOULD issues in a new version. either
> the unnecessaries are removed or alternative explanation is added
>
>
> I’ll review once you published
>
>
>>
>>
>>
>>
>>
>>field it contains, the presence and contents of the IE defined in
>>
>>[I-D.richardson-6tisch-join-enhanced-beacon 
>> <https://tools.ietf.org/

Re: [6tisch] MSF Shepherd review

[Tengfei Chang]

gt;
>
> For a node, this translates into
>
>monitoring the current usage of the cells it has to the parents it uses
>
>at this point of time for sending and receiving traffic:
>
>
>
> Later there a numerous references to “preferred parent” => I’d suggest you
> use just “selected parent” or “active parent” or  something in that vein.
>
TC: I think "preferred parent" is same with "selected parent".  it
indicates one preferred parent out of multiple. Isn't it right?

>
>

>
>
>
> Cell installed at initial
>
>
>
> Not sure this is correct. Maybe “at init time”
>

TC: Applied!

>
>
>
>
>
>
>
>
> It is recommended to set MAX_NUMCELLS value at
>
>least 4 times than the maximum link traffic load of the network in
>
>packets per slotframe.
>
>
>
>
>
> This does not parse. Can you please rephrase?
>

TC: it's rephrased as "*It is recommended to set MAX_NUMCELLS value at
least 4x of the maximum link traffic load of the network with unit of
packets per slotframe*."

>
>
>
>
>
>
>
>
> Section 8 does not try to avoid collisions with autocells. But it’s easy
> to compute the slot offset of autocells for self and parent and avoids
> those. Why not do that?
>

TC: agreed! Will apply in the next version.

>
>
>
>
>
>
> Section 16 will require more attention, either now or during secdir
> review, probably both. You should start now. Think, say, what if an
> attacker claims many cells to all its neighbors? Can it attack someone’s
> autocells to block him?
>

TC: That's a good question! It may have a chance to do so. We need discuss
internally on this section.
Thanks for belling ahead!

>
>
>
>
>
>
> Voila!
>
>
>
> Pascal as shepherd.
>
>
>
>
>
>
>
>
>
>
>
>
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>


-- 
——

Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria

www.tchang.org/
——
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Yatch's review on draft-ietf-6tisch-msf-08 - Re: MSF review

[Tengfei Chang]

 one or more 6P ADD commands to schedule
> draft> the same number of negotiated cells with same cell options
> draft> to the new preferred parent
>
> [clarification] Section 5.3
>
> It would be better to mention explicitly RELOCATION for negotiated RX
> cells are not supported. If MSF supports it, we need text describing
> how.
>

TC: agreed!

>
> [possible error?] Section 5.3
>
> draft> preferred parent.  When NumTx reaches 256, both NumTx and
> draft> NumTxAck
>
> The recommended size of NumTx is 1 byte, the maximum number of which
> is 255. See Section 15.
>

TC: thanks for pointing this out!

>
> * [question] Section 6
>
> draft> 6.  6P SIGNAL command
> draft>
> draft>The 6P SIGNAL command is not used by MSF.
>
> Why do we need this section? How about other commands, COUNT and LIST,
> which are not mentioned in the draft at all?
>

TC: we only mentioned 6P SIGNAL, because that's 6P leaves it to scheduling
function, which must mention how it is used.
TC: For consistency, yes, maybe state COUNT and LIST are not used as well.

>
> If MSF doesn't support LIST, we don't need Section 8 and the rule for
> RC_EOL. Section 8 is provided for LIST, according to Xavi:
>
>  > >> What is Section 10, "Rule for Ordering Cells", for...? Why do we
>  > >> need this section?
>  > >>
>  > >
>  > > I'll let other co-authors answer
>  > >
>  >
>
>  > XV> I think this was though to handle pagination when the LIST
>  > command is received. This is, define what are the cells to return
>  > when a list command is requesting cells from a particular offset.
>
> See
> https://mailarchive.ietf.org/arch/msg/6tisch/3SrQj7LXzfFZUSEYasWcwGSrFRM


TC: (personally thought) scheduling function doesn't need to use all the 6P
commands but, when it receives, the node will response still as part of 6P
(not MSF, I agree).
TC: The order of cells in the 6P LIST response, for example, could be
defined by MSF as a certain service. (such as during debugging, I am aware
different SF communicate ends with errors)
TC: I am slightly on keeping it but not strong option.

>
>
> [technical] Section 12
>
> draft> clear: Abort the 6P Transaction.  Issue a 6P CLEAR command to
> draft> that neighbor (this command may fail at the link layer).
> draft> Remove all cells scheduled with that neighbor from the
> draft> local schedule.  Keep that node in the neighbor and routing
> draft> tables.
>
> Manipulating the routing table is not a job of MSF nor 6top. I'm not
> sure what exactly the neighbor table is here, but I'd suggest removing
> the last sentence.
>

TC: agreed!

>
> * [nits/trivial suggestions]
> - Abstract: s/MSF builds/MSF is built/ ?
> - Section 1: "the root" --> "the DODAG root" or "the RPL DODAG root"
> - Section 3: "time offset" --> "slot offset"
> - Section 3: "the frame to be transmitted" --> a unicast frame ..."
> - Section 5.1: dwonstream --> downstream
> - Section 5.3: remove "(and need to be retransmitted)", it's redundant.
> - WAITDURATION_MIN --> WAIT_DURATION_MIN (for readability)
> - MAX_NUMCELLS --> MAX_NUM_CELLS (for readability)
>

TC: all accepted! Thanks a lot!

>
> Best,
> Yatch
>
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>


-- 
——

Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria

www.tchang.org/
——
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] Fwd: I-D Action: draft-ietf-6tisch-msf-08.txt

[Tengfei Chang]

Hi All,

We have update a new version of MSF-08. It fixed some typos and syntax
errors.

The content stays the same as no comment received since version-07.

Tengfei

-- Forwarded message -
From: 
Date: Mon, Nov 4, 2019 at 10:27 PM
Subject: [6tisch] I-D Action: draft-ietf-6tisch-msf-08.txt
To: 
Cc: <6tisch@ietf.org>



A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the IPv6 over the TSCH mode of IEEE 802.15.4e
WG of the IETF.

Title   : 6TiSCH Minimal Scheduling Function (MSF)
Authors : Tengfei Chang
  Malisa Vucinic
  Xavier Vilajosana
  Simon Duquennoy
  Diego Dujovne
Filename: draft-ietf-6tisch-msf-08.txt
Pages   : 19
Date: 2019-11-04

Abstract:
   This specification defines the 6TiSCH Minimal Scheduling Function
   (MSF).  This Scheduling Function describes both the behavior of a
   node when joining the network, and how the communication schedule is
   managed in a distributed fashion.  MSF builds upon the 6TiSCH
   Operation Sublayer Protocol (6P) and the Minimal Security Framework
   for 6TiSCH.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6tisch-msf/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-6tisch-msf-08
https://datatracker.ietf.org/doc/html/draft-ietf-6tisch-msf-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-6tisch-msf-08


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch


-- 
——

Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria

www.tcahng.org
——
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] new version of msf is read for WGLC

[Tengfei Chang]

Dear All,

You may notice that a new version of MSF: draft-ietf-6tisch-msf-07 is
published and available at:
https://tools.ietf.org/html/draft-ietf-6tisch-msf-07

This version includes two changes:

1. add neighbor polling section
2. rephrased the NUMCellsElapsed definition

We believe the current version is ready for WGLC.
Please let us know if any further changes are required! Thanks!

MSF authors
-- 
——

Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria

www.tcahng.org
——
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] validating the downstream traffic adaptation in draft-ietf-6tisch-msf-06

[Tengfei Chang]

That's exactly what happened :-)

On Thu, Oct 17, 2019 at 9:22 AM  wrote:

> Hi Tengfei,
>
>
>
> Thank you for your prompt reply.
>
>
>
> >It's calculated for all Tx cells, but since there is no auto tx cell when
> there is negotiated cell in schedule.
>
> >The num_transmissions for target is calculated for negotiated tx cells.
>
>
>
> I see. It make sense especially on the last sudden drop of
> target_num_transmissions in the figure.
>
> In this case, there is only one num_tx_cell. It hit 256 then drop to 128.
>
>
>
> Thank you again.
>
>
>
> Ryan
>
>
>
> *From:* Tengfei Chang 
> *Sent:* Wednesday, October 16, 2019 7:05 PM
> *To:* paderna ryan ranario(パデルナ ラヤン ○ＲＤＣ□ＣＮＬ) <
> ryanranario1.pade...@toshiba.co.jp>
> *Cc:* 6tisch <6tisch@ietf.org>
> *Subject:* Re: [6tisch] validating the downstream traffic adaptation in
> draft-ietf-6tisch-msf-06
>
>
>
> Hi Ryan,
>
>
>
> I replied inline:
>
>
>
> On Wed, Oct 16, 2019 at 4:39 AM 
> wrote:
>
> Hi Tengfei,
>
>
>
> First of all, thank you showing us the experiment results about downstream
> traffic adaptation for MSF. It was very helpful.
>
>
>
> I would like to ask simple questions about it. About the
> "num_transmissions" in the figure, is it the number of ping transmitted? Or
> is it "NumTx" counter that counts the number of transmission attempts on
> the cell (Section 5.3 Handling Schedule Collisions)? Because of this, I
> divided my questions into two parts depending on the assumption.
>
>
>
> 1. If the "num_transmission" is ping:
>
> I assumed that "num_transmissions" is number of ping because of the label
> "1 packet/2seconds" which is rate of ping you are giving. However there are
> sudden decrease of "num_transmission" in the target_num_transmissions
> figure.
>
>
>
> It's not this case.
>
>
>
> 2. If the "num_transmission" is "NumTx":
>
> It's more like this case, but "NumTx" is a counter for one cell.
> "num_transmission" here is like the sum of "NumTx" of all cells.
>
> In the experiment, I assumed that there is no parent switch because
> "NumTx" did not reset to 0 (section 5.3).
>
> Yes.
>
> I also assumed that the "MAXNUMTX"=256. That means "NumTx" will be divided
> by 2 if it hits 256.
>
> Yes.
>
> Based on the figure target_num_transmission, at first num_transmission hit
> around 256 but did not decrease to 128 (instead it decreased around 150).
> There are also multiple sudden decrease when the num_transmission is less
> than or higher than 256. Is it because num_transmissions in this experiment
> was calculated for all negotiated cells?
>
> It's calculated for all Tx cells, but since there is no auto tx cell when
> there is negotiated cell in schedule. The num_transmissions for target is
> calculated for negotiated tx cells.
>
>
>
> While the NumTx in Section 5.3 was calculated per cell?
>
>  num_transmissions = sum(NumTx per tx cell)
>
>
>
> I also have a follow up questions below:
>
> 3. About "NumCellsElapsed" in section 5.1 Adapting to Traffic. Can you
> explain about indication of TSCH state machine that increments the
> "NumCellsElapsed"?
>
> For each slot, there are several states such as checking the type of
> current slot, looking for packet to the target neighbor, load radio etc.
> But I see why you ask the question, probably TSCH state machine is
> implementation-specific term.  I will change it as following:
>
>
>
> NumCellsElapsed :  Counts the number of negotiated cells that have
>
>elapsed since the counter was initialized.  This counter is
>
>initialized at 0. When the current cell is declared as a
>
>negotiated cell to the preferred parent, NumCellsElapsed is
>
>incremented by exactly 1, regardless of whether the cell is
>
>used to transmit/receive a frame.
>
>
>
> 4. Why the target node was chosen to be a neighbor of Dagroot out of 36
> nodes in the network?
>
> The goal of the figure is to show the behaviors of downstream traffic
> adaptation.
>
> Ping to a first hop node is sufficient to reach this goal.
>
> Chose a node with multiple hoop to dagroot  may introduce parent switch
> event along the route,
>
> which is normal, but it may make the figure not clear for showing the
> downstream adaptation behavior.
>
> Thank you.
>
> Ryan Paderna
>
>
>
>
>
> *From:* Tengfei Chang 
> *Sent:* Wednesday, Septemb

Re: [6tisch] validating the downstream traffic adaptation in draft-ietf-6tisch-msf-06

[Tengfei Chang]

Hi Ryan,

I replied inline:

On Wed, Oct 16, 2019 at 4:39 AM  wrote:

> Hi Tengfei,
>
>
>
> First of all, thank you showing us the experiment results about downstream
> traffic adaptation for MSF. It was very helpful.
>
>
>
> I would like to ask simple questions about it. About the
> "num_transmissions" in the figure, is it the number of ping transmitted? Or
> is it "NumTx" counter that counts the number of transmission attempts on
> the cell (Section 5.3 Handling Schedule Collisions)? Because of this, I
> divided my questions into two parts depending on the assumption.
>
>
>
> 1. If the "num_transmission" is ping:
>
> I assumed that "num_transmissions" is number of ping because of the label
> "1 packet/2seconds" which is rate of ping you are giving. However there are
> sudden decrease of "num_transmission" in the target_num_transmissions
> figure.
>

It's not this case.

>
>
> 2. If the "num_transmission" is "NumTx":
>
It's more like this case, but "NumTx" is a counter for one cell.
"num_transmission" here is like the sum of "NumTx" of all cells.

> In the experiment, I assumed that there is no parent switch because
> "NumTx" did not reset to 0 (section 5.3).
>
Yes.

> I also assumed that the "MAXNUMTX"=256. That means "NumTx" will be divided
> by 2 if it hits 256.
>
Yes.

> Based on the figure target_num_transmission, at first num_transmission hit
> around 256 but did not decrease to 128 (instead it decreased around 150).
> There are also multiple sudden decrease when the num_transmission is less
> than or higher than 256. Is it because num_transmissions in this experiment
> was calculated for all negotiated cells?
>
It's calculated for all Tx cells, but since there is no auto tx cell when
there is negotiated cell in schedule. The num_transmissions for target is
calculated for negotiated tx cells.

While the NumTx in Section 5.3 was calculated per cell?
>
 num_transmissions = sum(NumTx per tx cell)

I also have a follow up questions below:
>
> 3. About "NumCellsElapsed" in section 5.1 Adapting to Traffic. Can you
> explain about indication of TSCH state machine that increments the
> "NumCellsElapsed"?
>
For each slot, there are several states such as checking the type of
current slot, looking for packet to the target neighbor, load radio etc.
But I see why you ask the question, probably TSCH state machine is
implementation-specific term.  I will change it as following:

NumCellsElapsed :  Counts the number of negotiated cells that have
   elapsed since the counter was initialized.  This counter is
   initialized at 0. When the current cell is declared as a

   negotiated cell to the preferred parent, NumCellsElapsed is

   incremented by exactly 1, regardless of whether the cell is

   used to transmit/receive a frame.


4. Why the target node was chosen to be a neighbor of Dagroot out of 36
> nodes in the network?
>
The goal of the figure is to show the behaviors of downstream traffic
adaptation.
Ping to a first hop node is sufficient to reach this goal.
Chose a node with multiple hoop to dagroot  may introduce parent switch
event along the route,
which is normal, but it may make the figure not clear for showing the
downstream adaptation behavior.

> Thank you.
>
> Ryan Paderna
>
>
>
>
>
> *From:* Tengfei Chang 
> *Sent:* Wednesday, September 25, 2019 7:58 PM
> *To:* 6tisch <6tisch@ietf.org>
> *Subject:* [6tisch] validating the downstream traffic adaptation in
> draft-ietf-6tisch-msf-06
>
>
>
> Hello, All,
>
>
>
> As in the MSF draft version 06, we added the downstream traffic adaptation
> feature.
>
> here I want to share the implementation result of this feature with
> OpenWSN
>
> (I remember Pascal asked for this before as well :-) so here it is!)
>
>
>
> The setup:
>
> -
>
> I had run OpenWSN 6TiSCH implementation on OpenTestbed with 36 nodes
> deployed in our office building.
>
> After the network formed. I start to ping one nodes in the network,
> specifically using the command:
>
> ping  ::12:4b00:14b5:b571 -w 2000 -t
>
> ( ::12:4b00:14b5:b571  is the pinging target node's address)
>
> This allows to generate ping traffic at 1 request /2 seconds.
>
> The command stopped after around 25 mins.
>
>
>
> What to measure:
>
> ---
>
> We measured the changes of the number of tx cells (num_tx_cells)
>
> from dagroot to the target node ( for downstream traffic)
>
> from target node to dagroot (for upstream traffic)
>
> The result is shown in

Re: [6tisch] Clarification on MSF-06

[Tengfei Chang]

Thanks Abdussalam for the comments, I updated the text as following:

   The node SHOULD send some form of keep-alive messages to all its
   neighbors it has negotiated cell with. The node sends a keep-

   alive message to the neighbor if no frames is received from that

   neighbor within a period, which is defined as KA_PERIOD. This mechanism

   is used to poll its children to ensure the child is still reachable.

   If the keep-alive message to a child fails at the link layer (i.e.

   the maximum number of link-layer retries is reached), the node

   SHOULD declare the child as unreachable. This can happen for example

   when the child node is switched off.


   When a neighbor is declared unreachable, the node MUST remove all
   negotiated cells with that neighbor from its own schedule.  In
   addition, it MAY issue a 6P CLEAR to that neighbor (which can fail at
   the link-layer). The node MAY be removed from the neighbor table.


Does this read good to you?

Tengfei



On Fri, Oct 11, 2019 at 5:06 PM Abdussalam Baryun <
abdussalambar...@gmail.com> wrote:

> Hi Tengfei,
>
> I am interested like Christian to see the poll mechanism into this draft.
> I don't think it is right to refer to RFC7554 (problem statement) which is
> an informational RFC, while this draft is a proposed standard, I think it
> is better to state the mechanism into the use case of minimum scheduling.
> Furthermore, the RFC7554 does not mention once Keep-Alive message, but
> mentions signalling messages, which may confuse users.
>
> Best regards
> AB
>
> On Fri, Oct 11, 2019 at 3:41 PM Tengfei Chang 
> wrote:
>
>> Hi Christian,
>>
>> Thanks for pointing this issue out!
>> The neighbor polling section is removed at 03 version. Can't remember why
>> we removed it.
>>
>> I re-edited this sections to fit the current content of MSF draft. I
>> paste it below. It will the be last step of boot behavior after it starts
>> sending EB and DIO.
>>
>>The node SHOULD send some form of keep-alive messages to all its
>>neighbors it has negotiated cell with.  The Keep-Alive (KA)
>>mechanism is detailed in [RFC7554 <https://tools.ietf.org/html/rfc7554>]. 
>>  It uses the keep-alive messages
>>to its preferred parent to stay synchronized.  It MAY use the keep-
>>alive messages to other neighbors to have statistics on link quality.
>>It MAY use the keep-alive messages to its children to ensure the
>>child is still reachable.  The RECOMMENDED period for sending keep-
>>alive messages is KA_PERIOD.
>>
>>
>>If the keep-alive message to a child fails at the link layer (i.e.
>>the maximum number of link-layer retries is reached), the node SHOULD
>>declare the child as unreachable.  This can happen for example when
>>the child node is switched off.
>>
>>When a neighbor is declared unreachable, the node MUST remove all
>>negotiated cells with that neighbor from its own schedule.  In
>>addition, it MAY issue a 6P CLEAR to that neighbor (which can fail at
>>the link-layer). The node MAY be removed from the neighbor table.
>>
>>
>> If this is good for you, I will update the MSF to 07 with this change and
>> propose WGLC right after.
>> Thanks!
>>
>> Tengfei
>>
>> On Fri, Oct 11, 2019 at 1:09 PM Christian Hopfner <
>> christian.hopf...@endress.com> wrote:
>>
>>> Hi authors,
>>>
>>> I may raise a clarification question before issuing WGLC for this draft..
>>>
>>> In the past there was a section in the draft dealing with neighbor
>>> polling which seems to me beeing an important topic in terms of schedule
>>> consistency.
>>>
>>> In the latest version I don't see a mechanism which explains how a
>>> parent keeps its schedule clean after some children silently disappeared
>>> (e.g.. batteries are gone). As per my understanding in such a case the
>>> negotiated RX cell towards the child remains in the schedule forever right?
>>>
>>> Previously this was handled by neighbor polling. Which required the
>>> parent to send KA packets in a periodic manner to its childset. (This could
>>> be identified by evaluation of the neighbor set where a negotiated RX cell
>>> was scheduled to)
>>>
>>> What is the idea now how to deal with that issue?
>>>
>>>
>>> Mit freundlichen Grüßen I Best regards
>>>
>>> Christian Hopfner
>>> --
>>> Developer | TPI F&E Plattform Informatik
>>> Endress+Hauser SE+Co. K

Re: [6tisch] Clarification on MSF-06

[Tengfei Chang]

eceive this in
> error, please contact the sender and delete the material from any computer.
> This e-mail does not constitute a contract offer, a contract amendment, or
> an acceptance of a contract offer unless explicitly and conspicuously
> designated or stated as such.
>
>
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>


-- 
——

Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria

www.tcahng.org
——
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] downstream traffic adaptation

[Tengfei Chang]

Yes, I have talked with all the authors and we agreed that the current
version is ready for WGLC!

Tengfei

On Mon, Oct 7, 2019 at 3:03 PM Pascal Thubert (pthubert) 
wrote:

> Hello Tengfei and all
>
>
>
> I see that the 2 issues of IETF 105
>
>- Rules for CellList
>- Downward traffic adaptation
>
> Were discussed and there was no objection. Do you fell ready for WGLC now?
>
>
>
> All the best
>
>
>
> Pascal
>
>
>
> *From:* 6tisch <6tisch-boun...@ietf.org> *On Behalf Of *Tengfei Chang
> *Sent:* vendredi 4 octobre 2019 07:25
> *To:* Pascal Thubert (pthubert) 
> *Cc:* 6tisch <6tisch@ietf.org>
> *Subject:* Re: [6tisch] downstream traffic adaptation
>
>
>
> Hi Pascal,
>
>
>
> Yes, it is implemented and tested, the result is shown in the (long) email
> "[6tisch] validating the downstream traffic adaptation in
> draft-ietf-6tisch-msf-06".
>
> I attached the figure here as well.
>
>
>
> Though that email is long, all the information is the explaination of the
> result figure, trying to make it clear.
>
> You can check the figure directly, I think is understandable for people
> following the msf well.
>
>
>
> Tengfei
>
>
>
> On Fri, Aug 23, 2019 at 4:23 PM Pascal Thubert (pthubert) <
> pthub...@cisco.com> wrote:
>
> Looks good Tengfei. Did you already implement and test?
>
>
>
> Pascal
>
>
>
> *From:* 6tisch <6tisch-boun...@ietf.org> *On Behalf Of *Tengfei Chang
> *Sent:* vendredi 23 août 2019 14:28
> *To:* 6tisch <6tisch@ietf.org>
> *Subject:* [6tisch] downstream traffic adaptation
>
>
>
> Hi All,
>
>
>
> As discussed in IETF 105, we are going to support adapting downstream
> traffic.
>
> And now this feature is added in draft-ietf-6tisch-msf-06 published one
> weeks ago.
>
>
>
> Some main changes related to this feature are:
>
>1. After joined the network and got Rank, the node will only add one
>Tx Cell to its parent (NOT add Rx Cell)
>2. When adapting downstream traffic, the mote will check the cell
>usage on the Rx Cells.
>3. At each Rx cell to parent, the NUMCELLELAPSE increments
>4. If there is any frames received on the Rx cell, the NUMCELLUSED
>increments
>5. If NUMCELLELAPSE reaches MAX_NUMCELLS, check the percentage of cell
>usage, if higher than the high threshold, add one Rx cell to parent, if
>lower than the low threshold, remove one Rx cell to parent.
>6. The AutoRx cell is used for downstream as well and will never be
>removed.
>
> Those changes are integrated into version 06 content.. You can read it to
> check exactly how we did the changes.
>
> Please let me know if you have comments on them.. Thanks!
>
>
>
> Tengfei
>
>
>
> --
>
> Chang Tengfei,
>
> Postdoctoral Research Engineer, Inria
>
>
>
>
> --
>
> ——
>
>
>
> Dr. Tengfei, Chang
>
> Postdoctoral Research Engineer, Inria
>
>
>
> www.tcahng.org
>
> ——
>


-- 
——

Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria

www.tcahng.org
——
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] 6P Timeout in MSF

[Tengfei Chang]

Hi All,

For the current version (06) of MSF,  we defined the 6P Timeout as the
result of following equation:

6PTIMEOUT = ((2^MAXBE)-1)*MAXRETRIES*SLOTFRAME_LENGTH

   o  MAXBE is the maximum backoff exponent used
   o  MAXRETRIES is the maximum retransmission times
   o  SLOTFRAME_LENGTH represents the length of slotframe

What I believed is this is the right timeout value according the definition
of RFC8480:


The value of the 6P
   Timeout should be greater than the longest possible time it takes to
   receive the 6P Response or Confirmation.

However, this value could be super large depending the value of MAXBE and
SLOTFRAME_LENGTH.

For example, MAXBE = 5, MAXRETRIES=8 (to get a better reliability),
SLOTFRAME_LENGTH=101.
for 10 ms slot duration, the 6P timeout is more than 4 minutes. This
could cause large delay for 6P transaction, for example at network
forming phase.


So my concerns on the 6P Timeout are

- do you think this is an issue or not

- if yes,  what's your suggestion?


Thanks!


Tengfei


-- 
Chang Tengfei,
Postdoctoral Research Engineer, Inria
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] downstream traffic adaptation

[Tengfei Chang]

Hi All,

As discussed in IETF 105, we are going to support adapting downstream
traffic.
And now this feature is added in draft-ietf-6tisch-msf-06 published one
weeks ago.

Some main changes related to this feature are:

   1. After joined the network and got Rank, the node will only add one Tx
   Cell to its parent (NOT add Rx Cell)
   2. When adapting downstream traffic, the mote will check the cell usage
   on the Rx Cells.
   3. At each Rx cell to parent, the NUMCELLELAPSE increments
   4. If there is any frames received on the Rx cell, the NUMCELLUSED
   increments
   5. If NUMCELLELAPSE reaches MAX_NUMCELLS, check the percentage of cell
   usage, if higher than the high threshold, add one Rx cell to parent, if
   lower than the low threshold, remove one Rx cell to parent.
   6. The AutoRx cell is used for downstream as well and will never be
   removed.

Those changes are integrated into version 06 content. You can read it to
check exactly how we did the changes.
Please let me know if you have comments on them. Thanks!

Tengfei

-- 
Chang Tengfei,
Postdoctoral Research Engineer, Inria
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] cell rules in MSF

[Tengfei Chang]

Hi all,

As we discussed in IETF 105, we may need some way to monitor the candidate
cells to schedule before adding them.

Hence the following paragraph is added in version 06:

 As a consequence of randomly cell selection, there is a non-zero
   chance that nodes in the vicinity installed cells with same
   slotOffset and channelOffset.  An implementer MAY implement a
   strategy to monitor the candidate cells before adding them in
   CellList to avoid collision.  For example, a node MAY maintain a
   candidate cell pool for the CellList.  The candidate cells in the
   pool are pre-configured as Rx cells to listen whether there is any
   incoming frame on those cells.  If any IEEE802.15.4 frames are
   received within a pre-defined duration on one cell, that cell will be
   moved out from the pool and a new cell is selected as a candidate

   cell.  The cells in CellList are picked from the candidate pool

   directly when required.

Please let me know if you have any comments on this fix. Thanks!

Tengfei

-- 
Chang Tengfei,
Postdoctoral Research Engineer, Inria
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] moving on with MSF

[Tengfei Chang]

Hi Pascal,

The two issues mentioned in the IETF 105 meeting are

   - Rules for CellList
   - Downward traffic adaptation

Those two issues are resolved in new version published msf-06.
I will create threads for those issues to clear how they are resolved.
Thanks for reminder!

Tengfei


On Fri, Aug 23, 2019 at 11:35 AM Pascal Thubert (pthubert) <
pthub...@cisco.com> wrote:

> Dear authors
>
>
>
> At IETF 105, we mentioned that 2 issues were remaining and that we’d last
> call by fall. Which is soon.
>
> I’d like to restart the discussion and I’m asking you to start a thread
> for each of these issues so we can solve them and move forward.
>
>
>
> The ball is in you camp.
>
>
>
> Many thanks : )
>
>
>
> Pascal
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>


-- 
Chang Tengfei,
Postdoctoral Research Engineer, Inria
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] draft-ietf-6tisch-msf-06 is published

[Tengfei Chang]

Hi Thomas,


Yes, you understood correctly.


There are two related part in RFC8480 mentioned this case:

Upon receiving the request, node B checks to see if the length of the
   Candidate CellList is greater than or equal to NumCells.  Node B's SF
   verifies that all the cells in the Relocation CellList are scheduled
   with node A and are associated with the options specified in the
   CellOptions field.  If either check fails, node B MUST send a 6P
   Response to node A with return code RC_ERR_CELLLIST.  If both checks
   pass, node B's SF verifies which of the cells in the Candidate
   CellList it can install in its schedule.  How that selection is done
   is specified in the SF and is out of scope for this document.  That
   verification for the Candidate CellList can succeed (NumCells cells
   from the Candidate CellList can be used), fail (none of the cells
   from the Candidate CellList can be used), or partially succeed (fewer
   than NumCells cells from the Candidate CellList can be used).  In all
   cases, node B MUST send a 6P Response that includes a return code set
   to RC_SUCCESS and that specifies the list of cells that will be
   rescheduled following the CellOptions field.  That list can contain
   NumCells elements (succeed), 0 elements (fail), or between 0 and
   NumCells elements (partially succeed).  If N < NumCells cells appear
   in the CellList, this means that the first N cells in the Relocation
   CellList have been relocated and the remainder have not.


Here it clarified the return code for this case MUST be RC_SUCCESS.

I would say it may implies that the case should be the option 1 I
mentioned above.


Another part in concurrent 6P transaction section, it says:

 If a
   node does not have enough resources to handle concurrent 6P
   Transactions from different neighbors, it MUST reply with a 6P
   Response with return code RC_ERR_BUSY (as per Figure 38 in
   Section 6.2.4 <https://tools.ietf.org/html/rfc8480#section-6.2.4>).


I says


enough resources to handle concurrent 6P Transactions,


but the option 2 I mentioned doesn't need to be concurrent 6P transaction.

Also the RC_BUSY doesn't sound the right return code name for this case.


So does the RC_BUSY is the return code for option 2 I mentioned?


Tengfei



On Wed, Aug 14, 2019 at 4:45 PM Thomas Watteyne 
wrote:

> Tengfei,
>
> Trying to understand you point about " handle Sixtop ADD Response with
> return code SUCCESS but 0 cells in cellList"
>
> If the response code is SUCCESS, IMO that means option 1. if option 2 is
> happening (I assume you mean "there is no memory for allocating more
> cells"), I would expect another return code, no?
>
> THomas
>
>
>
> 
>
> Thomas Watteyne, PhD
> Sr Research Scientist & Innovator, Inria
> Sr Networking Design Eng, Analog Devices
> Founder & Advisor, Wattson Elements/Falco
> Founder & co-lead, UC Berkeley OpenWSN
> Co-chair, IETF 6TiSCH
>
> www.thomaswatteyne.com
> 
>
> --
>
> *De: *"tengfei chang" 
> *À: *"6tisch" <6tisch@ietf.org>
> *Envoyé: *Lundi 12 Août 2019 08:52:37
> *Objet: *[6tisch] draft-ietf-6tisch-msf-06 is published
>
> Dear all,
> The  draft-ietf-6tisch-msf-06 is just published, it mainly resolved what
> we discussed during the IETF meeting.
>
> - add rules for celllist
> - update the downstream cell adaptation strategy
>
>
> Right now, there is one issue remained to be resolved and I am not sure
> what is the right solution. So I need suggestions and feedback from you:
>
> - handle Sixtop ADD Response with return code SUCCESS but 0 cells in
> cellList
>
> There are two possible reason for this situation
> 1. the proposed celllist doesn't meet the requirement from neighbor side
> 2. there is schedule memory for adding more cells.
>
> For the 1st  reason, the node may try to send another 6P request later.
> For the 2nd reason, the node may switch to another parent but it's layer
> violated.
>
> Any solutions for this case?
>
> Tengfei
>
> --
> Chang Tengfei,
> Postdoctoral Research Engineer, Inria
>
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
>

-- 
Chang Tengfei,
Postdoctoral Research Engineer, Inria
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] draft-ietf-6tisch-msf-06 is published

[Tengfei Chang]

Dear all,

The  draft-ietf-6tisch-msf-06 is just published, it mainly resolved what we
discussed during the IETF meeting.

- add rules for celllist
- update the downstream cell adaptation strategy


Right now, there is one issue remained to be resolved and I am not sure
what is the right solution. So I need suggestions and feedback from you:

- handle Sixtop ADD Response with return code SUCCESS but 0 cells in
cellList

There are two possible reason for this situation
1. the proposed celllist doesn't meet the requirement from neighbor side
2. there is schedule memory for adding more cells.

For the 1st  reason, the node may try to send another 6P request later.
For the 2nd reason, the node may switch to another parent but it's layer
violated.

Any solutions for this case?

Tengfei

-- 
Chang Tengfei,
Postdoctoral Research Engineer, Inria
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

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

[Tengfei Chang]

Thanks Tero and Pascal for the comments!

I understand What Pascal and Tero are saying. According to the discussion
above and during the IETF 105 6TiSCH meeting, I would add the following
content in the next version of the draft in Rule of Celllist section:

Since  the Cell is randomly selected, there is a non-zero chance that
several nodes in vicinity are using the same cells.
An implementer implements MSF MAY implement a CCA strategy to monitor the
Tx cell before using it to avoid this situation.
The node MAY configure the Tx cell to be installed as Rx cell to listen any
incoming frames.
Within a pre-defined time window, if there is no frames received, the Tx
cell will replace the Rx cell to transmit frames.

The content will be something like this, we can rephrase it later.

Please let me know what you think. Thanks!

Tengfei


On Mon, Jul 22, 2019 at 5:35 PM Tero Kivinen  wrote:

> Pascal Thubert (pthubert) writes:
> > In a 6TiSCH network, CCA is useless between synchronized devices because
> > they’ll talk at the same time. So LBT must be done some other way.
>
> Note, that 802.15.4 do allow doing CCA if TschCca was set on when
> MLME-TSCHE-MODE.request primitive is called to turn TSCH mode on. In
> that case the node will do CCA at macTsCcaOffset time for macTsCca,
> and all this is done before the actual macTsTxOffset happens, i.e.,
> before the node is supposed to send its frame. This CCA does not
> protect against other nodes in the TSCH, but it will protect against
> other users on the same band, thus it should be enough for the legal
> LBT requirements.
>
> See figure 6-30 of 802.15.4-2015 in Section 6.5.4.1 and Section
> 6.2.5.2 covering TSCH CCA algorithm.
>
> > The bright side is that the future collision can be detected before it
> even
> > happens. Doing CCA on cells before allocating them, etc… I think you must
> > provide a method for that. A trade off would be to provide that method
> in the
> > draft and make it optional.
>
> Note, that doing CCA on cells is bit pointless, as that will only
> detect someone inside the same syncronized network using that slot, it
> will not detect anybody else. I think it would be better to get
> information of allocated slots from some kind of centralized node,
> keeping track of nodes allocated and making sure there is no
> collisions inside that one network.
>
> Also, you cannot use the normal TSCH CCA for that, as it is done
> BEFORE the actual time for TSCH frame to be sent on the channel. I do
> not think there is a good way to do that specified in the 802.15.4. In
> theory you could do it by configuring the specific slot for receiving
> before starting to use it for transmission, and enabling promiscuous
> mode, so you get all frames even when they are not addressed to you.
>
> So requiring such feature to be provided for 6TiSCH to work, might
> make it so that not all radios can do this, depending how much of TSCH
> is actually implemented on MAC and how much is implemented in upper
> layer.
> --
> kivi...@iki.fi
>


-- 
Chang Tengfei,
Postdoctoral Research Engineer, Inria
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] New datatracker feature: Allow presenters to upload slides

[Tengfei Chang]

Hi Pascal,

Thanks for notification!

I just pushed the PDF version but don't know how to remove the previous
uploaded slides. Could you check that? Thanks!

Tengfei

On Wed, Jul 17, 2019 at 4:51 PM Pascal Thubert (pthubert) <
pthub...@cisco.com> wrote:

> Dear all:
>
>
>
> On the side, please keep in mind that the chromebooks only play PDFs, and
> use that form to upload your slides.
>
>
>
> All the best,
>
>
>
> Pascal
>
>
>
> *From:* 6tisch <6tisch-boun...@ietf.org> *On Behalf Of *Pascal Thubert
> (pthubert)
> *Sent:* lundi 15 juillet 2019 07:22
> *To:* lp-...@ietf.org; 6tisch@ietf.org
> *Subject:* [6tisch] Fwd: New datatracker feature: Allow presenters to
> upload slides
>
>
>
> Dear all,
>
>
>
> Please see below, you can now upload your slides directly !
>
> Regards,
>
>
>
> Pascal
>
>
> Début du message transféré :
>
> *Expéditeur:* Robert Sparks 
> *Date:* 12 juillet 2019 à 17:51:56 UTC+2
> *Destinataire:* IETF WG Chairs 
> *Objet:* *New datatracker feature: Allow presenters to upload slides*
>
> Shortly after IETF 104, we added the ability for presenters to upload
> slides and suggesting to the chairs that they be added to a session.
>
> On the meeting materials page for a group (for example <
> https://datatracker.ietf.org/meeting/105/session/stir>) anyone logged in
> who is not a chair/secretary for the group gets a [Suggest New Slides]
> button.
>
> When they upload slides using that, the chairs will get email, and the
> suggestions will appear in a new block on that page.
>
> Chairs can then accept or reject each suggestion.
>
> RjS
>
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>


-- 
Chang Tengfei,
Postdoctoral Research Engineer, Inria
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

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

[Tengfei Chang]

Hi Pascal,

It is good for me to confirm it is about the hidden terminal collision
issue. Great!

For your first question that where those cells come from, it is not
mentioned in the MSF draft, but what I assumed is using the CDU matrix.

I understand what you are saying and agree the collision could happen
without performing CCA.
But with 101 slotframe length and 16 channels,  the chance to choose the
same cell (slot,channel) for two nodes in the same propagation range is
around 1/1616.
Though, along more cells are scheduled, the probability goes higher,  it's
fine with the fact most of the application doesn't have much traffic load
(less than packet / second).

The complexity to introduce CCA to have a collision-free schedule looks for
me not worthy, comparing to use simple, but maybe long discovering process
strategy, according to my opinion.

Tengfei

On Wed, Jul 17, 2019 at 4:02 PM Pascal Thubert (pthubert) <
pthub...@cisco.com> wrote:

> Hello Tengfei:
>
>
>
> You start from a cell list from which a parent can select cells to talk
> with its children. But where do those cells come from?
>
> Is that all the CDU matrix? Or a chunk off it (see discussion in Archie)?
> Or just a pseudo-random selection, possibly dependent on that parent’s MAC?
>
>
>
> Bottom line is that unless there is a central entity that allocates a non
> -overlapping chunk for each parent there might be a cell CellA that parent
> P1 wants to use with child C1 and parent P2 wants to use with child C2. If
> P1 allocates CellA first, then P2 should discover that and refrain from
> using it. For that, P2 needs to monitor (CCA) CellA before it allocates it.
> This is the same idea as listen-before-talk but applied to cell allocation.
> Ideally, once a parent proposes a cell to a child for parent-> child
> communication, the child should also listen to the cell before accepting in
> order to avoid the hidden terminal collision.
>
>
>
> The process of discovering later that the cell collisions is long and
> inefficient. If the cells are not used a lot it will take time. I disagree
> that it can be the sole procedure to avoid collisions.
>
>
>
> All the best,
>
>
>
> Pascal
>
>
>
> *From:* Tengfei Chang 
> *Sent:* mercredi 17 juillet 2019 06:12
> *To:* Pascal Thubert (pthubert) 
> *Cc:* 6tisch@ietf.org
> *Subject:* Re: [6tisch] call for review: draft-ietf-6tisch-msf-04
>
>
>
> Hi Pascal,
>
>
>
> For the synchronization, I agree. It should be listening for a
> certain period of time and then choose which EB to use for synchronizing.
> Will update in the next version.
>
>
>
> For the rule of celllist:
>
>- > Not the same problem. Think about this, where does the list of
>free cells come from? How does the parent decided let me propose cells 5,
>6, 7 and 10?
>
>
>
> Any cells that not being used by the node or marked as "locked" are a
> candidate cell in the celllist. The parent just randomly select several
> cells from them.
>
>
>
>
>
>- > One possibility is that the controller has given them away as a
>chunk of cells that the parent manages, we have text in Archie for that.
>- > The other is that the parent picks them pseudo randomly. Which
>means that another parent next to him might pick the same. If that is the
>case they will collide
>
>
>
> Actually I didn't get what you say here about the parent and another
> parent , you mean a node has two parents?
>
>
>
> The 6P packets are negotiated only with one hop neighbor node, I agree the
> same cells could be scheduled  by other links in the same propagation
> range, which is the "hidden terminal" issue.  MSF won't trying to resolve
> it when choosing cell. It could  later on use the reallocation process to
> move the colliding cell to another place as mentioned in
> https://tools.ietf.org/html/draft-ietf-6tisch-msf-05#section-5.3
>
>
>
> For each node, as long as those cells are free to allocate according to
> its own schedule, that's fine.  If there are two on going 6P transactions
> for one node with different neighbors, the "locked" feature can resolve it.
>
>
>
>- > This is an impolite behavior, the sort why we do CCA / LBT. In
>TSCH CCA and LBT are useless between synchronized nodes within a cell, but
>they can be useful before pseudo randomly grabbing a cell to add to the
>schedule. That cell should be observed using CCA for a while before it is
>proposed to the child in 6P. IOW there should be a pool of cells that are
>not used (yet) but observed (CCA) so you know you can allocate them safely
>later.
>
>
>
> Tengfei
&g

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

[Tengfei Chang]

Hi Esteban,

Thanks for the comments, I will answer inline:

On Thu, Jul 11, 2019 at 3:47 PM Esteban Municio <
esteban.muni...@uantwerpen.be> wrote:

> Hi Tengfei,
>
> I like the new changes, especially the concept of autonomous cells by
> demand and always having by default 1 downlink negotiated cell.
>
> Here are some minor comments (checking msf-05):
>
> * In Section 5.2, it is not clear for me if the parent switch occurs
> before, during or after the 3-step procedure. My intuition says that is
> should be after point 2: "the node triggers one or more 6P ADD commands
> ...". I guess it may be interesting to clarify when the actual parent
> switch occurs.
>

TC: The 3-step procedures list in the draft is happened after the parent is
switching.
parent switching is a behavior from routing layer, which MSF won't know in
advance.

>
> * Also in the same section 5.2, it could be convenient (although maybe
> redundant) to say in point 2 that the node has to schedule the same
> number "and options" of negotiated cells. This would keep also the
> ratio TX/RX with the new parent.
>

TC: Yes, will add this information in next version.

>
> * Maybe out of the scope but, should not be defined here a housekeeping
> function that removes unused negotiated cells (TX or RX)? For example
> for cells that can't be removed with a 6P transaction (e.g. nodes are
> not in range any more).
>

TC: The issue need to be resolved in some way. There are several questions
here actually:

TC: 1. neighbor reachablility
TC: We could have a timeout if a cell in schedule doesn't being used for a
while, it expired and send some packet to the neighbor to check whether the
neighbor is there.
TC: We could use keep-alive packet for this purpose what defined in
IEEE802.15.4 is that the keep-alive packet is sent to its time source only.
TC: So, we could send another frame such as sixtop request with COUNT/LIST
packet.
TC: If the neighbor is able to receive ACK from the neighbor, then it's
reachable.
TC: otherwise, it's unreachable.

TC: 2. schedule decision
if it's unreachable, then the node can remove all the cells in its schedule
and reset the SeqNum as said by Yatch.
If it's reachable, then we will need make a decision what to do for that
neighbor.
I don't think the decision should be made by the node as those cells are
not originally managed by itself (The neighbor request those cells.).

TC: This is still an open questions though, I didn't have a good solution
for this issue right now.
TC: It's good that you propose it! Thanks!


> And some minor edit comments:
>
> - "increaase"
> - two "AutoUpCells" are still there
> - two "managed unicast cell" are still there
> - "it is possible for negotiated cell to avoid the collision with
> AutoRxCell." Maybe "for a negotiated"?
> - "For burst traffic type, larger value of MAX_NUMCELLS indeed
> introduces higher latency." Maybe "a larger value"?
>

TC: Thanks for pointing them out, will be fixed in the next version!

>
> Kind regards,
> Esteban
>
> On Tue, 2019-07-02 at 12:57 +0200, Tengfei Chang wrote:
> > 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
> --
> Esteban Municio
> PhD Researcher, IDLab, University of Antwerp, in collaboration with
> imec
> esteban.muni...@uantwerpen.be
> The Beacon | Sint-Pietersvliet 7 | 2000 Antwerpen, Belgium
>
>
>

-- 
Chang Tengfei,
Postdoctoral Research Engineer, Inria
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

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

[Tengfei Chang]

Hi Pascal,

For the synchronization, I agree. It should be listening for a
certain period of time and then choose which EB to use for synchronizing.
Will update in the next version.

For the rule of celllist:

   - > Not the same problem. Think about this, where does the list of free
   cells come from? How does the parent decided let me propose cells 5, 6, 7
   and 10?


Any cells that not being used by the node or marked as "locked" are a
candidate cell in the celllist. The parent just randomly select several
cells from them.



   - > One possibility is that the controller has given them away as a
   chunk of cells that the parent manages, we have text in Archie for that.
   - > The other is that the parent picks them pseudo randomly. Which means
   that another parent next to him might pick the same. If that is the case
   they will collide


Actually I didn't get what you say here about the parent and another parent
, you mean a node has two parents?

The 6P packets are negotiated only with one hop neighbor node, I agree the
same cells could be scheduled  by other links in the same propagation
range, which is the "hidden terminal" issue.  MSF won't trying to resolve
it when choosing cell. It could  later on use the reallocation process to
move the colliding cell to another place as mentioned in
https://tools.ietf.org/html/draft-ietf-6tisch-msf-05#section-5.3

For each node, as long as those cells are free to allocate according to its
own schedule, that's fine.  If there are two on going 6P transactions for
one node with different neighbors, the "locked" feature can resolve it.


   - > This is an impolite behavior, the sort why we do CCA / LBT. In TSCH
   CCA and LBT are useless between synchronized nodes within a cell, but they
   can be useful before pseudo randomly grabbing a cell to add to the
   schedule. That cell should be observed using CCA for a while before it is
   proposed to the child in 6P. IOW there should be a pool of cells that are
   not used (yet) but observed (CCA) so you know you can allocate them safely
   later.


Tengfei


On Wed, Jul 10, 2019 at 11:54 AM Pascal Thubert (pthubert) <
pthub...@cisco.com> wrote:

> Hello Tengfei
>
>
>
> I think you missed my points
>
>
>
> Ø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.
>
>
>
> ØI meant if you are configured to get 10 beacons but after an hour
> you get only one, will you wait for 1000 years?
>
> Ø  During this step, the pledge SHOULD NOT synchronize until it received
>
> Ø enough EB from the network it wishes to join or times out trying
>
>
>
>
>
> And here there should be an idea of a value for a number of beacons and a 
> time out value. IESG reviews will ask that anyway so you better have 
> something meaningful already.
>
>
>
>
>
>  “
> 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 b

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

[Tengfei Chang]

Hi Pascal,

On Mon, Jul 8, 2019 at 3:08 PM Pascal Thubert (pthubert) 
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 .
> 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 .  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
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

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

[Tengfei Chang]

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

On Thu, Jul 4, 2019 at 5:30 PM Pascal Thubert (pthubert) 
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 | RFC |
>
>|  | (MSF)   | (NOTE:this) |
>
>
>
> “
>
>- maybe
>
>
>
>| IANA_6TISCH_SFID_MSF | Minimal Scheduling Function | RFC_THIS|
>
>|  

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

[Tengfei Chang]

Hi Toshio,

Thanks for reviewing the draft, let me reply you inline below:

On Thu, Jul 4, 2019 at 4:16 AM  wrote:

> Thanks for the update, Tengfei.
>
>
>
> I think Auto{Tx,Rx}Cells are simpler than Auto{Up,Down}Cells, because
>
> they are independent of parent switching.
>
>
>
> Here are my comments.
>
>
>
>
>
> - Section 3: address for AutoTxCells
>
>
>
> msf-04> Autonomous Tx Cell (AutoTxCell), one cell at a
>
> msf-04> [slotOffset,channelOffset] computed as a hash of the layer 2
>
> msf-04> EUI64 source address in the frame to be transmitted
>
> msf-04>
>
> msf-04> ...
>
> msf-04>
>
> msf-04> Add an AutoTxCell to the layer 2 source address which is
>
> msf-04> indicated in a frame when:
>
>
>
> The destination address (not source address) of the frame should be
>
> used to calculate the AutoTxCell, shouldn't it?
>

Yes, it should. Thanks for indicating it! Will be fixed in next version.

>
>
>
>
> - Section 3: conflict between autonomous and negotiated cells
>
>
>
> msf-04> In case of conflicting with a negotiated cell, autonomous
>
> msf-04> cells take precedence over negotiated cell.
>
>
>
> Now that autonomous cells and negotiated cells are in different
>
> slotframes, this statement is a natural result of Section 6.2.6.4 of
>
> IEEE 802.15.4-2015. I think it's a good idea to refer to it here.
>

Yes,  will be added in next version.

>
>
>
>
> - Section 5.1: CellOptions of 6P ADD
>
>
>
> There is no specification on CellOptions (Tx/Rx/Shared) of 6P ADD
>
> requests as a result of traffic adaptation. Is it up to implemtation?
>

Yes, it's kind of implied in the draft that it can be Tx=1 only or Rx=1
only.
Will add this statement in the draft next version.

>
>
>
>
> - Section 5.2: parent switch
>
>
>
> We can now remove items 1. and 2. because we don't have AutoUpCells.
>

Removed. Thanks!

>
>
>
>
> - Section 5.3: counters for handling schedule collision
>
>
>
> msf-04> The node MUST maintain the following counters for each managed
>
> msf-04> unicast cell to its preferred parent:
>
>
>
> I think the node should maintain the counters for each negotiated Tx
>
> cell to ANY neighbor, not only to the preferred parent. That is
>
> because schedule collision can occur to any Tx cell.
>
>
>
> If a node had counters for each neighbor, the paragraph starting with
>
> the following sentance would be unnecessary.
>
>
>
> msf-04> Each time the node switches preferred parent (or during the
>
> msf-04> join process when the node selects a preferred parent for the
>
> msf-04> first time), both NumTx and NumTxAck MUST be reset to 0.
>
>
>
> Although managing the counters for each neighbor is conceptually
>
> simple, I admit it might be too much overhead for constrainted nodes.
>

Thanks for the comments! However, along the network time, the node won't
send upper layer packet s to non-parent neighbor.
In case of switching parent, the traffic will go on autoTx cell.

>
>
>
>
> BTW, there are still two occurrences of "managed unicast cell" in the
>
> draft.
>

Will corrected in next version.

>
>
>
>
> Best regards,
>
> Toshio Ito
>
>
>
> *From:* 6tisch <6tisch-boun...@ietf.org> *On Behalf Of *Tengfei Chang
> *Sent:* Tuesday, July 02, 2019 7:57 PM
> *To:* 6tisch@ietf.org
> *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
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

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

[Tengfei Chang]

Thanks a lot Yatch for reviewing the draft. I will reply inline:

On Tue, Jul 2, 2019 at 2:58 PM Yasuyuki Tanaka 
wrote:

> Thank you, Tengfei and the other authors, for the update!
>
> Here are my comments:
>
> [Major] Negotiated RX cell (Section 4.6)
>
> https://tools.ietf.org/html/draft-ietf-6tisch-msf-04#section-4.6
>
> If MSF is designed for regular upstream traffic, I don't think we need
> the negotiated RX cell that is introduced by this new version.
>
> I presume the purpose of the negotiated RX cell is, to have a
> collision-free channel directed from parent to child. The parent may
> have collisions on the autonomous TX cell to a node since children of
> the node also use the cell to transmit their frames. However, once the
> network converges, the children have negotiated TX cells to the
> node. The parent of the node will be the only one who uses the
> autonomous TX cell until a topological change happens.
>
> I would rather keep unused cells in the slotframe for negotiated TX
> cells to handle "regular upstream traffic" instead of using some of
> them for negotiated RX cells (to receive frames from the parent).
>
> I'm looking forward to seeing Tengfei's evaluation results, by the way
> :-)
>

I think the purpose is indeed trying to add support for downstream traffic.
I current doesn't have a strong option on this.


>
> [Minor] AutoTxCell usage (Section 3)
>
> https://tools.ietf.org/html/draft-ietf-6tisch-msf-04#section-3
>
> Sorry for bringing this again and again, but *in general*, L2/TSCH
> layer has no idea about its upper layers. Although you can implement a
> 6TiSCH stack in which TSCH is aware of upper layer contents of a frame
> to transmit, that may not be always the case. That is, the second
> bullet point, starting with "frame is used for...", may not be able to
> be implemented.
>
> In this sense, applying "MUST" to the second bullet point seems too
> strict.
>
> draft> AutoTxCell is not permanent in the schedule but added/deleted on
> draft>demand when there is a frame to sent.  Throughout the network
> draft>lifetime, nodes MUST maintain the autonomous cells as follows:
> draft>
> draft>o  Add an AutoTxCell to the layer 2 source address which is
> indicated
> draft>   in a frame when:
> draft>
> draft>   *  there is no 6P negotiated Tx cell in schedule for that
> frame to
> draft>  transmit, and
> draft>   *  the frame is used for protocol management purposes , such
> as
> draft>  Join Request/Response, 6P Request/Response and any
> link-local
> draft>  communication for RPL routing control.
>

Hmm, it only requires read access from other layers right? It could be
implemented. But I agree MUST is too strict.  I just removed the MUST from
the sentence.

>
>
> [Minor] Unprotected frames on negotiated cells? (Section 5.1)
>
> https://tools.ietf.org/html/draft-ietf-6tisch-msf-04#section-5.1
>
> draft>   Both NumCellsElapsed and NumCellsUsed counters can be used to
> draft>   negotiated cells with cell option TX=1 or Rx=1.  All the frames
> used
> draft>   for increasing/decreasing the counters MUST be encrypted or
> draft>   decryptable with the key get from joining process.
>
> Will we have unprotected frames transmitted on negotiated TX/RX cells,
> which are expected to be scheduled with *joined* nodes? I'm not sure
> why the last sentence is necessary...
>
>
Yes, it's removed in the next version.


>
> [Minor] Length of CellList (Section 8)
>
> https://tools.ietf.org/html/draft-ietf-6tisch-msf-04#section-8
>
> What should a node do when it receives a CellList shorter than 5?
> Return RC_ERR_CELLLIST?
>
> draft> 8.  Rules for CellList
> draft>
> draft>MSF uses 2-step 6P Transactions exclusively.  6P Transactions are
> draft>only initiated by a node towards its preferred parent.  As a
> result,
> draft>the cells to put in the CellList of a 6P ADD command, and in the
> draft>candidate CellList of a RELOCATE command, are chosen by the node
> draft>initiating the 6P Transaction.  In both cases, the same rules
> apply:
> draft>
> draft>o  The CellList SHOULD contain 5 or more cells.
>

 Nothing happens actually, the 6P will process with less than 5 candidate
cells.
Though the SHOULD here is a little strong, I changed the SHOULD to
RECOMMENDED, to make it less constrain.

>
>
> [Trivial] Section 3. Autonomous Cells
>
> https://tools.ietf.org/html/draft-ietf-6tisch-msf-04#section-3
>
> draft>  o  The AutoRxCell MUST always remain scheduled.
>
> *Always* is ambiguous. A node cannot schedule an AutoRxCell until it's
> get synchronized, when the length of slotframe 1 is available.
>

Yes, changed to " The AutoRxCell MUST always remain scheduled after
synchronized"

>
>
> [Trivial] nits / editorial
>
> - "AutoUpCells" is still there
> - s/behvaior/behavior/
> - s/boostrap/bootstrap/
> - s/sheduling/scheduling/
> - s/negoitated/negotiated/
> - s/neogtiated/negotiated/
> - s/transcation/transaction/
> - s/calulated/calcula

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

[Tengfei Chang]

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
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] MSF and RPL

[Tengfei Chang]

Hi Koojana,

It's true that MSF works with RPL closely. And it's mainly designed for
upstream traffic.

As you mentioned, MSF could be extended by having autonomous cell to any
potential neighbors that the node intend to have packet exchanged with.
The concept of parent/upstream node could be replaced by the nexthop of the
routing protocols, I think.

Tengfei

On Wed, May 22, 2019 at 6:49 AM Koojana Kuladinithi <
koojana.kuladini...@tuhh.de> wrote:

> Hi
>
> I tried to understand the MSF draft and read in the impression that this
> was written to work with any kind of routing protocol.
> But, my thinking is that this is written more specifically to work with
> RPL.
>
> A
>/  \
>   C   B
>  /
> D
>
> For example, in section 3, for the above figure you will end up with
> having only 2 autonomous cells, which are correspond to the MAC addresses
> of A and C. In a flat routing, nodes cannot identify the parent/upstream
> nodes, the same four nodes example, autonomous cells might be decided based
> on neighbours, and will result in having 2 more cells corresponding to B
> and D mac addresses.
>
> Can somebody make MSF implementation working with any other routing
> protocol other than RPL?
>
> Kind regards
> Koojana
>
>
>
>
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>


-- 
Chang Tengfei,
Postdoctoral Research Engineer, Inria
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] MSF draft - minimal cell

[Tengfei Chang]

Good catch! It's probably written because in an old version when we send
join request/response on the minimal cell. We will remove this sentence in
next version.
Thanks!

Tengfei

On Fri, May 17, 2019 at 3:53 PM Koojana Kuladinithi <
koojana.kuladini...@tuhh.de> wrote:

> Hi
>
> MSF draft in section 2, I think the following sentence does not make sense
> for me.
> "Because the minimal cell is SHARED, the back-off algorithm defined in
>[IEEE802154-2015] is used to resolve collisions."
>
> AFIK, there is no backoff for broadcast packets. Did I misunderstood
> something here?
>
> Kind regards
>
> Koojana
>
>
>
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>


-- 
Chang Tengfei,
Postdoctoral Research Engineer, Inria
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] [Call for Review] draft-ietf-6tisch-msf-03

[Tengfei Chang]

Hi Toshio,

Thanks for review the draft!

For your comments:
*Minimum number of managed cells  *

TC: Yes, it's better to have at least one Tx Managed Cell to parent, maybe
one Rx Managed Cell as well for downstream, for your second point.

*Direction of managed cells*

TC: yes, the support on Tx and Rx managed cell are not clear in 03. We will
rephrase the section.

TC: One problem discovered by now is that the adaption to traffic only
works on Tx cell actually.
TC: For Rx managed cell, if the node didn't receive a packet at Rx cell, it
doesn't know where there is no packet incoming or the packet is failed
because of interference/collision.

TC: One solution for that is, we will only support Tx managed cell but the
initiator of 6P  could be parent and the request is sent to one of its
children.

Tengfei



On Tue, Apr 23, 2019 at 2:51 AM  wrote:

> Hi Tengfei,
>
>
>
> Thanks for the work. The draft looks promising.
>
>
>
> I have two comments on the managed cells.
>
>
>
>
>
> * Minimum number of managed cells
>
>
>
> Sec. 5.1: Revision -02 had the following sentence.
>
>
>
> msf-02> To have the counters working, at least one unicast cell need
>
> msf-02> to be maintained all the time and never be removed.
>
>
>
> However, this is removed in -03. So, I think it's possible that msf-03
>
> removes all managed cells, as a result of adaptation to the
>
> traffic. Is it OK?
>
>
>
>
>
> * Direction of managed cells
>
>
>
> It looks like managed cells are only for upstream traffic.
>
>
>
> In section 4.6, the joining node adds a Tx cell to the preferred
>
> parent.
>
>
>
> msf-03> Then it MUST issue a 6P ADD command MUST to that parent, with
>
> msf-03> the following fields:
>
> msf-03>o  CellOptions: set to TX=1,RX=0,SHARED=0
>
> msf-03>o  NumCells: set to 1
>
>
>
> In section 5.1, the node adds a Tx cell to the preferred parent to
>
> adapt to the traffic.
>
>
>
> msf-03> the node issues a 6P ADD command to its preferred parent to
>
> msf-03> add one managed Tx cell to the TSCH schedule.
>
>
>
> Because 6P transaction is always initiated from the child to the
>
> preferred parent, and CellOption in 6P ADD request is always (?) Tx=1
>
> RX=0, there is no downstream managed cells. As a result, downstream
>
> packets such as DAO-ACK have to use AutoDownCell or the minimal
>
> cell. I think we should have downstream cells, too.
>
>
>
>
>
> Best regards,
>
> Toshio Ito
>
>
>
> *From:* 6tisch <6tisch-boun...@ietf.org> *On Behalf Of *Tengfei Chang
> *Sent:* Tuesday, April 09, 2019 1:06 PM
> *To:* 6tisch@ietf.org
> *Subject:* [6tisch] [Call for Review] draft-ietf-6tisch-msf-03
>
>
>
> Dear all,
>
>
>
> A new version of "draft-ietf-6tisch-msf" is just published at here:
> https://www.ietf.org/id/draft-ietf-6tisch-msf-03.txt
>
>
>
> This version mainly resolved the issues presented during IETF 104 meeting.
>
> I would like to mention one of the main changes in this version is we
> removed the frame pending bit feature.
>
>
>
> It's for two reasons:
>
> - it will influence the "adapt to traffic" strategy of MSF.
>
> - the "adapt to traffic" strategy has the ability to handle burst traffic
> by using a smaller MAX_NUMCELLS
>
>
>
> Now we are calling for reviews on the new version of MSF!
>
> Any comments and feedback are appreciated!
>
>
>
> Tengfei
>
>
>
>
>
>
>
> --
>
> Chang Tengfei,
>
> Postdoctoral Research Engineer, Inria
>


-- 
Chang Tengfei,
Postdoctoral Research Engineer, Inria
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Review of draft-ietf-6tisch-msf-03

[Tengfei Chang]

After talking with Yatch, I realize I misunderstand the first comments:
(Yatch, please correct me if I said something wrong.)

For the join request/response, they are only sent on autonomous cell at the
first hop, after that, they are OK to sent on managed cell since the node
will only recognize the packet as IPv6.
For the 6P request/response,

There are two aspects we are concerning:

1. standard-complaint : now I am concerning it may be not
standard-complaint with IEEE802.15.4. The TSCH MAC layer shouldn't be able
to aware whether it's 6P or not and what is the type of it.
2. performance: we agreed that either allowing send 6P on managed cell or
not will work. Put the standard-complaint issue on the side, it's only
performance concern.

What I consider is if a 6P cell inconsistency happens, sending 6P on
managed cell may consume the number of re-transmission chance.

For example, node A has a Tx cell to node B, but node B doesn't have a Rx
cell to node A.
If node A wants to add another cell to node B by issuing a 6P ADD request,
the 6P ADD request
If 6P ADD request send on autoUpCell successfully, then there is no problem.
If not,  the ADD request will be sent later on the Tx cell but will be
failed because of inconsistent.
If there is other managed Tx Cell, the performance will be better.
If not, the ADD request will try to send on autoUpCell again but because of
backoof algorithm, it will skip it and try to send on the inconsistent Tx
cell again.
The number of re-transmission will be consumed on the Tx cell and probably
failed finally.

As a conclusion, making sure only regulating the traffic on autonomous cell
is standard complaint or not is primary.
I want to have more comments on this.
@Tero, @Pat, @pascal any comment on this?

Tengfei


On Wed, Apr 17, 2019 at 4:58 PM Tengfei Chang 
wrote:

> Hi Yatch,
>
> Thanks for the reviewing! I will reply your comments inline.
>
> On Tue, Apr 9, 2019 at 2:03 PM Yasuyuki Tanaka 
> wrote:
>
>> Thank you, the authors!
>>
>> I confirmed most of my comments to the previous version have been
>> addressed. It reads better :-)
>>
>> Here are my comments: two comments are major, the rest are minor.
>>
>>
>> [major: usage of the autonomous cell and the managed cell]
>>
>> The draft specifies rules what type of frames MUST be sent over the
>> autonomous cell. How can we implement the rules on top of TSCH MAC
>> defined by IEEE802.15.4?
>>
>> https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-3
>> draft-03>  The traffic on the autonomous cells are scheduled as:
>> draft-03>
>> draft-03>  o  Join Request packets and 6P ADD/DELETE Request frames to the
>> draft-03> node's Join Proxy or its RPL routing parent MUST be sent on
>> draft-03> AutoUpCell.
>> draft-03>  o  Join Response packets and 6P ADD/DELETE Response frames to
>> the
>> draft-03> pledge or its RPL routing child MUST be sent on
>> AutoDownCell.
>> draft-03>  o  6P RELOCATE Request frames to the node's RPL routing child
>> MUST be
>> draft-03> sent on AutoDownCell.
>> draft-03>  o  6P RELOCATE Response frames to its RPL routing parent MUST
>> be sent
>> draft-03> on AutoUpCell.
>>
>
> TC: For implementing, it requires some flag for the frame to mark as what
> type of 6P frames.
> TC: I agree that there are other frames that should be able to send on the
> autonomous cell according to IEEE802.15.4 standards.
> TC: Here is to limit the type frames on one cell but it doesn't break what
> defined in IEEE802.15.4 standards, IMO.
>
>>
>> https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-5.1
>> draft-03>   Adding/removing/relocating cells involves exchanging frames
>> that
>> draft-03>   contain 6P commands.  All 6P Request frames to its parent
>> MUST be
>> draft-03>   sent on the AutoUpCell All 6P Response frames to non-parent
>> neighbor
>> draft-03>   MUST be sent on AutoDownCell.
>>
>> At draft-ietf-6tisch-msf-02, the autonomous cell and the managed cell
>> to the same neighbor are used without distinction. This is totally
>> fine and straightforward. Why do we need the change to this part?
>>
>
> TC: this is to avoid the failure of 6P frames on inconsistent managed
> cell, for example, the node has a Tx cell to parent but the parent doesn't
> have the RX cell.
> TC: Though, it will be resolved at next 6P transaction (two transactions
> actually), it will be underperformance.
>
>>
>> https://tools.ietf.org/html/draft-ietf-6tisch-msf-02#section-5.1
>> draft-02>   Autonomous cells are used indistinguishably
>> draft-02>   togethe

Re: [6tisch] Review of draft-ietf-6tisch-msf-03

[Tengfei Chang]

Hi Yatch,

Thanks for the reviewing! I will reply your comments inline.

On Tue, Apr 9, 2019 at 2:03 PM Yasuyuki Tanaka 
wrote:

> Thank you, the authors!
>
> I confirmed most of my comments to the previous version have been
> addressed. It reads better :-)
>
> Here are my comments: two comments are major, the rest are minor.
>
>
> [major: usage of the autonomous cell and the managed cell]
>
> The draft specifies rules what type of frames MUST be sent over the
> autonomous cell. How can we implement the rules on top of TSCH MAC
> defined by IEEE802.15.4?
>
> https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-3
> draft-03>  The traffic on the autonomous cells are scheduled as:
> draft-03>
> draft-03>  o  Join Request packets and 6P ADD/DELETE Request frames to the
> draft-03> node's Join Proxy or its RPL routing parent MUST be sent on
> draft-03> AutoUpCell.
> draft-03>  o  Join Response packets and 6P ADD/DELETE Response frames to
> the
> draft-03> pledge or its RPL routing child MUST be sent on AutoDownCell.
> draft-03>  o  6P RELOCATE Request frames to the node's RPL routing child
> MUST be
> draft-03> sent on AutoDownCell.
> draft-03>  o  6P RELOCATE Response frames to its RPL routing parent MUST
> be sent
> draft-03> on AutoUpCell.
>

TC: For implementing, it requires some flag for the frame to mark as what
type of 6P frames.
TC: I agree that there are other frames that should be able to send on the
autonomous cell according to IEEE802.15.4 standards.
TC: Here is to limit the type frames on one cell but it doesn't break what
defined in IEEE802.15.4 standards, IMO.

>
> https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-5.1
> draft-03>   Adding/removing/relocating cells involves exchanging frames
> that
> draft-03>   contain 6P commands.  All 6P Request frames to its parent MUST
> be
> draft-03>   sent on the AutoUpCell All 6P Response frames to non-parent
> neighbor
> draft-03>   MUST be sent on AutoDownCell.
>
> At draft-ietf-6tisch-msf-02, the autonomous cell and the managed cell
> to the same neighbor are used without distinction. This is totally
> fine and straightforward. Why do we need the change to this part?
>

TC: this is to avoid the failure of 6P frames on inconsistent managed cell,
for example, the node has a Tx cell to parent but the parent doesn't have
the RX cell.
TC: Though, it will be resolved at next 6P transaction (two transactions
actually), it will be underperformance.

>
> https://tools.ietf.org/html/draft-ietf-6tisch-msf-02#section-5.1
> draft-02>   Autonomous cells are used indistinguishably
> draft-02>   together with dedicated cells, for broadcast or unicast
> traffic with
> draft-02>   the target neighbor.  The procedure to remove autonomous cells
> is
> draft-02>   described in Section 3.
>
> To my understandings, TSCH MAC selects a cell (link) to transmit a
> frame seeing macTxType, macLinkType, and macNodeAddress of the cell,
> which are defined in section 8.4.2.2.2 of IEEE802.15.4-2015. TSCH MAC
> cares only the destination MAC address and the frame type of a TX
> frame, doesn't it?
>
> TC: It does in IEEE802.15.4 standard.
TC: I am just not considering instead of caring only the destination MAC
address and frame type, caring about more parameters is not a violation of
standard.
TC: Though, just in my opinion.

>
> [major: some confusions in Section 5]
>
> We don't need to maintain NumCellsElapsed and NumCellsUsed for RX
> cells because managed cells have always only TX=1.
>
> https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-5.1
> draft-03>   NumCellsElapsed :  Counts the number of managed cells that have
> draft-03>   elapsed since the counter was initialized.  This counter is
> draft-03>   initialized at 0.  Each time the TSCH state machine
> indicates
> draft-03>   that the current cell is a managed cell to the preferred
> parent,
> draft-03>   NumCellsElapsed is incremented by exactly 1, regardless of
> draft-03>   whether the cell is used to transmit/receive a frame.
>
> "to transmit/receive a frame" in the last sentence should be replaced
> with "to transmit a frame", and
>
> draft-03>   Both NumCellsElapsed and NumCellsUsed counters can be used to
> cell
> draft-03>   with cell option TX=1 or RX=1.
>
> "with cell option TX=1 or RX=1" should be replaced with "with cell
> option TX=1"?
>
> Another thing is related to what Fabrice pointed out. There is
> something wrong in text about the RELOCATE operation. Since NumTx and
> NumTxAck are the key counters for the RELOCATE operation, a RELOCATE
> request is never issued for an RX cell. Then, the direction in the
> following text is opposite...
>
> https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-3
> draft-03>  o  6P RELOCATE Request frames to the node's RPL routing child
> MUST be
> draft-03> sent on AutoDownCell.
> draft-03>  o  6P RELOCATE Response frames to its RPL routing parent MUST
> be sent
> draft-03> on AutoUpCell.
>

TC

Re: [6tisch] [Call for Review] draft-ietf-6tisch-msf-03

[Tengfei Chang]

Hi Atis,

Thank you for reviewing and giving the comments! I will reply them below.

For your comments:
*- There is still one reference left to the number 16 as the max number of
channels (which 2.4 GHz frequency-band-specific). It's in the formula
`channelOffset(MAC) = hash(EUI64, 16)`. This may conflict with the
intention expressed previously in the text, where you say that "the
coordinates are computed to distribute the cells across all channel
offsets" (i.e. not exactly 16 channel offsets)*

TC: Yes, we will replace the 16 by NUM_CH_OFFSET and added it to the
recommended value table.

*- Have you considered suggesting that the implementers to prioritize 6top
packets over data packets?*

TC: Sure, we may add a rule about the application packet is not allowed to
send on autonomous cell, this will separate the traffic between 6P and
application.
Then prioritizing 6P is not necessary.

*- Have you considered providing a recommended value for MAX_NUMCELLS or
discussing how to select it?*

TC: Maybe we will discuss it.

TC: Generally, to quick react the changes of traffic, a small size of
MAX_NUMCELLS is preferred, otherwise, a large value is preferred.
For more details, some investigation on this is required. A recommendation
value or discussion will come after that.

TC: I will fixed the other comments in the next version.

Tengfei



On Tue, Apr 9, 2019 at 1:06 PM Atis Elsts  wrote:

> Hello Tengfei and the 6tisch community,
>
> I'm happy to see the frame pending bit removed and other big improvements
> in clarity and functionality.
>
> Following up on my other previous comments,
> - There is still one reference left to the number 16 as the max number of
> channels (which 2.4 GHz frequency-band-specific). It's in the formula
> `channelOffset(MAC) = hash(EUI64, 16)`. This may conflict with the
> intention expressed previously in the text, where you say that "the
> coordinates are computed to distribute the cells across all channel
> offsets" (i.e. not exactly 16 channel offsets)
> - Have you considered suggesting that the implementers to prioritize 6top
> packets over data packets?
> - Have you considered providing a recommended value for MAX_NUMCELLS or
> discussing how to select it?
>
> Minor new comments:
>
> - The parameter KA_PERIOD from the recommended values is not referenced in
> the main text.
>
> - There are a number of typos in the text, for example:
>  Boradcast -> Broadcast
>  maxmium -> maximum
>  calcualted -> calculated
>  bewteen -> between
>
> Best regards,
> Atis
>
>
>
> On Tue, Apr 9, 2019 at 7:06 AM Tengfei Chang 
> wrote:
>
>> Dear all,
>>
>> A new version of "draft-ietf-6tisch-msf" is just published at here:
>> https://www.ietf.org/id/draft-ietf-6tisch-msf-03.txt
>>
>> This version mainly resolved the issues presented during IETF 104 meeting.
>> I would like to mention one of the main changes in this version is we
>> removed the frame pending bit feature.
>>
>> It's for two reasons:
>> - it will influence the "adapt to traffic" strategy of MSF.
>> - the "adapt to traffic" strategy has the ability to handle burst traffic
>> by using a smaller MAX_NUMCELLS
>>
>> Now we are calling for reviews on the new version of MSF!
>> Any comments and feedback are appreciated!
>>
>> Tengfei
>>
>>
>>
>> --
>> Chang Tengfei,
>> Postdoctoral Research Engineer, Inria
>> ___
>> 6tisch mailing list
>> 6tisch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tisch
>>
>
> --
> Dr. Atis Elsts
> Researcher, Institute of Electronics and Computer Science (EDI)
> Dzerbenes str. 14, Riga, LV-1006
>
>


-- 
Chang Tengfei,
Postdoctoral Research Engineer, Inria
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] [Call for Review] draft-ietf-6tisch-msf-03

[Tengfei Chang]

( I accidentally sending the email before finishing) the reply continues
inline...

On Wed, Apr 17, 2019 at 1:57 PM Tengfei Chang 
wrote:

> Hi Fabrice,
>
> Thanks a lot for your detailed comments! I will reply them inline below.
>
> On Tue, Apr 9, 2019 at 11:39 AM Fabrice Theoleyre 
> wrote:
>
>> Dear Tengfei,
>>
>> Please find below my review of the draft. I isolated the corresponding
>> blocks, and inserted my comments after 'FT>'
>>
>> The draft is very well written, and I have mostly minor comments.
>> Great job!
>>
>> Best regards,
>> Fabrice
>>
>>
>> 
>>
>>
>> an implementor MAY implements MSF
>>
>> FT> an implementor MAY implement MSF
>>
>> FT> I’m also a little bit confused. The section describes how to use the
>> shared
>> FT>  cell of Minimal 6TISCH. If Minimal 6TISCH is not used, how does the
>> FT> scheme work? Shouldn’t some minimum requirements be FT given here?
>>
>
TC: The minimum requirements will be that the the joining nodes are able to
find a way to listen the EB/DIO from neighbors.
It could be implemented in someway that not only sent on minimal cell.

TC: However, consider your comments further below that the minimal security
is a MUST for MSF, and minimal security is based on minimal configuration,
we may need command the minimal configuration as well.

>
>> ———
>>
>> These cells are called  'autonomous cells', because they are maintained
>> autonomously
>> by each node.
>>
>> FT> I find the term ‘autonomous’ quite misleading, since manage cells are
>> FT> also negotiated autonomously (without any controller). I would rather
>> use
>> FT> something else like ‘pseudo-random’.
>> FT> or rename the 'managed cells' in ’negotiated cells’?
>>
>> TC:  yes, "negotiated cells" sounds good for me.
> TC: I will rephrase the sentence as :
>
TC: These cells are called  'autonomous cells', because they are maintained
autonomously
TC: by each node without negotiation through 6P.
TC: Cells scheduled through 6P transaction are called '  negotiated cells'.

> ———
>>
>> There are other optional parameters defined in SAX determines the
>> performance of SAX hash function.
>>
>> FT> Other optional parameters defined in SAX
>> FT>  determine the performance of SAX hash function.
>>
>> TC: Will be fixed in next version.

> ———
>>
>> The AutoUpCell with the most packets in the outgoing queue takes
>>   precedence.
>>
>> FT> does a node has several upstream cells? I would have thought
>> FT> that a single upstream cell exists (or you consider multiple parents?)
>>
>>  TC: no. only one parent is considered. Will change something like:
"AutoUpCell  takes precedence if its outgoing queue is non-empty."

> ———
>>
>> Autonomous Downstream Cell (AutoDownCell), one cell at a
>>   [slotOffset,channelOffset] computed as a hash of its own EUI64
>>   (detailed next).  Its cell options bits are assigned as TX=1,
>>   RX=1, SHARED=0.
>>
>> FT> I would have explained here the role of this cell (i.e. receiving
>> FT> control packets from any neighbor), and similarly  for the upstream
>> cell.
>> FT> I conjecture it may be quite hard for the reader to understand
>> FT> their purpose
>>
>> TC: The traffic on the autonomous cells are defined later in the section,
which explains what packets/frames are sent on those cells.
We could replace that explanation early in the section. For example, right
after the definition of the autonomous cell.

> ———
>>
>>  6P RELOCATE Request frames to the node's RPL routing child MUST be
>>   sent on AutoDownCell.
>>
>> FT> What about 6P RELOCATE request to the parent? Can only a parent
>> FT> relocate a cell with 6P?
>>
>> TC:  6P RELOCATE request to the parent will be sent on AutoUpCell. I
missed the RELOCATE 6P request. Will be fixed in next version.

> ———
>>
>> Join Response packets and 6P ADD/DELETE Response frames to the
>>   pledge or its RPL routing child MUST be sent on AutoDownCell.
>>
>> FT> does this mean that a cell MUST be inserted in the schedule
>> FT> for each child (or after the reception of a Join-req)? Or can
>> FT> a node send a packet through a cell not registered in its schedule?
>>
>
TC: no. There is only on AutoDownCell. The parent/JP can use the cell to
send to any of its chidren/pledge.

>
>> ———
>>
>>  A node implementing MSF MUST implement the 

Re: [6tisch] [Call for Review] draft-ietf-6tisch-msf-03

[Tengfei Chang]

r instance, a burst of
> FT> packets is dropped at the beginning (i.e. during convergence, with
> FT> many collisions). Then, everything is fine. The PDR will take a long
> time
> FT> to reflect the actual PDR. The cell may be RELOCATED erroneously.
> FT> (the collision may have been solved meanwhile by the conflicting link)
>
> FT> Is it something you considered?
>
> ———
> towards it preferred parent
>
> FT> towards its preferred parent
>
> ———
>
> is calcualted as
>((2^MAXBE)-1)*SLOTFRAME_LENGTH, where:
>
> FT>is calculated as
>
> ———
>
> MAXEB is the maxmium backoff exponent is used
>
> FT> MAXBE is the maximum backoff exponent used
> (3 errors)
>
> ———
>
>
>
>
>
> Le 9 avr. 2019 à 06:06, Tengfei Chang  a écrit :
>
> Dear all,
>
> A new version of "draft-ietf-6tisch-msf" is just published at here:
> https://www.ietf.org/id/draft-ietf-6tisch-msf-03.txt
>
> This version mainly resolved the issues presented during IETF 104 meeting..
> I would like to mention one of the main changes in this version is we
> removed the frame pending bit feature.
>
> It's for two reasons:
> - it will influence the "adapt to traffic" strategy of MSF.
> - the "adapt to traffic" strategy has the ability to handle burst traffic
> by using a smaller MAX_NUMCELLS
>
> Now we are calling for reviews on the new version of MSF!
> Any comments and feedback are appreciated!
>
> Tengfei
>
>
>
> --
> Chang Tengfei,
> Postdoctoral Research Engineer, Inria
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
>
>

-- 
Chang Tengfei,
Postdoctoral Research Engineer, Inria
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] [Call for Review] draft-ietf-6tisch-msf-03

[Tengfei Chang]

Dear all,

A new version of "draft-ietf-6tisch-msf" is just published at here:
https://www.ietf.org/id/draft-ietf-6tisch-msf-03.txt

This version mainly resolved the issues presented during IETF 104 meeting.
I would like to mention one of the main changes in this version is we
removed the frame pending bit feature.

It's for two reasons:
- it will influence the "adapt to traffic" strategy of MSF.
- the "adapt to traffic" strategy has the ability to handle burst traffic
by using a smaller MAX_NUMCELLS

Now we are calling for reviews on the new version of MSF!
Any comments and feedback are appreciated!

Tengfei



-- 
Chang Tengfei,
Postdoctoral Research Engineer, Inria
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] Review on draft-tiloca-6tisch-robust-scheduling-01

[Tengfei Chang]

Hello Authors,

I just reviewed the draft. It reads pretty good for me! I only found a tiny
typo error in Eq.1 where the 'c' is not defined actually, I believe you
mean 'chOff'.

Besides, I have two questions referring the usage of minimal cell.

1. What if the selective jamming applied on the minimal cell? Do you
consider to resolve this case?

2. The joining traffic is going on  minimal cell in slotframe 0. Do you
plan to use some strategy to regulate the traffic on minimal cell? I am
asking this because this is different from what MSF is doing, which send
joining packet over autonomous cell.

Tengfei

-- 
Chang Tengfei,
Pre-Postdoctoral Research Engineer, Inria
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Thomas' review of draft-ietf-6tisch-msf-02

[Tengfei Chang]

Thanks for the comments! Generally, all comments are taken.

I will  fix them in the next version!

Tengfei

On Mon, Mar 25, 2019 at 7:59 AM Thomas Watteyne 
wrote:

> Authors,
>
> Please find below my review of draft-ietf-6tisch-msf-02. It's a patch
> file to the txt version of the draft.
>
> You will find inline fixes of typos, and comments, which start at the new
> line with "TW>"
>
> Overall, the draft is in good shape. The recommendations I make are
> editorial. The biggest remark is that the draft mixes the terms "dedicated
> cells" and "managed cells". I also would like to see some text that
> describes the reasoning between "autonomous SHARED cells" and "autonomous
> non-SHARED cells". Also, because those terms are obscure, you could replace
> them throughout by "autonomous upstream cells" and  "autonomous
> downstream cells".
>
> Thomas
>
> =
>
> diff --git
> "a/C:\\Users\\twatteyn\\AppData\\Local\\Temp\\TortoiseGit\\draft-ietf-6tisch-msf-02-54bdb6a.000.txt"
> "b/C:\\Users\\twatteyn\\Desktop\\ietf\\draft-ietf-6tisch-msf-02.txt"
> index 89514c6...49e59bb 100644
> ---
> "a/C:\\Users\\twatteyn\\AppData\\Local\\Temp\\TortoiseGit\\draft-ietf-6tisch-msf-02-54bdb6a.000.txt"
> +++ "b/C:\\Users\\twatteyn\\Desktop\\ietf\\draft-ietf-6tisch-msf-02.txt"
> @@ -135,10 +135,9 @@ Internet-Draft  6TiSCH Minimal Scheduling Function
> (MSF)  March 2019
>
> The 6TiSCH Minimal Scheduling Function (MSF), defined in this
> specification, is a 6TiSCH Scheduling Function (SF).  The role of an
> -   SF is entirely defined in [RFC8480]: it complements [RFC8480] by
> +   SF is entirely defined in [RFC8480]. This specification complements
> [RFC8480] by
> providing the rules of when to add/delete cells in the communication
> -   schedule.  The SF defined in this document follows that definition,
> -   and satisfies all the requirements for an SF listed in Section 4.2 of
> +   schedule.  This specification satisfies all the requirements for an SF
> listed in Section 4.2 of
> [RFC8480].
>
> MSF builds on top of the following specifications: the Minimal IPv6
> @@ -153,11 +152,11 @@ Internet-Draft  6TiSCH Minimal Scheduling Function
> (MSF)  March 2019
> the 7 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 preferred routing
> -   parent, has scheduled one default managed unicast cell (defined in
> +   parent, and has scheduled one default managed unicast cell (defined in
> Section 5.1) to/from its preferred routing parent.  After the join
> process, the node can continuously add/delete/relocate cells, as
> described in Section 5.  It does so for 3 reasons: to match the link-
> -   layer resources to the traffic, to handle changing parent, to handle
> +   layer resources to the traffic, to handle changing parent, or to handle
> a schedule collision.
>
> MSF is designed to operate in a wide range of application domains.
> @@ -172,18 +171,19 @@ Internet-Draft  6TiSCH Minimal Scheduling Function
> (MSF)  March 2019
>
> the nodes to the root).  Appendix C contains a performance evaluation
> of MSF.
> +TW> I would remove this sentence, as Appexdix C might be removed
>
> This specification follows the recommended structure of an SF
> -   specification in Appendix A of [RFC8480], with the following
> +   specification, given in Appendix A of [RFC8480], with the following
> adaptations:
>
> -   o  We have reordered part of the sections, in particular to have the
> -  section on the node behavior at boot Section 4 appear early in
> +   o  We have reordered some sections, in particular to have the
> +  section on the node behavior at boot (Section 4) appear early in
>this specification.
> o  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, the
> -  performance of MSF Appendix C.
> +  configuration (Section 2), the use of the SIGNAL command (Section
> 6),
> +  the MSF constants (Section 14), the MSF statistics (Section 15),
> and the
> +  performance of MSF (Appendix C).
> o  This specification does not include an examples section.
>
>  2.  Interface to the Minimal 6TiSCH Configuration
> @@ -193,8 +193,9 @@ Internet-Draft  6TiSCH Minimal Scheduling Function
> (MSF)  March 2019
> shared cell providing minimal connectivity between the nodes in the
> network.  The MSF implementation provided in this specification is
> based on the implementation of the Minimal 6TiSCH Configuration.  An
> -   implementor with full-awareness of the Minimal 6TiSCH Configuration
> +   implementor with full awareness of the Minimal 6TiSCH Configuration
> implications MAY implement MSF without it.
> +TW> I don't understand the statement "with full 

[6tisch] OpenWSN project will be presented during Hackdemo Happy Hour!

[Tengfei Chang]

Hello all,

As the subject of email, for those who missed the IETF104 hackathon, you
have a chance to see a live demo of OpenWSN project at ROOM Chez Louis during
the Hackdemo Happy Hour.

Here is the link for the live demo:
https://openwsn-dashboard.eu-gb.mybluemix.net/ui/

Feel free to come to ask us questions!

Tengfei

-- 
Chang Tengfei,
Pre-Postdoctoral Research Engineer, Inria
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Comments on draft-ietf-6tisch-msf-02 - Re: draft-ietf-6tisch-msf-02.txt is published

[Tengfei Chang]

Hi Yatch,

Thanks for the following-up comments! I replied inline below.

On Thu, Mar 21, 2019 at 4:25 PM Yasuyuki Tanaka 
wrote:

> Thank you, Tengfei.
>
> Additional and following-up comments:
>
>
> [Section 5.1, what to do after timeout of a 6P transaction]
> https://tools.ietf.org/html/draft-ietf-6tisch-msf-02#section-5
>
> The draft does not say anything about how to handle timeout of a 6P
> transaction. I know, the initiator of the timed out transaction will
> resend a 6P request to the same peer ;-) But, it's better to mention
> that as well as the maximum number of retries if we have.
>
>
Comment accepted!


>
> [Section 9, 6P Timeout Value]
> https://tools.ietf.org/html/draft-ietf-6tisch-msf-02#section-9
>
> A couple of questions:
>
> - "C" includes the autonomous cell to the neighbor or it is the number
>of the managed cells?
> - How can the timeout value be calculated while PDR is not available?
>
>
I agree that those questions are not clear for the current version.
As the current version allows 6P to send on the autonomous SHARED cell
mentioned in the draft (MAY send on the Managed Cell as well, as mentioned
in the draft.), the PDR value is not realistic.
The calculation of TIMEOUT in the draft MAY not apply anymore.

Instead of a complex calculation, I propose to use a fixed value.
The value is the worst case to have a 6P response received on the
autonomous SAHRED cell after maxmium re-tries.
The worse case means each time when 6P response is failed to send out, it
back-off with the largest number of cells (autonomous SHARED cell).
Since there is only one autonomous SHARED cell each node, the node will
wait for the same number of slotframes.

The calculation is like:

for maxmium 3 retries:

backoff exponent start from 2 and increase each re-transmission

6P Timeout = slotframeDuration * (1 +  (2^2-1)+(2^3-1)+(2^4-1)  )


> [Section 4.5, Step 4 of the bootstrap process]
> https://tools.ietf.org/html/draft-ietf-6tisch-msf-02#section-4.5
>
> tengfei> I don't know whether there is a specification for how the
> tengfei> neighbor table should be managed. If no, I think PERSONALLY
> tengfei> it's better not keeping the address from pledge in neighbor
> tengfei> table.
>
> Although the actual way to manage neighbor information is
> implementation-dependent, the minimal security framework draft
> suggests to have separate memory for joined nodes and for pledges
> respectively:
>
>
> https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-09#section-6


I see. I am not sure using a neighbor cache is able to avoid the DoS attack.
My intuitive thinking is the neighbor cache still has a fixed size.
If an attacker sends multiple join requests with fake eui64 address in the
packet, it can still fill up the neighbor cache, which blocks other pledges
to join.

This maybe need to discuss with minimal security scope as well.


>
> Again, my comment on Section 4.5 is just that, I think we need some
> text in "Security Considerations" section for this operation described
> in Step 4. And, it seems the term of "the neighbor table" in the Step
> 4 is ambiguous. Some may think it's IPv6 neighbor cache, some may
> think L2 neighbor table.
>

I agree!


>
>
> [Appendix-B, SAX configuration]
>
> tengfei> This is a pre-configured (offline) for interoperability
> tengfei> purpose only.
>
> It's better to mention how a pledge gets the SAX parameters used in
> the network where it is trying to join. There are always two options:
>
> - pre-configured
> - advertised in EBs
>

Agreed.


>
> Best,
> Yatch
>


-- 
Chang Tengfei,
Pre-Postdoctoral Research Engineer, Inria
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Comments on draft-ietf-6tisch-msf-02 - Re: draft-ietf-6tisch-msf-02.txt is published

[Tengfei Chang]

Thanks a lot Yatch, for the comments!

I will answer your comments inline.

On Mon, Mar 18, 2019 at 3:50 PM Yasuyuki Tanaka 
wrote:

> Hi,
>
> Thank you, Tengfei and the other authors, for updating the draft!
>
> I'm sharing my comments on the latest version.
>
> https://tools.ietf.org/html/draft-ietf-6tisch-msf-02
>
> [Security Consideration on autonomous SHARED cell allocation]
>
> > 4.5.  Step 4 - Installing Autonomous Cells for each neighbor in neighbor
> >   table
> >
> >Because it has learnt the link-layer keying material used in the
> >network, the joined node can now decrypt any packets sent by its
> >neighbors.  Once a new neighbor is added to the neighbor table, a new
> >autonomous SHARED cell MUST be added to that neighbor.
>
> As per the second sentence in this section, a JP MUST allocate an
> autonomous SHARED cell to a pledge during its secure joining process.
>

For Step 4, the node already securely joined the network.
The neighbor referred to the neighbor who has already joined the network.
There is no action for pledge at this step.


>
> Tengfei's email says no action required on the JP side, but the JP
> need to have a neighbor table entry (neighbor cache entry) for the JP
> in order to send back a join response, doesn't it? I may miss
> something.
>

For security issue, the address of pledge will not be recorded in neighbor
table.
The JP will get the nexthop address from the layer 3 source address, hence
send back the join response.
I don't know whether there is a specification for how the neighbor table
should be managed.
If no, I think PERSONALLY it's better not keeping the address from pledge
in neighbor table.

>
> tengfei> [Resolved. During join process, only pledge required to
> tengfei> install autonomous SHARED cell to JP, no action required from
> tengfei> JP side.]
>
> If this is the case, I would propose to add some note in Security
> Considerations section where we mention risks of this kind allocation,
> and may suggest a mitigation technique such as "on-demand allocation".
>

There is no risks on cell allocation, right?
I assume the allocation here you are saying is about the neighbor table
entry allocation?


>
> Basically this is the same comment as the first one in the following
> email:
>
>
> https://mailarchive.ietf.org/arch/msg/6tisch/9jcaTddi6vLO5zHqTDNk6yqrNao
>
>
> [Join request packets can still increment NumCellUsed?]
>
> tengfei> non-trusted packet shouldn't be accounted for for adapting
> tengfei> traffic
> tengfei> 
> tengfei> Mention that the untrusted packet (e.g. join
> tengfei> request/response) shouldn't be counted for adapting the
> tengfei> traffic.  Issues link:
> tengfei> https://github.com/twatteyne/draft-ietf-6tisch-msf/issues/15
> tengfei>
> tengfei> [Resolved. clarified in adapting traffic section.]
>
> I think this issue hasn't been resolved yet by the latest draft. I
> expect text describing how to handle packets having code point AF42 or
> AF43.
>

Yes, I was just thinking the join request/response between JP and pledge
since they are only sent on autonomous cell which won't effect the traffic
adaptation.
But it does between JP and JRC. I will state that. But I have a question
maybe something I haven't followed before, how the node who already joined
the network knowing the packet it forwarded is a join request/response?


>
>
> https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-09#section-6.1
>
>
> [EB / DIO transmission rules]
>
> I would propose to remove the third and fourth paragraphs mainly for
> these two reasons:
>
> - This is an implementation-specific optimization
> - This is irrevalnt to the scheduling function itself
>
> > 2.  Interface to the Minimal 6TiSCH Configuration
> >
> > (snip)
> >
> >Because the minimal cell is SHARED, the back-off algorithm defined in
> >[IEEE802154-2015] is used to resolve collisions. To ensure there is
> >enough bandwidth available on the minimal cell, a node implementing
> >MSF SHOULD enforce the following rules for broadcast frames:
> >
> >1.  send EBs on a portion of the minimal cells not exceeding
> >1/(3(N+1)), where N is the number of neighbors of the node.
> >2.  send any other broadcast packets on a portion of the minimal
> >cells not exceeding 1/(3(N+1)), where N is the number of
> >neighbors of the node.  For example, the broadcast DIO and DIS,
> >IPv6 Neighbor Discovery (ND)[RFC4861] and any other application
> >layer broadcast packets.
> >
> >The RECOMMENDED behavior for sending EBs is to have a node send EBs
> >with a probability of 1/(3(N+1)).  The RECOMMENDED behavior for
> >sending DIOs is to use a Trickle timer with rate-limiting.  There is
> >no recommendation behavior for sending any other broadcast.  However,
> >the traffic portion of all broadcast packets on minimal cell, except
> >EBs, MUST not exceed 1/(3(N+1)).
>
> Here is Xavi's com

[6tisch] draft-ietf-6tisch-msf-02.txt is published

[Tengfei Chang]

Dear all,

draft-ietf-6tisch-msf-02.txt  is just published.

The main changes made in this version are

   - Resolve the issues in Pending Elements section.
   - Using autonomous SHARED and non-SHARED cells.
   - Overall revised the specification.

Additional information about how the issues in the pending elecments
section are resolved is written below.  (issues are separated by "=")

Any reviews or comments are welcome!

Tengfei


Security issue on autonomous cell installation


The autonomous cell to the pledge is installed on the join proxy before the
pledge is authorized, which is a security issue. Related discussion: ttps://
mailarchive.ietf.org/arch/msg/6tisch/9jcaTddi6vLO5zHqTDNk6yqrNao

[Resolved. During join process, only pledge required to install autonomous
SHARED cell to JP, no action required from JP side.]


Handling the case when bandwidth allocation exceeds available capacity


When node A initializes a 6top ADD transaction to node B, but node B does
NOT have enough bandwidth to allocate.
What can node B do to indicate this case in its 6top response, and how
should node A handle the packet after receiving the response?
Related discussion:
https://www.ietf.org/mail-archive/web/6tisch/current/msg06095.html

[ToDo. According to 6top RFC8480, SUCCESS return code will be in the 6top
response with an empty cellList possibly. For this case, I don't have a
prefect solution. One solution I am using is marking the node B as
'no_resource', then updating it's routing table and filtering out the
neighbor marked as 'no_resource'. However, this is a layer-violation
design.]


joining traffic MUST be sent in minimal cell


Joining traffic MUST be sent in minimal cell.
Issues link: https://github.com/twatteyne/draft-ietf-6tisch-msf/issues/11

 [Resolved. Joining traffic will be sent on autonomous cell.]


NumCellsElapsed  shouldn't update on shared dedicated cell

NumCellsElapsed  is used to track under/overuse of cells.
If we are backing off, i.e. skipping cells, should those skipped cells
count towards NumCellsElapsed ?
Issues link:
https://github.com/twatteyne/draft-ietf-6tisch-msf/issues/13

[Resolved. The counters are only applied on managed unicast cell.]


non-trusted packet shouldn't be accounted for for adapting traffic

Mention that the untrusted packet (e.g. join request/response)
shouldn't be counted for adapting the traffic.
Issues link:
https://github.com/twatteyne/draft-ietf-6tisch-msf/issues/15

[Resolved. clarified in adapting traffic section.]


Customize the backoff exponent on dedicated shared cell.

Use small backoff exponent on dedicated cell since it's only shared by
two nodes.
Discussion: do we still have this case with the merger of ASF?
Issues link:
https://github.com/twatteyne/draft-ietf-6tisch-msf/issues/17
[NotApplied. After ASF is merged, the dedicated shared cell is not used
anymore. The autonomous SHARED cell is shared among a set of neighbors
hence no need to customize the backoff exponent.]


Adapting 6P Timeout

After 6P TIMEOUT, the next 6P transaction should be configured using a
larger TIMEOUT.
Issues link:
https://github.com/twatteyne/draft-ietf-6tisch-msf/issues/19

[ToDo. I am not sure this is an issue or not with current version. Need
to discuss with Malisa and Simon.]


Timeout calculation is wrong

The 6P Timeout is calculated as :
list style: symbols

(1/(C+1))*(1/PDR)*SIXP_TIMEOUT_SEC_FACTOR

It should be
list style: symbols

(1/(C+1))*(1/PDR)*SIXP_TIMEOUT_SEC_FACTOR


according to the paper: https://arxiv.org/pdf/1507.05810.pdf
Related link is at:
https://github.com/twatteyne/draft-ietf-6tisch-msf/issues/22

[Resolved. The comments are taken and applied in the text.]


Separate Cell Counters for TX and RX

NumCellsUsed and NumCellsElapsed counter should be separated between TX
and RX.
Question: still applies?
Related Link is at:
https://github.com/twatteyne/draft-ietf-6tisch-msf/issues/20

[Resolved. The comments are taken and applied in the text.]


Two slotframes

Why are they two slotframes in same length?
Issues link:
https://github.com/twatteyne/draft-ietf-6tisch-msf/issues/25

[Resolved. The length of two slotframes are SHOULD be the same, instead
of MUST.]


Parameters for SAX is missing

It'd be nice to have an example or a test vector in the draft in order
to validate a SAX implementation used for MSF.
This is critical for interoperability.
Related discussion:
https://mailarchive.ietf.org/arch/msg/6tisch/9jcaTddi6vLO5zHqTDNk6yqrNao

[Resolved. An appredix of how to implement the sax is added.]


Wrong end state statement

In Section 1, one of the end states of the join process i

[6tisch] OpenWSN project will be presented during the hackathon!

[Tengfei Chang]

Dear all,

We am happy to announce that OpenWSN project is going to present during the
hackathon!

We are targeting to show:

   - OpenTestbed: a simple but elegant  Testbed
   - A 40 nodes 6TiSCH network running over OpenTestbed with OpenWSN
   implementation
   - An OpenBenchmark platform demonstrates the performance of the 6TiSCH
   network

Very much welcome to come by and see what we are doing!

Tengfei & Malisa

-- 
Chang Tengfei,
Pre-Postdoctoral Research Engineer, Inria
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] [MSF] Suggestion from simulation and experiment result

[Tengfei Chang]

All,

The following are the suggestions and recommendations we mentioned during
the 6tisch meeting yesterday. Those points will be addressed and pushed to
the new version draft-ietf-6tisch-msf-02


   - The  NumCellsUsed is no incremented during backoff wait delay for TSCH
   retransmission algorithm. (suggestion: only apply adaptive traffic
   algorithm on non-shared cell)
   - Some usage about Frame Pending bit is under specified, the usage of
   pending bit in MSF will be updated once it's specified.
   - Only reserve autonomous cell on demand, for each node
  - Reserve one TxRx shared  autonomous cell to parent/JP (unicast
  cell)
  - Reserve one TxRx non shared autonomous cell (anycast)
  - Reserve at least one managed Tx cell  (reserved by Sixtop) aside
   with autonomous cell, and upstream application traffic only goes on managed
   Tx cells
   - EB can be sent when the node has a parent, DIO should be sent after
   when one managed Tx cell is installed to the parent

Regards,
Tengfei

-- 
Chang Tengfei,
Postdoctoral Research Engineer, Inria
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Protocol Action: '6TiSCH Operation Sublayer Protocol (6P)' to Proposed Standard (draft-ietf-6tisch-6top-protocol-12.txt)

[Tengfei Chang]

This is great news! Congrats!

On Mon, Aug 20, 2018 at 4:41 PM Qin Wang  wrote:

> Great!
>
> On Thursday, August 16, 2018, 9:38:13 AM EDT, The IESG <
> iesg-secret...@ietf.org> wrote:
>
>
> The IESG has approved the following document:
> - '6TiSCH Operation Sublayer Protocol (6P)'
>   (draft-ietf-6tisch-6top-protocol-12.txt) as Proposed Standard
>
> This document is the product of the IPv6 over the TSCH mode of IEEE
> 802.15.4e
> Working Group.
>
> The IESG contact persons are Suresh Krishnan and Terry Manderson.
>
> A URL of this Internet Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-6tisch-6top-protocol/
>
>
>
>
>
> Technical Summary
>
>   This document defines the 6top Protocol (6P), which enables
>   distributed scheduling in 6TiSCH networks.  6P allows neighbor nodes
>   to add/delete TSCH cells to one another.  6P is part of the 6TiSCH
>   Operation Sublayer (6top), the next higher layer to the IEEE Std
>   802.15.4 TSCH medium access control layer.  The 6P layer is formed by
>   the 6top Protocol defined in this document and 6top Scheduling
>   Function(s).  A 6top Scheduling Function (SF) decides when to add/
>   delete cells, and triggers 6P Transactions.  This document lists the
>   requirements for an SF, but leaves the definition of SFs out of
>   scope.
>
> Working Group Summary
>
>
> This document was not controversial. The design was complex due to the
> need to save exchanges and yet provide transactional outcomes.
> The next generation of the work may be done at IEEE, e.g. within IEEE Std.
> 802.12
>
> Document Quality
>
> This specification was implemented in openWSN and contiki.
> It was interop tested at the 6TiSCH F-interop in Prague:
> http://www.etsi.org/news-events/events/1197-6tisch-interop-prague-2017
> 
> Return from experimentation is implemented in the draft
>
> Personnel
>
> Pascal Thubert is the Document Shepherd. Suresh Krishnan is the
> Responsible Area Director.
>
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>


-- 
Chang Tengfei,
Postdoctoral Research Engineer, Inria
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Comments on draft-ietf-6tisch-minimal-security-06

[Tengfei Chang]

Hi Malisa and Tero,

Thanks for answering my question! It is clear to me!

I don't fully understand. Do you mean in which case would a node send
> another Join Request, if it has already completed the join process sometime
> before and obtained the L2 encryption keys?
>

My question is exactly what you rephrased :-)

Tengfei


On Tue, Jul 17, 2018 at 1:24 PM, Tero Kivinen  wrote:

> Mališa Vučinić writes:
> > Hence I have two questions:
> > 1. in what case JRC or some entity will send such packet?
> >
> > For example if a JRC detects that some node in the network
> > misbehaves, generates large amount of traffic, is misconfigured or
> > similar. The JRC would then simply need to rekey the network,
> > providing the new key to every node except the one that it wants to
> > see expelled.
> >
> > Then, Tero on another thread also mentioned a couple of cases where
> > this is necessary, e.g. if JRC restarts.
>
> If JRC restarts and looses track who is in the network, then it cannot
> send updaes, as it does not know who is in the network. I.e., in that
> case all nodes need to rejoin.
>
> On the other hand if JRC wants to clean up some address space, for
> example if it has given out lots of short address without expirity
> time, and then it cannot take those address back to use ever even if
> the node has already been silent for few weeks. In that case if it
> does the rekey of the network then after the old keys are no longer in
> use anywhere it can start reusing the short addresses for those nodes,
> it did not send key update for.
>
> It cannot use the fact that node did not ack the key update sent to it
> to indicate that node has gone from the network, as it is possible
> that the ack got lost, even when the key update actually reached the
> node. So it needs to have list of nodes it will send key updates, and
> those it does not send it, are something it can remove from the
> address pool after the key update.
> --
> kivi...@iki.fi
>



-- 
Chang Tengfei,
Postdoctoral Research Engineer, Inria
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] Comments on draft-ietf-6tisch-minimal-security-06

[Tengfei Chang]

Hi Malisa,

I just reviewed the draft and have several comments below.

*Comment 1: *
*--*
In section 9.3.2 when describing link-layer key set:

*When 6LBR receives this*
*parameter, it MUST remove any old keys it has installed from the*
*previous key set and immediately install and start using the new*
*keys for all outgoing and incoming traffic. When a non-6LBR node*
*receives this parameter, it MUST install the keys, use them for*
*any incoming traffic matching the key identifier, but keep using*
*the old keys for all outgoing traffic. A non-6LBR node accepts*
*any frames for which it has keys: both old and new keys. Upon*
*reception and successful security processing of a link-layer frame*
*secured with a key from the new key set, a non-6LBR node MUST*
*remove any old keys it has installed from the previous key set.*
*From that moment on, a non-6LBR node MUST use the keys from the*
*new key set for all outgoing traffic.*

I understand this is for the case when a packet containing the* link-layer
key set parameter* is received, how the node should handle it. This sounds
to me like there is a proactive packet from JRC requesting to update the
key settings. Hence I have two questions:
1. in what case JRC or some entity will send such packet?
2. if the parameter is from a Join response corresponding to a Join request
sent by the node before, (this implied by Table 2: Join Response map
labels), then what's the reason a node needs to send Join request if it
already has key configured (not the PSK).

Maybe this is just for me that I don't understand the background of this
paragraph. But I just ask in case not.

*Comment 2:*
*--*
Another comment, you talked before, is the required parameters for the 6LBR
pledge.
Table 2 listed the parameters in the configuration object. It's generally
for non-6LBR pledge.
I made a pre-list for those parameters that required by 6LBR pledge. They
are from the information that EB should carry.

1. time slot template
2. channel hopping template
3. number of slotframes

   - slotframe handler
   - slotframe length
  - number of links
  - link information (slotoffset, channeloffset, type)

Is there anything else we should also add?

Tengfei


-- 
Chang Tengfei,
Postdoctoral Research Engineer, Inria
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] Fwd: New Version Notification for draft-chang-6tisch-msf-02.txt

[Tengfei Chang]

-- Forwarded message --
From: 
Date: Mon, Jul 2, 2018 at 6:37 PM
Subject: New Version Notification for draft-chang-6tisch-msf-02.txt
To: Malisa Vucinic , Simon Duquennoy ,
Xavier Vilajosana , Diego Dujovne <
diego.dujo...@mail.udp.cl>, Tengfei Chang 



A new version of I-D, draft-chang-6tisch-msf-02.txt
has been successfully submitted by Tengfei Chang and posted to the
IETF repository.

Name:   draft-chang-6tisch-msf
Revision:   02
Title:  6TiSCH Minimal Scheduling Function (MSF)
Document date:  2018-07-02
Group:  6tisch
Pages:  19
URL:https://www.ietf.org/internet-drafts/draft-chang-6tisch-msf-
02.txt
Status: https://datatracker.ietf.org/doc/draft-chang-6tisch-msf/
Htmlized:   https://tools.ietf.org/html/draft-chang-6tisch-msf-02
Htmlized:   https://datatracker.ietf.org/doc/html/draft-chang-6tisch-msf
Diff:   https://www.ietf.org/rfcdiff?url2=draft-chang-6tisch-msf-02

Abstract:
   This specification defines the 6TiSCH Minimal Scheduling Function
   (MSF).  This Scheduling Function describes both the behavior of a
   node when joining the network, and how the communication schedule is
   managed in a distributed fashion.  MSF builds upon the 6TiSCH
   Operation Sublayer Protocol (6P) and the Minimal Security Framework
   for 6TiSCH.





Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




-- 
Chang Tengfei,
Postdoctoral Research Engineer, Inria
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Question/Comment on draft-chang-6tisch-6top-msf

[Tengfei Chang]

Hi John,

Before switching parent, the node still can keep synchronized to it's old
parent through the TXRXSHARED cell. That cell is only shared between the
node and its parent.
The keepalive on TXRXSHARED cell should be able to keep the node
synchronized.

Tengfei

On Wed, Nov 15, 2017 at 12:34 AM, john rubis  wrote:

> I think the MSF draft states/infers this, but I wanted to verify.
>
>
>
> In the case a node has a valid preferred parent and wishes to switch to a
> new one then:
>
>
>
> Dedicated link(s) to its current parent initially remain in place. This
> way, while dedicated link(s) are being setup with the new, I’ll call it the
> ‘Candidate Parent’, the node and its possible children remain connected and
> reachable. During this period, the node also maintains its rank and time
> synchronization to the current parent, not the candidate parent. Once
> dedicated link(s) are established to the new parent, the node updates its
> rank and time syncs to the new parent. All up stream packets now are routed
> through the new parent and link(s) to the old parent are cleared.
>
>
>
> It has been observed in our system,  that the links to the new parent can
> take some time to setup over the single minimal cell. Especially in dense
> networks. This may cause a node to desync or loose connectivity for an
> extended period of time.
>
>
>
> Thank  you,
>
>
>
> John Rubis
>
>
>
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
>


-- 
Chang Tengfei,
Pre-Postdoctoral Research Engineer, Inria
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Questions on draft-chang-6tisch-6top-msf

[Tengfei Chang]

Hi Esteban,

I replied inline :-)

On Mon, Nov 13, 2017 at 8:19 PM, Esteban Municio <
esteban.muni...@uantwerpen.be> wrote:

> Hi,
>
> After reading the draft I have some small comments.
>
> When requesting the first 6P ADD, the CellsOptions are TX=1,RX=1,SHARED=1
> which means that the cell is bidirectional.
> Is there any way to prevent that future EBs and DIOs are sent in this
> shared cell? Or the implementation ensures that they will only be sent in
> ts=0,ch=0?
>

*In this case the implementation will ensure that but through the neighbor
associated to the cell. For the reserved cell, it associated to its
parent/child address. Only a packet send to/received from parent/child are
allow to send on the cell.*


> When allocating/deallocating cells due to parent switching, is this
> initial bidirectional cell allocated with the same CellsOptions in the new
> parent as well?
>

*The 6P transaction for allocation to new parent will happen on the minimal
cell. After new cells are reserved to new parent, the 6P transaction for
deallocation to the old parent will happen on the previous installed cell
to the old parent. After this process, there will be no cell to it's old
parent.*


> Then if I understand well the node should always have at least one cell
> with TX=1,RX=1,SHARED=1 with its preferred parent
>

*Correct!*


> and has to "re-allocate" it parallely
> in a different 6P message than the used for the dedicated cells with
> TX=1,RX=0,SHARED=0. Am I right?
>

*The cell managed by MSF are all TX=1 RX=1 and SHARED=1 type of cell but
associated to a dedicated neighbor. (It's a dedicated cell since it only
send/received packet from a dedicated address)*


>
> When the nodes start sending DAOs? If it is at Step 6, it could be
> interesting mention it there.
> Are the DAOs allowed to be sent in the minimal cell?
>

*No, the DAO is send through the scheduled dedicated cell.  Hence even a
node get a RANK through the DIOs it received, it can't send any packet
except 6P until it has a dedicated cell installed.*
*The DAOs and all other packets should be sent after a node reach to the **End
State.*

>
> And maybe a bit off-topic,
> Is it possible for a node to have TX cells to neighbours that are not
> currently its preferent parent?
>

*For MSF, the node only schedule the TX|RX|SHARED cell to preferent parent.
The TX cell or schedule non-preferent parent are out of scope of MSF.*
*It could be another SF though.*


>
> Kind regards,
> Esteban
>

*Let me know if you have any future issue or suggestion on MSF. Thank you
for asking! They are good questions. I hope I answered clearly!*

*Tengfei*

> --
>
> Esteban Municio
>
> IDLab - Dept. Mathematics and Computer Science
>
> University of Antwerp - imec
>
> Middelheimlaan 1 , 2020 Antwerp, Belgium
>
> Office M.G.322
>
>
>
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
>


-- 
Chang Tengfei,
Pre-Postdoctoral Research Engineer, Inria
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Agenda, 6TiSCH WG interim, November 3rd, 2017

[Tengfei Chang]

All,

Here is the msf draft which has been submitted at here:
https://datatracker.ietf.org/doc/draft-chang-6tisch-msf/

Tengfei

On Tue, Oct 31, 2017 at 1:17 PM, Tengfei Chang 
wrote:

> Diego, All,
>
> Because of my mistake, I failed to submit this draft before the deadline.
> We are waiting for the message from the administration to see if it's
> possible to submit it.
> I will keep you all update.
>
> My apologies for the mistake!
>
> Tengfei
>
> On Tue, Oct 31, 2017 at 12:10 PM, Prof. Diego Dujovne <
> diego.dujo...@mail.udp.cl> wrote:
>
>> Dear all,
>>  I cannot find the text for:
>>
>> draft-chang-6tisch-6top-msf
>>
>> Can you provide a link?
>> Thank you.
>> Regards,
>>
>>   Diego
>>
>> 2017-10-31 6:35 GMT-03:00 Pascal Thubert (pthubert) :
>>
>>> Dear all :
>>>
>>>
>>>
>>> *Note: Due to EU going CET this WE, this meeting is at 3PM CET!*
>>>
>>> We placed a draft agenda on the IETF tools site
>>>
>>> https://datatracker.ietf.org/doc/agenda-interim-2017-6tisch-
>>> 17-6tisch-01/
>>>
>>> At the time of the posting it reads as follows; please let us know if we
>>> need to consider changing anything before next Monday.
>>>
>>>
>>>
>>> The chairs.
>>>
>>>
>>> Connection details
>>> --
>>>
>>> * Date: 3 November 2017  7-8am Pacific
>>> http://www.worldtimebuddy.com/?qm=1&lid=100,12,5392171,18501
>>> 47&h=100&date=2017-11-03&sln=14-15
>>> * Webex Meeting:
>>> https://cisco.webex.com/ciscosales/j.php?MTID=m829e5143deab3
>>> 957a95b6cdb44fff299
>>> * Meeting number (access code): 208 468 097
>>> * Meeting password: B2FVVAkM (22388256 from phones)
>>> * Material link:
>>> https://bitbucket.org/6tisch/meetings/raw/master/170908_webe
>>> x/slides_170908_webex.ppt
>>>
>>> Agenda
>>> --
>>>
>>> * Note-Well, Blue Sheets, Scribes, Agenda Bashing   [ 5min]
>>>
>>> * Status of the work[ 5min]
>>>
>>> * IETF 100 prep   (chairs)  [15min]
>>>
>>> * draft-ietf-6tisch-minimal-security (Malisa Vucinic)   [15min]
>>>
>>> * draft-chang-6tisch-6top-msf   (Tengfei Chang) [20min]
>>>
>>> * Any Other Business, IEEE status[QS]
>>>
>>>
>>>
>>> ___
>>> 6tisch mailing list
>>> 6tisch@ietf.org
>>> https://www.ietf.org/mailman/listinfo/6tisch
>>>
>>>
>>
>>
>> --
>> DIEGO DUJOVNE
>> Profesor Asociado
>> Escuela de Informática y Telecomunicaciones
>> Facultad de Ingeniería - Universidad Diego Portales - Chile
>> www.ingenieria.udp.cl
>> (56 2) 676 8125
>>
>> ___
>> 6tisch mailing list
>> 6tisch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tisch
>>
>>
>
>
> --
> Chang Tengfei,
> Pre-Postdoctoral Research Engineer, Inria
>



-- 
Chang Tengfei,
Pre-Postdoctoral Research Engineer, Inria
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Agenda, 6TiSCH WG interim, November 3rd, 2017

[Tengfei Chang]

Hi,

The attached is the txt format for the draft-ietf-6tisch-6top-msf-00. You
can refer to this attachment for now.

Tengfei

On Tue, Oct 31, 2017 at 1:33 PM, Pascal Thubert (pthubert) <
pthub...@cisco.com> wrote:

> Hello Tengfei :
>
>
>
> For those interested, would you have another link in the meantime (e.g. a
> WIP in bitbucket) ?
>
>
>
> Thanks in advance
>
>
>
> Pascal
>
>
>
> *From:* Tengfei Chang [mailto:tengfei.ch...@inria.fr]
> *Sent:* mardi 31 octobre 2017 13:17
> *To:* Prof. Diego Dujovne 
> *Cc:* Pascal Thubert (pthubert) ; 6tisch@ietf.org
> *Subject:* Re: [6tisch] Agenda, 6TiSCH WG interim, November 3rd, 2017
>
>
>
> Diego, All,
>
>
>
> Because of my mistake, I failed to submit this draft before the deadline.
> We are waiting for the message from the administration to see if it's
> possible to submit it.
>
> I will keep you all update.
>
>
>
> My apologies for the mistake!
>
>
>
> Tengfei
>
>
>
> On Tue, Oct 31, 2017 at 12:10 PM, Prof. Diego Dujovne <
> diego.dujo...@mail.udp.cl> wrote:
>
> Dear all,
>
>  I cannot find the text for:
>
>
>
> draft-chang-6tisch-6top-msf
>
>
>
> Can you provide a link?
>
> Thank you.
>
> Regards,
>
>
>
>   Diego
>
>
>
> 2017-10-31 6:35 GMT-03:00 Pascal Thubert (pthubert) :
>
> Dear all :
>
>
>
> *Note: Due to EU going CET this WE, this meeting is at 3PM CET!*
>
> We placed a draft agenda on the IETF tools site
>
> https://datatracker.ietf.org/doc/agenda-interim-2017-6tisch-17-6tisch-01/
>
> At the time of the posting it reads as follows; please let us know if we
> need to consider changing anything before next Monday.
>
>
>
> The chairs.
>
>
> Connection details
> --
>
> * Date: 3 November 2017  7-8am Pacific
> http://www.worldtimebuddy.com/?qm=1&lid=100,12,5392171,
> 1850147&h=100&date=2017-11-03&sln=14-15
> * Webex Meeting:
> https://cisco.webex.com/ciscosales/j.php?MTID=
> m829e5143deab3957a95b6cdb44fff299
> * Meeting number (access code): 208 468 097
> * Meeting password: B2FVVAkM (22388256 from phones)
> * Material link:
> https://bitbucket.org/6tisch/meetings/raw/master/170908_
> webex/slides_170908_webex.ppt
>
> Agenda
> --
>
> * Note-Well, Blue Sheets, Scribes, Agenda Bashing   [ 5min]
>
> * Status of the work[ 5min]
>
> * IETF 100 prep   (chairs)  [15min]
>
> * draft-ietf-6tisch-minimal-security (Malisa Vucinic)   [15min]
>
> * draft-chang-6tisch-6top-msf   (Tengfei Chang) [20min]
>
> * Any Other Business, IEEE status[QS]
>
>
>
>
>
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
>
>
>
>
> --
>
> DIEGO DUJOVNE
> Profesor Asociado
> Escuela de Informática y Telecomunicaciones
> Facultad de Ingeniería - Universidad Diego Portales - Chile
> www.ingenieria.udp.cl
> (56 2) 676 8125
>
>
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
>
>
>
>
> --
>
> Chang Tengfei,
>
> Pre-Postdoctoral Research Engineer, Inria
>
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
>


-- 
Chang Tengfei,
Pre-Postdoctoral Research Engineer, Inria




6TiSCH T. Chang, Ed.
Internet-Draft Inria
Intended status: Standards Track  M. Vucinic
Expires: April 30, 2018 University of Montenegro
   X. Vilajosana
 Universitat Oberta de Catalunya
October 27, 2017


6TiSCH Minimal Scheduling Function (MSF)
   draft-ietf-6tisch-6top-msf

Abstract

   This specification defines the 6TiSCH Minimal Scheduling Function
   (MSF).  This Scheduling Function describes both the behavior of a
   node when joining the network, and how the communication schedule is
   managed in a distributed fashion.  MSF builds upon the 6top Protocol
   (6P) and the Minimal Security Framework for 6TiSCH.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL&

Re: [6tisch] Agenda, 6TiSCH WG interim, November 3rd, 2017

[Tengfei Chang]

Diego, All,

Because of my mistake, I failed to submit this draft before the deadline.
We are waiting for the message from the administration to see if it's
possible to submit it.
I will keep you all update.

My apologies for the mistake!

Tengfei

On Tue, Oct 31, 2017 at 12:10 PM, Prof. Diego Dujovne <
diego.dujo...@mail.udp.cl> wrote:

> Dear all,
>  I cannot find the text for:
>
> draft-chang-6tisch-6top-msf
>
> Can you provide a link?
> Thank you.
> Regards,
>
>   Diego
>
> 2017-10-31 6:35 GMT-03:00 Pascal Thubert (pthubert) :
>
>> Dear all :
>>
>>
>>
>> *Note: Due to EU going CET this WE, this meeting is at 3PM CET!*
>>
>> We placed a draft agenda on the IETF tools site
>>
>> https://datatracker.ietf.org/doc/agenda-interim-2017-6tisch-17-6tisch-01/
>>
>> At the time of the posting it reads as follows; please let us know if we
>> need to consider changing anything before next Monday.
>>
>>
>>
>> The chairs.
>>
>>
>> Connection details
>> --
>>
>> * Date: 3 November 2017  7-8am Pacific
>> http://www.worldtimebuddy.com/?qm=1&lid=100,12,5392171,18501
>> 47&h=100&date=2017-11-03&sln=14-15
>> * Webex Meeting:
>> https://cisco.webex.com/ciscosales/j.php?MTID=m829e5143deab3
>> 957a95b6cdb44fff299
>> * Meeting number (access code): 208 468 097
>> * Meeting password: B2FVVAkM (22388256 from phones)
>> * Material link:
>> https://bitbucket.org/6tisch/meetings/raw/master/170908_webe
>> x/slides_170908_webex.ppt
>>
>> Agenda
>> --
>>
>> * Note-Well, Blue Sheets, Scribes, Agenda Bashing   [ 5min]
>>
>> * Status of the work[ 5min]
>>
>> * IETF 100 prep   (chairs)  [15min]
>>
>> * draft-ietf-6tisch-minimal-security (Malisa Vucinic)   [15min]
>>
>> * draft-chang-6tisch-6top-msf   (Tengfei Chang) [20min]
>>
>> * Any Other Business, IEEE status[QS]
>>
>>
>>
>> ___
>> 6tisch mailing list
>> 6tisch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tisch
>>
>>
>
>
> --
> DIEGO DUJOVNE
> Profesor Asociado
> Escuela de Informática y Telecomunicaciones
> Facultad de Ingeniería - Universidad Diego Portales - Chile
> www.ingenieria.udp.cl
> (56 2) 676 8125
>
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
>


-- 
Chang Tengfei,
Pre-Postdoctoral Research Engineer, Inria
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] new command for 6P

[Tengfei Chang]

I like the idea!

On Wed, Jul 19, 2017 at 9:03 PM, Pascal Thubert (pthubert) <
pthub...@cisco.com> wrote:

> Makes sense to me J
>
>
>
> *From:* 6tisch [mailto:6tisch-boun...@ietf.org] *On Behalf Of *Xavi
> Vilajosana Guillen
> *Sent:* mercredi 19 juillet 2017 19:23
> *To:* tisch <6tisch@ietf.org>
> *Subject:* [6tisch] new command for 6P
>
>
>
> Dear all,
>
>
>
> I would like to propose a new command to be used to the 6P Protocol. The
> command may be used to configure SF or exchange information between the SF
> of the communicating nodes. The command can be named SIGNAL and 6P will not
> define the content but only the operation and encapsulation. The content
> will be defined by the different SFs as an IE.
>
>
>
> I think that a message like this brings flexibility to SFs to implement
> configuration operations.
>
>
>
> what do you think?
>
> regards,
>
> Xavi
>
>
>
> --
>
> *Dr. Xavier Vilajosana*
> Wireless Networks Lab
>
> *Internet Interdisciplinary Institute (IN3) Professor*
> (+34) 646 633 681 <+34%20646%2063%2036%2081>
> xvilajos...@uoc.edu 
> http://xvilajosana.org
> http://wine.rdi.uoc.edu
>
> Parc Mediterrani de la Tecnologia
> Av Carl Friedrich Gauss 5, B3 Building
> 08860 Castelldefels (Barcelona). Catalonia. Spain
>
> [image: Universitat Oberta de Catalunya]
>
> ­
>
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
>


-- 
Chang Tengfei,
Pre-Postdoctoral Research Engineer, Inria
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] Fwd: [hackathon] Hackathon project: OpenWSN

[Tengfei Chang]

Dear all,



We’re planning to an OpenWSN session in IETF 99 hackathon to add more
features into OpenWSN project. E.g. we are going to integrate the RIOT into
OpenWSN stack implementation, build a remotely interoperability test
infrastructure based on OpenWSN and  new 6TiSCH dissectors  verified with
OpenWSN.



Everyone is invited to join us during the hackathon!

*OpenWSN *


   - Champion(s)
   - Tengfei Chang
  - Remy Leone
  - Jonathan Munoz
  - Malisa Vucinic
  - Thomas Watteyne
  - Project(s)
   - RIOT support: enable OpenWSN on RIOT platform.
  - F-Interop: The traditional interoperability test need vendors to
  sit down in a same room and perform the test with varies of tools. With
  F-Interop, everything will be done at home.
  - 6TiSCH Wireshark Dissector.
  - TBA

A little brief about OpenWSN project:

The *Internet of Things* enables great applications, such as energy-aware
homes or real-time asset tracking. With these networks gaining maturity,
*standardization* bodies have started to work on standardizing how these
networks of tiny devices communicate.

The goal of the OpenWSN project is to provide *open-source implementations* of
a complete protocol stack based on Internet of Things standards, on a
*variety* of software and hardware platforms. This implementation can then
help *academia and industry* verify the applicability of these standards to
the Internet of Things, for those networks to become truly ubiquitous.


Best Regard,

Tengfei

-- 
Chang Tengfei,
Pre-Postdoctoral Research Engineer, Inria
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] First version of 4th 6TiSCH plugfest test description

[Tengfei Chang]

I agree ICMPv6 echo request/reply is mandatory to be implemented.

Another point is the ICMPv6 may use the 6LoRH format or not, which also
need to be tested at some point.
If two vendors implement different format or implement not properly, they
can't test the timing template also.

Tengfei

On Fri, Jun 9, 2017 at 3:59 PM, Thomas Watteyne 
wrote:

> yep, that's what I was missing. I now understand your point.
>
> One important advantage of ping is that you create, with one command
> downstream data (root->mote) then upstream data (mote->root) with an ACK
> for every packet. This allows you to have a full record of every case in
> one go. Using another method (e.g. 6P) would be less immediate.
>
> Would you (or anyone else) agree that mandating the implementation of
> ICMPv6 echo request/reply is a realistic requirement?
>
> Thomas
>
> On Fri, Jun 9, 2017 at 3:52 PM, Tengfei Chang 
> wrote:
>
>> If a vendor implements the timing template correctly but doesn't support
>> ping echo request, the vendor can't pass the test.
>>
>> Tengfei
>>
>> On Fri, Jun 9, 2017 at 3:50 PM, Thomas Watteyne > > wrote:
>>
>>> Tengfei,
>>>
>>> I'm afraid I don't quite follow.
>>>
>>> Any traffic (ping, EB, etc) will result is frames being exchanged
>>> between neighbor, which allows us to verify timing inside the timeslot, no?
>>>
>>> Probably missing something,
>>>
>>> Thomas
>>>
>>> On Fri, Jun 9, 2017 at 3:47 PM, Tengfei Chang 
>>> wrote:
>>>
>>>> Remy,
>>>>
>>>> The draft looks great! Thanks for updating!
>>>>
>>>> I have reviewed the draft and have one comment on the test:
>>>> TD_6TiSCH_FORMAT_02
>>>>
>>>> It says a ping echo request packet is used to test the timing template.
>>>> I think we shouldn't use layer 3 packets to test layer 2 behaviors.
>>>>
>>>> What other layer 2 packet can we use for this test? keep alive packet
>>>> can be used for testing from 6N->Dagroot.
>>>> But there is no layer 2 packet from Dagroot to 6N requiring ACK.
>>>>
>>>> What do you think?
>>>> Tengfei
>>>>
>>>> On Fri, Jun 9, 2017 at 3:24 PM, Remy Leone  wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> Please find an updated version of the test description joined. As
>>>>> always, the source is here: https://bitbucket.org/6tisch/td-6tisch/src
>>>>>
>>>>>
>>>>> All comments are welcomed.
>>>>>
>>>>> Best regards
>>>>>
>>>>> Rémy
>>>>>
>>>>> Le mer. 7 juin 2017 à 16:40, Thomas Watteyne 
>>>>> a écrit :
>>>>>
>>>>>> Thanks Remy for putting together such a comprehensive list of tests.
>>>>>> With Pascal, we have set aside time during the interim on Friday [1]
>>>>>> to discuss this.
>>>>>> Thomas
>>>>>>
>>>>>> [1] https://www.ietf.org/mail-archive/web/6tisch/current/msg
>>>>>> 05340.html
>>>>>>
>>>>>> On Wed, Jun 7, 2017 at 4:37 PM, Remy Leone 
>>>>>> wrote:
>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> I created a pull request containing the test descriptions program
>>>>>>> for the next plugfest.
>>>>>>>
>>>>>>> https://bitbucket.org/6tisch/td-6tisch/pull-requests/5/ietf99/diff
>>>>>>>
>>>>>>> It's the first draft.
>>>>>>> It will be discussed on Friday and the final one will be published
>>>>>>> on June 15th.
>>>>>>>
>>>>>>> Once this list of test description is approved I will merge it, tag
>>>>>>> this commit (ietf99_plugfest) and release it.
>>>>>>>
>>>>>>> @all: Could you take a look at the list of tasks presented and tell
>>>>>>> me what you think. Find attached in this email the list of tests in a 
>>>>>>> PDF
>>>>>>> file.
>>>>>>>
>>>>>>> Best regards
>>>>>>>
>>>>>>> Rémy
>>>>>>>
>>>>>>> ___

Re: [6tisch] First version of 4th 6TiSCH plugfest test description

[Tengfei Chang]

If a vendor implements the timing template correctly but doesn't support
ping echo request, the vendor can't pass the test.

Tengfei

On Fri, Jun 9, 2017 at 3:50 PM, Thomas Watteyne 
wrote:

> Tengfei,
>
> I'm afraid I don't quite follow.
>
> Any traffic (ping, EB, etc) will result is frames being exchanged between
> neighbor, which allows us to verify timing inside the timeslot, no?
>
> Probably missing something,
>
> Thomas
>
> On Fri, Jun 9, 2017 at 3:47 PM, Tengfei Chang 
> wrote:
>
>> Remy,
>>
>> The draft looks great! Thanks for updating!
>>
>> I have reviewed the draft and have one comment on the test:
>> TD_6TiSCH_FORMAT_02
>>
>> It says a ping echo request packet is used to test the timing template.
>> I think we shouldn't use layer 3 packets to test layer 2 behaviors.
>>
>> What other layer 2 packet can we use for this test? keep alive packet can
>> be used for testing from 6N->Dagroot.
>> But there is no layer 2 packet from Dagroot to 6N requiring ACK.
>>
>> What do you think?
>> Tengfei
>>
>> On Fri, Jun 9, 2017 at 3:24 PM, Remy Leone  wrote:
>>
>>> Hello,
>>>
>>> Please find an updated version of the test description joined. As
>>> always, the source is here: https://bitbucket.org/6tisch/td-6tisch/src
>>>
>>> All comments are welcomed.
>>>
>>> Best regards
>>>
>>> Rémy
>>>
>>> Le mer. 7 juin 2017 à 16:40, Thomas Watteyne 
>>> a écrit :
>>>
>>>> Thanks Remy for putting together such a comprehensive list of tests.
>>>> With Pascal, we have set aside time during the interim on Friday [1] to
>>>> discuss this.
>>>> Thomas
>>>>
>>>> [1] https://www.ietf.org/mail-archive/web/6tisch/current/msg05340.html
>>>>
>>>> On Wed, Jun 7, 2017 at 4:37 PM, Remy Leone  wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> I created a pull request containing the test descriptions program for
>>>>> the next plugfest.
>>>>>
>>>>> https://bitbucket.org/6tisch/td-6tisch/pull-requests/5/ietf99/diff
>>>>>
>>>>> It's the first draft.
>>>>> It will be discussed on Friday and the final one will be published on
>>>>> June 15th.
>>>>>
>>>>> Once this list of test description is approved I will merge it, tag
>>>>> this commit (ietf99_plugfest) and release it.
>>>>>
>>>>> @all: Could you take a look at the list of tasks presented and tell me
>>>>> what you think. Find attached in this email the list of tests in a PDF 
>>>>> file.
>>>>>
>>>>> Best regards
>>>>>
>>>>> Rémy
>>>>>
>>>>> ___
>>>>> 6tisch mailing list
>>>>> 6tisch@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/6tisch
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> ___
>>>>
>>>> Thomas Watteyne, PhD
>>>> Research Scientist & Innovator, Inria
>>>> Sr Networking Design Eng, Linear Tech
>>>> Founder & co-lead, UC Berkeley OpenWSN
>>>> Co-chair, IETF 6TiSCH
>>>>
>>>> www.thomaswatteyne.com
>>>> ___
>>>>
>>>
>>> ___
>>> 6tisch mailing list
>>> 6tisch@ietf.org
>>> https://www.ietf.org/mailman/listinfo/6tisch
>>>
>>>
>>
>>
>> --
>> Chang Tengfei,
>> Pre-Postdoctoral Research Engineer, Inria
>>
>
>
>
> --
> ___
>
> Thomas Watteyne, PhD
> Research Scientist & Innovator, Inria
> Sr Networking Design Eng, Linear Tech
> Founder & co-lead, UC Berkeley OpenWSN
> Co-chair, IETF 6TiSCH
>
> www.thomaswatteyne.com
> ___
>



-- 
Chang Tengfei,
Pre-Postdoctoral Research Engineer, Inria
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] First version of 4th 6TiSCH plugfest test description

[Tengfei Chang]

Remy,

The draft looks great! Thanks for updating!

I have reviewed the draft and have one comment on the test:
TD_6TiSCH_FORMAT_02

It says a ping echo request packet is used to test the timing template.
I think we shouldn't use layer 3 packets to test layer 2 behaviors.

What other layer 2 packet can we use for this test? keep alive packet can
be used for testing from 6N->Dagroot.
But there is no layer 2 packet from Dagroot to 6N requiring ACK.

What do you think?
Tengfei

On Fri, Jun 9, 2017 at 3:24 PM, Remy Leone  wrote:

> Hello,
>
> Please find an updated version of the test description joined. As always,
> the source is here: https://bitbucket.org/6tisch/td-6tisch/src
>
> All comments are welcomed.
>
> Best regards
>
> Rémy
>
> Le mer. 7 juin 2017 à 16:40, Thomas Watteyne  a
> écrit :
>
>> Thanks Remy for putting together such a comprehensive list of tests.
>> With Pascal, we have set aside time during the interim on Friday [1] to
>> discuss this.
>> Thomas
>>
>> [1] https://www.ietf.org/mail-archive/web/6tisch/current/msg05340.html
>>
>> On Wed, Jun 7, 2017 at 4:37 PM, Remy Leone  wrote:
>>
>>> Hello,
>>>
>>> I created a pull request containing the test descriptions program for
>>> the next plugfest.
>>>
>>> https://bitbucket.org/6tisch/td-6tisch/pull-requests/5/ietf99/diff
>>>
>>> It's the first draft.
>>> It will be discussed on Friday and the final one will be published on
>>> June 15th.
>>>
>>> Once this list of test description is approved I will merge it, tag this
>>> commit (ietf99_plugfest) and release it.
>>>
>>> @all: Could you take a look at the list of tasks presented and tell me
>>> what you think. Find attached in this email the list of tests in a PDF file.
>>>
>>> Best regards
>>>
>>> Rémy
>>>
>>> ___
>>> 6tisch mailing list
>>> 6tisch@ietf.org
>>> https://www.ietf.org/mailman/listinfo/6tisch
>>>
>>>
>>
>>
>> --
>> ___
>>
>> Thomas Watteyne, PhD
>> Research Scientist & Innovator, Inria
>> Sr Networking Design Eng, Linear Tech
>> Founder & co-lead, UC Berkeley OpenWSN
>> Co-chair, IETF 6TiSCH
>>
>> www.thomaswatteyne.com
>> ___
>>
>
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
>


-- 
Chang Tengfei,
Pre-Postdoctoral Research Engineer, Inria
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] 6P "design team" session this Friday, same time as interim meeting

[Tengfei Chang]

@Thomas, Thanks a lot for the meeting!

@Yatch, I like your comments. Looking forwarding to discuss on it. Here are
two more comments(tiny) from my side :

[slide-17]

ppt>*Section 4.3*: do we wait for a link-layer ACK on the Response (or
Confirmation) before committing the transaction?
ppt> à reponse/confirmation. L2 ACK doesn’t carry any 6P meaning

I agree L2 ACK doesn't carry any 6P meaning. But the node indeed commits
the transaction (adding cell in schedule) after the ACK is sent
out/received.

[slide-21]

ppt> [Q] Are the following sentences correct? They allow a pair of nodes
ppt> to open two transactions in parallel. I think these transactions
ppy> might cause inconsistency in their schedule generations.

draft> Only a single 6P Transaction between two neighbors, in a given
draft> direction, can take place at the same time.
draft> (snip)
draft> Nodes A and B MAY support having two transactions going on at
draft> the same time, one in each direction.


ppt>  Here is a simple example in which nodes update their schedule

ppt>  generation counters after receiving a MAC-level ACK for a 6P

ppt>  Response frame:

ppt>  Step-1: Node A Send Request  (GAB=0, GBA=0) : Queued

ppt> Step-2: Node B Send Request  (GAB=0, GBA=0) : Queued

ppt>  Step-3: Node B Recv Request : Send MAC-ACK

ppt> Step-4: Node B Send Response (GAB=0, GBA=0) : Queued

ppt>  Step-5: Node A Recv Request : Send MAC-ACK

ppt> Step-6: Node A Send Response (GAB=0, GBA=0) : Queued

ppt>  Step-7: Node A Recv Response: Send MAC-ACK

ppt>  Step-8: Node B Update GTX/GRX   : (GTX=0, GRX=1)

ppt>  Step-8: Node B Recv Response (GAB=0, GBA=0) : Detect Inconsistency



This is a good point. So this is called because the GAB/GBA is prepended
early.
At the implementation view, this could be solved to add GAB/GBA at when the
queued packet has already being chosen to sent on a cell. This will look
like the ASN in EB.

Tengfei

On Wed, Dec 14, 2016 at 9:21 PM, Yasuyuki Tanaka <
yasuyuki9.tan...@toshiba.co.jp> wrote:

> Thank you, Thomas.
>
> Let me add comments on a couple of the ppt slides in advance, which
> could save time of the coming meeting, I hope...:
>
>   The ppt sides Thomas provided:
>   https://bitbucket.org/6tisch/meetings/raw/c9bd4d78fa452a0588
> abefc104d08520d32e0c26/161209_webex/slides_161209_webex.ppt
>
> 
>
> (6P unclarities 2 [1/4], slide-19)
>
> ppt> Section 4.2.2: [Q] Why must the value of SeqNum increment *by
> ppt> exactly one* at each new 6P request to a certain neighbor?
> ppt>
> ppt> -> Why not?
>
> I think "MUST" is too strict. I thought an idea behind that
> requirement was to try to have different SeqNum to previous
> requests. If this was true, "incrementing by exactly one at each new
> 6P request" could be just an example of implementation.
>
> In addition, there is no validation defined in the draft to see if the
> SeqNum of a receiving request is off by one from the previous one. If
> it was a really "MUST" thing, some validation should be in place,
> shouldn't it? But, of course, such a validation is not practical at
> all since a request could be lost in the air.
>
> I may be wrong; just wanted to know the reason of the restriction,
> "MUST increment by exactly one at each new 6P request issued to the
> same neighbor."
>
> 
>
> ppt> [C] I'd suggest listing only valid combinations of CellOption
> ppt> bits and mentioning others are invalid.
> ppt> -> isn’t that policy?
>
> Indeed, 6P doesn't care about the meanings of bits in CellOptions in
> its operation. However, the definitions in Figure 11 are RECOMMENDED
> by the draft. I cannot see any reason to have ineffective CellOptions
> values separately in the recommendation...
>
> draft> 4.2.6.  6P CellOptions
> draft> (snip)
> draft> Figure 11 contains the RECOMMENDED meaning of the 6P
> draft> CellOptions field for the 6P STATUS and 6P LIST requests.
>
> In this context, we may have to define a return code to respond to
> CellOptions invalid to a corresponding SF, something like
> RC_ERR_CELL_OPTIONS. Or, should RC_ERR (generic error) be returned? In
> any case, it'd be nice to have some text on checking CellOptions value
> in Section 4.3.
>
> 
>
> (6P unclarities 2 [4/4], slide-22)
>
> ppt> [C] I'm not sure typical use cases of the LIST operation. When
> ppt> does a SF use STATUS and LIST...? I think these commands would be
> ppt> useful for the purpose of management or administration. But, it's
> ppt> not within the scope of SF, is it? I'd be nice that a typical use
> ppt> case of LIST is provided in the text.
> ppt> -> Recover after reset
>
> Such recovery doesn't work due to generation inconsistency.
>
> Let's say, there are two 6P nodes, Node A a

[6tisch] (no subject)

[Tengfei Chang]

Hi Yatch, Prof. Qin

Thanks for your comments! Let's me explain my thought more further.

The important benefit is the two cell list 6top format could support
scheduling function better on bandwidth estimation.

An important thought behind this idea is we don't treat Relocation as a
policy in SF0 but a decision SF0 can use during estimating  bandwidth
requirement, like ADD, DELETE command.

With this thought, the SF0 may end up with a decision with:

   1. Relocating cell 1 and 2 to cell 3 and 4,
   2. and Add one more cell 5.

*(1,2,3,4,5 are the slotoffset of cells, just for simplification)*

With the proposed format, the adding list will be [3,4,5] and deleting list
will be [1,2]. If we want to give more choice on choosing which one to
allocate, the adding list can be  like [3,4,5,6,7] and finally pick up 3
out of them. It's the same if the decision is relocating some cell +
deleting.

With this format:

   1. SF0 could manage the schedule/bandwidth more flexible, by taking the
   affect after relocation into account.
   2. as the finally decision can be archived with single 6top transaction
   instead of two, the 6top traffic could be reduced.


Regard,
Tengfe

On Mon, Dec 12, 2016 at 4:32 PM, Qin Wang  wrote:

> Hi Tengfei,
>
> My impression on your proposal is that you are trying to use the
> combination of the length of ADD CellList and DELETE CellList as sort of
> operation code. Right? If 6P really needs so many operations, why do we
> just add more operation codes, which could cost just 1 more bit?
>
> Thanks
> Qin
>
>
> On Friday, December 9, 2016 10:53 AM, Tengfei Chang <
> tengfei.ch...@gmail.com> wrote:
>
>
> Dear all,
>
> As we are going to have RELOCATE command in sixtop draft, then we will
> need add a specific format for RELOCATE. Though the format is not discussed
> yet, but I think finally it will ends up something with two list of cell in
> the packet and having (a) fields to indicate where the cell list to be
> added and list to be removed are. Of course , with RELOCATE command byte in
> the frame. I think this format can be a general format for ADD , DELETE
>  and RELOCATE.
>
> With such format,
>
>- if there is only list of cell to be added, then the frame can be
>represented as ADD command
>- if there is only list of cell to be removed, then DELETE  command
>- if there are both two list of cell, and they have the same number,
>then RELOCATE command..
>
> The benefit of using this two cell list format is that:
>
> If the node wants to relocate one cell and at the same time add some cells
> OR delete some cells, with single sixtop transaction, which is
>
>- there are two list of cell, one for adding, one for deleting, but
>length of adding list is longer than deleting list (Add command+Relocation
>command)
>- there are two list of cell, one for adding, one for deleting, but
>    length of adding list is shorter than deleting list (Delete
>command+Relocation command)
>
> Let me know your thought.
>
> Tengfei
>
> --
> Chang Tengfei,
> Pre-Postdoctoral Research Engineer, Inria
>
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
>
>


-- 
Chang Tengfei,
Pre-Postdoctoral Research Engineer, Inria
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] [6TiSCH] sixtop relocation command format/sixtop general message format?

[Tengfei Chang]

Dear all,

As we are going to have RELOCATE command in sixtop draft, then we will need
add a specific format for RELOCATE. Though the format is not discussed yet,
but I think finally it will ends up something with two list of cell in the
packet and having (a) fields to indicate where the cell list to be added
and list to be removed are. Of course , with RELOCATE command byte in the
frame. I think this format can be a general format for ADD , DELETE  and
RELOCATE.

With such format,

   - if there is only list of cell to be added, then the frame can be
   represented as ADD command
   - if there is only list of cell to be removed, then DELETE  command
   - if there are both two list of cell, and they have the same number,
   then RELOCATE command..

The benefit of using this two cell list format is that:

If the node wants to relocate one cell and at the same time add some cells
OR delete some cells, with single sixtop transaction, which is

   - there are two list of cell, one for adding, one for deleting, but
   length of adding list is longer than deleting list (Add command+Relocation
   command)
   - there are two list of cell, one for adding, one for deleting, but
   length of adding list is shorter than deleting list (Delete
   command+Relocation command)

Let me know your thought.

Tengfei

-- 
Chang Tengfei,
Pre-Postdoctoral Research Engineer, Inria
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Call for adoption of ddraft-vucinic-6tisch-minimal-security as WG document

[Tengfei Chang]

+1. I support to adopt this draft. It's important to have this secure
joining process in 6TiSCH network.

Tengfei

On Wed, Nov 23, 2016 at 2:05 PM, Xavi Vilajosana Guillen <
xvilajos...@uoc.edu> wrote:

> Hi, I support the adoption of this draft. The draft proposes a lightweight
> secure joining mechanism which is definitely needed.
> regards,
> Xavi
>
> 2016-11-23 8:55 GMT+01:00 Pascal Thubert (pthubert) :
>
>> Dear all :
>>
>> The sense of the room at the WG meeting at IETF 97 in Seoul was that
>> draft-richardson-6tisch-dtsecurity-secure-join and
>> draft-vucinic-6tisch-minimal-security could be combined as a staged join
>> process, the former being optional in the case of a PSK, and that the two
>> documents could be adopted as WG docs.
>>
>> We are now confirming this on the ML and calling for adoption of
>> draft-vucinic-6tisch-minimal-security as WG document.
>>
>> The call will be closing in on Friday, December 9th.
>>
>> Please consider the draft carefully and reply to this mail expressing
>> support or disagreement, and in either case, justification for the vote and
>> suggestions are appreciated.
>>
>> The chairs,
>>
>> ___
>> 6tisch mailing list
>> 6tisch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tisch
>>
>
>
>
> --
> Dr. Xavier Vilajosana Guillén­
> Research Professor
> Wireless Networks Research Group
> Internet Interdisciplinary Institute (IN3)
> Universitat Oberta de Catalunya­
>
> +34 646 633 681 <+34%20646%2063%2036%2081>| xvilajos...@uoc.edu­ | Skype­:
> xvilajosana
> http://xvilajosana.org
> http://wine.rdi.uoc.edu/
>
> Parc Mediterrani de la Tecnologia
> Av. Carl Friedrich Gauss, 5. Edifici B3
> 08860 Castelldefels (Barcelona)
>
>
>
> ­
>
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
>


-- 
Chang Tengfei,
Pre-Postdoctoral Research Engineer, Inria
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] [6P+SF0] CALL FOR CONSENSUS: sending a CLEAR request to old parents

[Tengfei Chang]

+1

On Tue, Nov 22, 2016 at 11:00 AM, Lijo Thomas  wrote:

> +1
>
>
>
> The clear command will be useful at implementation point of view.
>
>
>
>
>
> *Thanks & Regards,*
>
> *Lijo Thomas *
>
>
>
>
>
> *From:* 6tisch [mailto:6tisch-boun...@ietf.org] *On Behalf Of *Thomas
> Watteyne
> *Sent:* 22 November 2016 12:47
> *To:* 6tisch@ietf.org
> *Subject:* [6tisch] [6P+SF0] CALL FOR CONSENSUS: sending a CLEAR request
> to old parents
>
>
>
> In thread "Node Behavior at Boot in SF0" (https://www.ietf.org/mail-
> archive/web/6tisch/current/msg04883.html), we ended up discussing the
> following paragraph
>
>
>
> https://tools.ietf.org/html/draft-ietf-6tisch-6top-sf0-02#section-10:
>
>
>
>In order to define a known state after the node is restarted, a CLEAR
>
>command is issued to each of the neighbor nodes to enable a new
>
>allocation process.  The 6P Initial Timeout Value provided by SF0
>
>should allow for the maximum number of TSCH link-layer retries, as
>
>defined by Section 4.3.4 of [I-D.ietf-6tisch-6top-protocol].  TODO/
>
>REMARK: The initial timeout is currently under discussion.
>
>
>
> The suggestion on the table is to:
>
>
>
> step 1. Change *MailScanner has detected a possible fraud attempt from
> "tools.ietf..org" claiming to be* https://tools.ietf.org/html/
> draft-ietf-6tisch-6top-sf0-02#section-10
> 
> to:
>
>
>
>The 6P Initial Timeout Value provided by SF0
>
>should allow for the maximum number of TSCH link-layer retries, as
>
>defined by Section 4.3.4 of [I-D.ietf-6tisch-6top-protocol].  TODO/
>
>REMARK: The initial timeout is currently under discussion.
>
>
>
> step 2. Add the following text to draft-ietf-6tisch-6top-protocol, by
> possibly adding a 4.3.X section:
>
>
>
> 4.3.X. Disconnecting from a neighbor
>
>
>
>If the SF realizes connection to a particular neighbor is no longer
>
>needed (for example a change in parent by the routing protocol),
>
>the SF MAY send a CLEAR request to that neighbor to speed up the
>
>cleanup process of the cells allocated with that neighbor.
>
>
>
> I'm hereby opening a call for WG consensus. Please +1 or comment/suggest.
> The chairs will summarize on Fridat 25 Nov.
>
>
>
> Thomas
>
>
>
> --
>
> ___
>
>
>
> Thomas Watteyne, PhD
>
> Research Scientist & Innovator, Inria
>
> Sr Networking Design Eng, Linear Tech
>
> Founder & co-lead, UC Berkeley OpenWSN
>
> Co-chair, IETF 6TiSCH
>
>
>
> www.thomaswatteyne.com
>
> ___
>
> 
> ---
> [ C-DAC is on Social-Media too. Kindly follow us at:
> Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]
>
> This e-mail is for the sole use of the intended recipient(s) and may
> contain confidential and privileged information. If you are not the
> intended recipient, please contact the sender by reply e-mail and destroy
> all copies and the original message. Any unauthorized review, use,
> disclosure, dissemination, forwarding, printing or copying of this email
> is strictly prohibited and appropriate legal action will be taken.
> 
> ---
>
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
>


-- 
Chang Tengfei,
Pre-Postdoctoral Research Engineer, Inria
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] [6TiSCH] Node Behavior at Boot in SF0

[Tengfei Chang]

@Yatch,
I see the point. I have no doubt now about the behaviors  after the node
boot.

I am thinking another case that a node needs send a CLEAR command to
previous parent if it changed. I guess this is not mentioned in the draft?
@Thomas, maybe we can create an issue for that?
Let me know if this is already mentioned in the draft.

Tengfei

On Wed, Nov 16, 2016 at 3:05 PM, Thomas Watteyne 
wrote:

> @Tengfei,
> Does that suggestion work for you or should we create an issue on SF0?
> Thomas
>
> On Fri, Nov 11, 2016 at 8:50 PM, Yasuyuki Tanaka <
> yasuyuki9.tan...@toshiba.co.jp> wrote:
>
>> Hi Tengfei,
>>
>> I think an assumption there is that a node has no state with its
>> neighbors just after booting up or restarting. On the other hand, a
>> neighbor of them may have cells allocated for the node. To resolve
>> such a possible inconsistency, the node issues CLEAR to each of its
>> neighbors.
>>
>> Best,
>> Yatch
>>
>> On 2016/11/02 15:29, Tengfei Chang wrote:
>>
>>> All,
>>>
>>> For the decision when a node is restarted, the SF0 says:
>>>
>>>In order to define a known state after the node is restarted, a CLEAR
>>>command is issued to each of the neighbor nodes to enable a new
>>>allocation process.  The 6P Initial Timeout Value provided by SF0
>>>should allow for the maximum number of TSCH link-layer retries, as
>>>defined by Section 4.3.4 of [I-D.ietf-6tisch-6top-protocol <
>>> https://tools.ietf.org/html/draft-ietf-6tisch-6top-sf0-02#r
>>> ef-I-D.ietf-6tisch-6top-protocol>].  TODO/
>>>REMARK: The initial timeout is currently under discussion.
>>>
>>>
>>> A little suggestion is DO NOT issue a clear command to previous parent
>>> until the nodes has reserved new cells to its new parent. This is to avoid
>>> the swing if the reservation failed to its new parent and changed back to
>>> previous parent.
>>>
>>> What do you think?
>>>
>>> Tengfei
>>>
>>> --
>>> Chang Tengfei,
>>> Pre-Postdoctoral Research Engineer, Inria
>>>
>>>
>>> ___
>>> 6tisch mailing list
>>> 6tisch@ietf.org
>>> https://www.ietf.org/mailman/listinfo/6tisch
>>>
>>>
>> ___
>> 6tisch mailing list
>> 6tisch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tisch
>>
>
>
>
> --
> ___
>
> Thomas Watteyne, PhD
> Research Scientist & Innovator, Inria
> Sr Networking Design Eng, Linear Tech
> Founder & co-lead, UC Berkeley OpenWSN
> Co-chair, IETF 6TiSCH
>
> www.thomaswatteyne.com
> ___
>
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
>


-- 
Chang Tengfei,
Pre-Postdoctoral Research Engineer, Inria
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] [6TISCH] Specify the number of cells to be added or deleted in SF0

[Tengfei Chang]

Hi Nicola, Diego,

I see. Thanks for all your explanation!

It would be very helpful if we can see some recommended number of cell or
advice how to choose the number of cell in the draft.
As Sixtop left lots of details in SF, my thought is SF should give more
specific information or clues for developer/implementer to implement.
Of course, those information will come out from real experiments.

Thanks for all you replying!

Tengfei


On Wed, Nov 2, 2016 at 3:42 PM, Prof. Diego Dujovne <
diego.dujo...@mail.udp.cl> wrote:

> Nicola,
>I agree with your comment, but the cell estimation
> algorithm changed: we now estimate the number of required
> cells from the number of requested cells (to add or delete)
> and the number of effectively used cells. What is still not clear
> to me is if the simulation results from the OTF paper is still valid
> given this change. To enable the cell estimation algorithm without
> packet loss, we need to guarantee always a small amount of
> overprovisioning.
>   Let me bring the lost text (from OTF) back to SF0.
>   Regards,
>
>  Diego
>
> 2016-11-02 11:36 GMT-03:00 Nicola Accettura :
>
>> Hi Tengei,
>>
>> the problem you are rising is that you would like to see a number of
>> cells to add/delete when comparing required and deleted cells.
>>
>> The ancestor of SF0, namely OTF, used to specify the following sentence:
>>
>> The number of soft cells to be scheduled/deleted for bundle resizing
>>is out of the scope of this document and implementation-dependant.
>>
>> In fact, we wanted to let that choice being implementation specific.
>>
>> What you are proposing (the exact number of cells to add or delete) was
>> already implemented in the 6tisch simulator, and it is in fact something
>> that has already been used and tested in the following papers:
>>
>> Palattella et al., On-the-Fly Bandwidth Reservation for 6TiSCH Wireless
>> Industrial Networks, IEEE Sensors Journal, 2015
>>
>> Muraoka et al., Simple Distributed Scheduling with Collision Detection in
>> TSCH Networks, IEEE Sensors Journal, 2016
>>
>> But, as already said, this is just a way you can allocate cells. I guess
>> we don't want to restrict that setting to a particular algorithm choice.
>>
>> Hope this helps.
>>
>> Nicola
>>
>> 2016-11-02 14:59 GMT+01:00 Tengfei Chang :
>>
>>> Hi All,
>>>
>>> I am reading the SF0-02 version which is just released few days ago.
>>>
>>> In the SF0 Allocation Policy section, the policy said
>>>
>>>1.  If REQUIREDCELLS<(SCHEDULEDCELLS-SF0THRESH), delete one or more
>>>cells.
>>>2.  If (SCHEDULEDCELLS-SF0THRESH)<=REQUIREDCELLS<=SCHEDULEDCELLS, do
>>>nothing.
>>>3.  If SCHEDULEDCELLS<=REQUIREDCELLS, add one or more cells.
>>>
>>>
>>>
>>> Personally thinking, add/delete one cells may call the sixtop many times
>>> which is not efficiency, add/delete more cells is not clear to the
>>> implementer.
>>> I guess there is a decision to say when to add one cell and when to add
>>> more cells. But I didn't find it in SF0 draft.
>>> Is there any reason why we doesn't say specific number of cells?
>>>
>>> If no, I think we can add/remove the number of cells to make sure the
>>> scheduled cells equals to the required cells plus half of SF0THRESH, which
>>> will help stabilize a little bit of the SF0, in case the sixtop is calling
>>> too often.
>>>
>>> Which means: if SCHEDULEDCELLS<=REQUIREDCELLS:
>>>
>>> 1. when there is no cell in the schedule add one cell
>>> 2. when there is at least one cell in schedule, add
>>> REQUIREDCELLS-SCHEDULEDCELLS+(SF0THRESH+1)/2 number of cells
>>>
>>> if REQUIREDCELLS<(SCHEDULEDCELLS-SF0THRESH))
>>>
>>> 1. When required cells equals 0, remove all cells but keep one in
>>> schedule
>>> 2. when required cells is greater than 0, remove  SCHEDULEDCELLS-
>>> REQUIREDCELLS-(SF0THRESH+1)/2
>>>
>>> Does this make sense?
>>>
>>> Tengfei
>>>
>>> --
>>> Chang Tengfei,
>>> Pre-Postdoctoral Research Engineer, Inria
>>>
>>> ___
>>> 6tisch mailing list
>>> 6tisch@ietf.org
>>> https://www.ietf.org/mailman/listinfo/6tisch
>>>
>>>
>>
>> ___
>> 6tisch mailing list
>> 6tisch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tisch
>>
>>
>
>
> --
> DIEGO DUJOVNE
> Profesor Asociado
> Escuela de Informática y Telecomunicaciones
> Facultad de Ingeniería - Universidad Diego Portales - Chile
> www.ingenieria.udp.cl
> (56 2) 676 8125
>



-- 
Chang Tengfei,
Pre-Postdoctoral Research Engineer, Inria
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch