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

[Tengfei Chang <[e-mail]>]

Hi Esteban,

Thanks for the comments, I will answer inline:

On Thu, Jul 11, 2019 at 3:47 PM Esteban Municio <
[e-mail]> 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
> [e-mail]
> The Beacon | Sint-Pietersvliet 7 | 2000 Antwerpen, Belgium
>
>
>

-- 
Chang Tengfei,
Postdoctoral Research Engineer, Inria