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

From: Tengfei Chang <[email-masked]>
Date: Mon, 8 Apr 2019 21:06:26 -0700

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

---

From: Fabrice Theoleyre <[email-masked]>
Date: Tue, 9 Apr 2019 11:39:46 +0200

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 <[email-masked]> 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 <https://www.ietf.org/id/draft-ietf-6tisch-msf-03.txt>
> 
> 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:
> - the "adapt to traffic" strategy has the ability to handle burst traffic by using a smaller MAX_NUMCELLS
> 
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch

---

From: Atis Elsts <[email-masked]>
Date: Tue, 9 Apr 2019 14:06:13 +0300

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

--
Dr. Atis Elsts
Researcher, Institute of Electronics and Computer Science (EDI)
Dzerbenes str. 14, Riga, LV-1006

---

From: Yasuyuki Tanaka <[email-masked]>
Date: Tue, 9 Apr 2019 14:02:58 +0200

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.

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?

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?

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

One more thing:

https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-5.3
draft-03>  4.  For any other cell, it compares its PDR against that of the cell
draft-03>      with the highest PDR.  If the different is less than
draft-03>      RELOCATE_PDRTHRES, it triggers the relocation of that cell using
draft-03>      a 6P RELOCATE command.

- s/different/difference/
- s/less than/larger than/ ??

Can you check the entire text in Section 5?

