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

[<[e-mail]>]

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 <[e-mail]>
Sent: Tuesday, April 23, 2019 10:32 PM
To: ito toshio(伊藤 俊夫 ○ＲＤＣ□ＣＮＬ) <[e-mail]>
Cc: [e-mail]
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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> On Behalf Of Tengfei Chang
Sent: Tuesday, April 09, 2019 1:06 PM
To: [e-mail]<mailto:[e-mail]>
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