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

[toshio9.ito]

Thanks, Tengfei.

I understand that adaptation to traffic doesn't work for Rx
managed cells. So, as you suggested, the parent node should
trigger 6P ADD/DELETE/RELOCATE to one of its children, probably
using 3-step transaction. That would affect description on usage
of AutoUpCell and AutoDownCell.


Best regards,
Toshio Ito

From: Tengfei Chang 
Sent: Tuesday, April 23, 2019 10:32 PM
To: ito toshio(伊藤 俊夫 ○ＲＤＣ□ＣＮＬ) 
Cc: 6tisch@ietf.org
Subject: Re: [6tisch] [Call for Review] draft-ietf-6tisch-msf-03

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 
mailto:toshio9@toshiba.co.jp>> 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<mailto:6tisch-boun...@ietf.org>> On 
Behalf Of Tengfei Chang
Sent: Tuesday, April 09, 2019 1:06 PM
To: 6tisch@ietf.org<mailto: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] [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] [Call for Review] draft-ietf-6tisch-msf-03

[toshio9.ito]

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
___
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 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 Minimal Security Framework
>>for 6TiSCH
>>
>> FT> In contradiction with section 2 'MAY implements MSF without
>> implementing
>> FT> Minimal 6TiSCH Configuration.'
>>
>
TC: yes, as a consequence, we may use "MUST" again on the Minimal 6TiSCH
Configuration. Or make the security strategy open as well?
I am tending to the former.

>
>> ———
>>
>> The section 4 is particularly clearly, explaining well the ‘flow’ when a
>> device joins the network
>>
> TC: 👍

>
>> ———
>>
>> While autonomous cells have a dedicated section (2), managed cells are
>> not described.
>> In particular, are they bidirectional, shared, etc.?
>>
>
TC: no, they are considered as only one direction, with cell option either
TX=1

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

[Tengfei Chang]

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

———
>
> 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.
>
> ———
>
> 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?)
>
> ———
>
> 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
>
> ———
>
>  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?
>
> ———
>
> 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?
>
> ———
>
>  A node implementing MSF MUST implement the Minimal Security Framework
>for 6TiSCH
>
> FT> In contradiction with section 2 'MAY implements MSF without
> implementing
> FT> Minimal 6TiSCH Configuration.'
>
> ———
>
> The section 4 is particularly clearly, explaining well the ‘flow’ when a
> device joins the network
>
> ———
>
> While autonomous cells have a dedicated section (2), managed cells are not
> described.
> In particular, are they bidirectional, shared, etc.?
>
> ———
>
> NumCellsUsed:  Counts the number of managed cells that have been
>used.  This counter is initialized at 0.  NumCellsUsed is
>incremented by exactly 1 when, during a managed cell to the
>preferred parent, either of the following happens:
>
> […]
>
>*  The node receives a frame from its preferred parent.
>
> FT> Let assume a cell is shared, and is only used to receive packets.
> FT> Because of a bad PDR, we have many retransmissions. The receiver
> FT> implements the counter only when the cell is decoded. It may decide
> FT> to DELETE this cell.
> FT> Doesn’t it?
>
> FT> Shouldn’t the description consider separately the SHARED and NON-SHARED
> FT> cases?
>
> ———
>
> 1.  if there is managed cell conflicted with the AutoUpCells to be
>installed, the node MUST issue a 6P RELOCATE command to relocate
>the conflicted cell
>
> FT> When is the AutoUpCells installed? After the 6P RELOCATE RESPONSE?
> FT> Before, and the AutoUpCells has the priority?
>
> ———
> That is, for example, from NumTx=256 and
>NumTxAck=128, they become NumTx=128 and NumTxAck=64.  This operation
>does not change the value of the PDR, but allows the counters to keep
>incrementing.
>
> FT> yes, but it increases the convergence time. For 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 ba

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

[Atis Elsts]

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

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

[Fabrice Theoleyre]

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?

———

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

———

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.

———

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

———

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

———

 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? 

———

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?

———

 A node implementing MSF MUST implement the Minimal Security Framework
   for 6TiSCH 

FT> In contradiction with section 2 'MAY implements MSF without implementing
FT> Minimal 6TiSCH Configuration.'

———

The section 4 is particularly clearly, explaining well the ‘flow’ when a device 
joins the network

———

While autonomous cells have a dedicated section (2), managed cells are not 
described. 
In particular, are they bidirectional, shared, etc.?

———

NumCellsUsed:  Counts the number of managed cells that have been
   used.  This counter is initialized at 0.  NumCellsUsed is
   incremented by exactly 1 when, during a managed cell to the
   preferred parent, either of the following happens:
   
[…] 

   *  The node receives a frame from its preferred parent.

FT> Let assume a cell is shared, and is only used to receive packets.
FT> Because of a bad PDR, we have many retransmissions. The receiver 
FT> implements the counter only when the cell is decoded. It may decide
FT> to DELETE this cell. 
FT> Doesn’t it?

FT> Shouldn’t the description consider separately the SHARED and NON-SHARED
FT> cases? 

———

1.  if there is managed cell conflicted with the AutoUpCells to be
   installed, the node MUST issue a 6P RELOCATE command to relocate
   the conflicted cell

FT> When is the AutoUpCells installed? After the 6P RELOCATE RESPONSE?
FT> Before, and the AutoUpCells has the priority? 

———
That is, for example, from NumTx=256 and
   NumTxAck=128, they become NumTx=128 and NumTxAck=64.  This operation
   does not change the value of the PDR, but allows the counters to keep
   incrementing.

FT> yes, but it increases the convergence time. For 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 li