[minor comment #1]

https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-2
draft-03>   For example, a Trickle Timer defined in [RFC6550] MAY be
draft-03>   applied on DIOs.

Do we need "MAY" here? If you implement RFC6550, DIO is automatically
controlled by Trickle Timer.

[minor comment #2]

https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-3
draft-03>   MUST use the hash function SAX [SAX-DASFAA].  The coordinates are
draft-03>   computed to distribute the cells across all channel offsets, and all
draft-03>   but the first time offsets of Slotframe 1.  The first time offset is
draft-03>   skipped to avoid colliding with the minimal cell in Slotframe 0.

s/time offset/slot offset/

[minor comment #3]

https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-3
draft-03>    o  slotOffset(MAC) = 1 + hash(EUI64, length(Slotframe_1) - 1)
draft-03>    o  channelOffset(MAC) = hash(EUI64, 16)
draft-03>
draft-03>    The second input parameter defines the maxmium return value of the
draft-03>    hash function.

The second input should be "the maximum return value plus 1", which
is the parameter 'T' of SAX.

https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#appendix-B
draft-03>   In MSF, the T is replaced by the length slotframe 1.  String s is
draft-03>   replaced by the mote EUI64 address.  The characters of the string c0,
draft-03>   c1, ..., c7 are the 8 bytes of EUI64 address.

This may be misleading. The first sentence could be...

  For slotOffset(), T is the length of the slotframe 1. For
  channelOffset(), T is the number of available channels.

[minor comment #4]

https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-3
draft-03>   The second input parameter defines the maxmium return value of the
draft-03>   hash function.  There are other optional parameters defined in SAX
draft-03>   determines the performance of SAX hash function.  Those parameters
draft-03>   could be broadcasted in EB frame or pre-configured.

What parameters...? The parameters to configure are be h0, l_bit,
and r_bit, I believe.

By the way, s/maxmium/maximum/

[minor comment #5]

https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-5.1
draft-03>   Implementors MAY choose to create the same counters for each
draft-03>   neighbor, and add them as additional statistics in the neighbor
draft-03>   table.

https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-5.3
draft-03>   Implementors MAY choose to maintain the same counters for each
draft-03>   managed cell in the schedule.

For what purposes? Do we need these sentences?

[minor comment #6]
Want to have test vectors of SAX! :-)

[minor comment #7]

https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-5.1
draft-03>       *  If NumCellsUsed > LIM_NUMCELLSUSED_HIGH, trigger 6P to add a
draft-03>          single cell to the preferred parent
draft-03>       *  If NumCellsUsed < LIM_NUMCELLSUSED_LOW, trigger 6P to remove a
draft-03>          single cell to the preferred parent

It would be better to put "managed" there:

proposed>       *  If NumCellsUsed > LIM_NUMCELLSUSED_HIGH, trigger 6P to add a
proposed>          single managed cell to the preferred parent
proposed>       *  If NumCellsUsed < LIM_NUMCELLSUSED_LOW, trigger 6P to remove a
proposed>          single managed cell to the preferred parent

[minor comment #8]

s/Tx Cell/TX cell/
s/Tx cell/TX cell/

Best,
Yatch

---

From: Tengfei Chang <[email-masked]>
Date: Wed, 17 Apr 2019 13:57:17 +0200

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 <[email-masked]>
wrote:

> Dear Tengfei,
>
> Please find below my review of the draft. I isolated the corresponding
> blocks, and inserted my comments after 'FT>'
>
> TC:  yes, "negotiated cells" sounds good for me.

———

---

From: Tengfei Chang <[email-masked]>
Date: Wed, 17 Apr 2019 14:48:22 +0200

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

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

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

>> TC: Will be fixed in next version.

>>  TC: no. only one parent is considered. Will change something like:
"AutoUpCell  takes precedence if its outgoing queue is non-empty."

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

>> TC:  6P RELOCATE request to the parent will be sent on AutoUpCell. I
missed the RELOCATE 6P request. Will be fixed in next version.

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

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

> TC: 👍

>> In particular, are they bidirectional, shared, etc.?
TC: no, they are considered as only one direction, with cell option either
TX=1 or RX=1.

>> FT> implements the counter only when the cell is decoded. It may decide
TC: This is good point! I think the adaption strategy doesn't fit the case
for the RX cell in this sense.
TC: if we can't figure out a good way to handle that case, we will remove
the support of RX cell.

>> TC: Right now we are not considering the case of SHARED "managed cell"
(negotiated cell) since It may influence the calculation of cell Usage.

>> FT> Before, and the AutoUpCells has the priority?
TC: for general case, AutoUpcell is installed before issuing 6P RELOCATE
RESPONSE. However, in case of parent switching, the sequence may change.

>> FT> Is it something you considered?
TC: in convergence time, the traffic goes on autonomous cell, when the
"managed cell"  is installed, that cell shouldn't have collision.
Though the PDR take a long time to reflect the actual PDR, in case of bad
PDR on the cell, the MSF traffic adapting  strategy will compensate by
allocating extra cell to meet the throughput.

>> TC: will be fixed in next version.

> TC: will be fixed in next version.

>> FT> MAXBE is the maximum backoff exponent used
TC: will be fixed in next version.

---

From: Tengfei Chang <[email-masked]>
Date: Wed, 17 Apr 2019 15:31:31 +0200

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

---

From: Tengfei Chang <[email-masked]>
Date: Wed, 17 Apr 2019 16:58:24 +0200

Hi Yatch,

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

> draft-03>  o  6P RELOCATE Response frames to its RPL routing parent MUST

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.

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

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

> draft-03>  o  6P RELOCATE Response frames to its RPL routing parent MUST

TC: yes, accepted this comment.
TC: As replied to Fabrice, I will remove the RX=1 cell case for the
adapting traffic strategy in next version..

> Can you check the entire text in Section 5?

TC: sure. Sorry for the confusing! Will be clarified in next version.

> TC: yes, it's a requirement.

> TC: Thanks! I will go over the draft to make sure this is consistent.

> is the parameter 'T' of SAX.

TC: That's correct! Will be fixed.

> TC: Will be applied in next verison. Thanks!

> What parameters...? The parameters to configure are be h0, l_bit,

TC: yes, I didn't say that but presented in the example section. Maybe I
should mention there though.

> By the way, s/maxmium/maximum/

TC: will be fixed! Thanks!

> For what purposes? Do we need these sentences?

TC: For parent selection. In case parent switching happens, those counters
can record the link quality of previous parent for future parent selection.

> TC: like givem a node EUI64 address, to have the slotoffset and choffset?
we could.

> proposed>          single managed cell to the preferred parent

TC: will put in next version!

> s/Tx cell/TX cell/

TC: Will go through the text in the next version about the consistency!
Thanks!

---

From: Tengfei Chang <[email-masked]>
Date: Wed, 17 Apr 2019 18:50:32 +0200

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 <[email-masked]>
wrote:

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

---

From: <[email-masked]>
Date: Tue, 23 Apr 2019 00:51:46 +0000

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 <[email-masked]> On Behalf Of Tengfei Chang
Sent: Tuesday, April 09, 2019 1:06 PM
To: [email-masked]
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

It's for two reasons:

Tengfei

---

From: Tengfei Chang <[email-masked]>
Date: Tue, 23 Apr 2019 15:31:52 +0200

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 <[email-masked]> wrote:

> *From:* 6tisch <[email-masked]> *On Behalf Of *Tengfei Chang
> *Sent:* Tuesday, April 09, 2019 1:06 PM
> *To:* [email-masked]
> *Subject:* [6tisch] [Call for Review] draft-ietf-6tisch-msf-03
>
>
>
> Dear all,
>
>
>

---

From: <[email-masked]>
Date: Thu, 25 Apr 2019 03:03:08 +0000

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 <[email-masked]>
Sent: Tuesday, April 23, 2019 10:32 PM
To: ito toshio(伊藤 俊夫 ○ＲＤＣ□ＣＮＬ) <[email-masked]>
Cc: [email-masked]
Subject: Re: [6tisch] [Call for Review] draft-ietf-6tisch-msf-03

Hi Toshio,

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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi Tengfei,

Best regards,
Toshio Ito

From: 6tisch <[email-masked]<mailto:[email-masked]>> On Behalf Of Tengfei Chang
Sent: Tuesday, April 09, 2019 1:06 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [6tisch] [Call for Review] draft-ietf-6tisch-msf-03

Dear all,

It's for two reasons:

Tengfei