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

Hi Esteban,

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

It'd be nice to mention something there, at least like this:

  A node may remove negotiated cells scheduled with a neighbor which is
  considered as "unreachable", without having a 6P transaction. In that
  case, the node SHOULD reset the (6P) SeqNum for the neighbor. Specifying
  mechanisms to detect unreachable neighbors is out of scope of this
  document.

We used to have such a mechanism in previous versions, by the way:

https://tools.ietf.org/html/draft-ietf-6tisch-msf-02#section-4.8

I'm not sure what is the best way to do for that purpose when using MSF.

Best,
Yatch

> On Jul 11, 2019, at 15:47, Esteban Municio <esteban.municio@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.
> 
> * 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.
> 
> * 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).
> 
> 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"?
> 
> 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.municio@uantwerpen.be
> The Beacon | Sint-Pietersvliet 7 | 2000 Antwerpen, Belgium 
> 
> 
> _______________________________________________
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch