Re: [6tisch] [6TiSCH] Node Behavior at Boot in SF0

Hi Diego and Tengfei,

diego> I suggest to keep the CLEAR command after reboot/failure.

It's fine for me, too.

tengfei> I am thinking another case that a node needs send a CLEAR
tengfei> command to previous parent if it changed. I guess this is not
tengfei> mentioned in the draft?

No, it's not mentioned. Yet, I think, it's out of scope of SF0.

tengfei> [from the original mail]
tengfei> A little suggestion is DO NOT issue a clear command to
tengfei> previous parent until the nodes has reserved new cells to its
tengfei> new parent. This is to avoid the swing if the reservation
tengfei> failed to its new parent and changed back to previous parent.

A solution here "to avoid the swing" is to have enough
over-provisioned cells to prevent undesirable packet losses for
RPL. This can be done by setting SF0THRESH reasonably high.

And, I don't think a node switching its preferred parent needs to send
CLEAR to the previous one at any point. Unnecessary cells are supposed
to be deallocated automatically by SF0.

After changing its preferred parent at the RPL layer, the amount of
traffic or "the current number of used cell" to the previous one is
expected to decrease. Once Cell Estimation Algorithm notices the
decrement, unnecessary cells scheduled for the previous preferred
parent are deleted eventually.

In fact, SF0 cannot tell which neighbor is the previous preferred
parent, anyway.

Best,
Yatch

On 2016/11/16 16:16, Thomas Watteyne wrote:
> That would be perfect, thanks!
>
> On Thu, 17 Nov 2016 at 00:11 Prof. Diego Dujovne <diego.dujovne@mail.udp.cl <mailto:diego.dujovne@mail.udp.cl>> wrote:
>
>     Thomas,
>                  It is not on my slides, since the default
>     behavior (issue a CLEAR command) did not
>     change from -01 to -02. I can raise the issue
>     during the presentation.
>     Regards,
>
>                                     Diego
>
>     2016-11-16 12:06 GMT-03:00 Thomas Watteyne <thomas.watteyne@inria.fr <mailto:thomas.watteyne@inria.fr>>:
>
>         Diego,
>         Fine for me. Could you bring it up during the WG meeting tomorrow?
>         Thomas
>
>         On Thu, 17 Nov 2016 at 00:02 Prof. Diego Dujovne <diego.dujovne@mail.udp.cl <mailto:diego.dujovne@mail.udp.cl>> wrote:
>
>             Yasuyuki, Thomas,
>                                          I suggest to keep the CLEAR command
>             after reboot/failure.
>             Regards,
>
>                                                    Diego
>
>             2016-11-16 11:05 GMT-03:00 Thomas Watteyne <thomas.watteyne@inria.fr <mailto:thomas.watteyne@inria.fr>>:
>
>                 @Tengfei,
>                 Does that suggestion work for you or should we create an issue on SF0?
>                 Thomas
>
>                 On Fri, Nov 11, 2016 at 8:50 PM, Yasuyuki Tanaka <yasuyuki9.tanaka@toshiba.co.jp <mailto:yasuyuki9.tanaka@toshiba.co.jp>> wrote:
>
>                     Hi Tengfei,
>
>                     I think an assumption there is that a node has no state with its
>                     neighbors just after booting up or restarting. On the other hand, a
>                     neighbor of them may have cells allocated for the node. To resolve
>                     such a possible inconsistency, the node issues CLEAR to each of its
>                     neighbors.
>
>                     Best,
>                     Yatch
>
>                     On 2016/11/02 15:29, Tengfei Chang wrote:
>
>                         All,
>
>                         For the decision when a node is restarted, the SF0 says:
>
>                            In order to define a known state after the node is restarted, a CLEAR
>                            command is issued to each of the neighbor nodes to enable a new
>                            allocation process.  The 6P Initial Timeout Value provided by SF0
>                            should allow for the maximum number of TSCH link-layer retries, as
>                            defined by Section 4.3.4 of [I-D.ietf-6tisch-6top-protocol <https://tools.ietf.org/html/draft-ietf-6tisch-6top-sf0-02#ref-I-D.ietf-6tisch-6top-protocol>].  TODO/
>                            REMARK: The initial timeout is currently under discussion.
>
>
>                         A little suggestion is DO NOT issue a clear command to previous parent until the nodes has reserved new cells to its new parent. This is to avoid the swing if the reservation failed to its new parent and changed back to previous parent.
>
>                         What do you think?
>
>                         Tengfei
>
>                         --
>                         Chang Tengfei,
>                         Pre-Postdoctoral Research Engineer, Inria
>
>
>                         _______________________________________________
>                         6tisch mailing list
>                         6tisch@ietf.org <mailto:6tisch@ietf.org>
>                         https://www.ietf.org/mailman/listinfo/6tisch
>
>
>                     _______________________________________________
>                     6tisch mailing list
>                     6tisch@ietf.org <mailto:6tisch@ietf.org>
>                     https://www.ietf.org/mailman/listinfo/6tisch
>
>
>
>
>                 --
>                 _______________________________________
>
>                 Thomas Watteyne, PhD
>                 Research Scientist & Innovator, Inria
>                 Sr Networking Design Eng, Linear Tech
>                 Founder & co-lead, UC Berkeley OpenWSN
>                 Co-chair, IETF 6TiSCH
>
>                 www.thomaswatteyne.com <http://www.thomaswatteyne.com>
>                 _______________________________________
>
>                 _______________________________________________
>                 6tisch mailing list
>                 6tisch@ietf.org <mailto:6tisch@ietf.org>
>                 https://www.ietf.org/mailman/listinfo/6tisch
>
>
>
>
>             --
>             DIEGO DUJOVNE
>             Profesor Asociado
>             Escuela de Informática y Telecomunicaciones
>             Facultad de Ingeniería - Universidad Diego Portales - Chile
>             www.ingenieria.udp.cl <http://www.ingenieria.udp.cl>
>             (56 2) 676 8125
>
>
>
>
>     --
>     DIEGO DUJOVNE
>     Profesor Asociado
>     Escuela de Informática y Telecomunicaciones
>     Facultad de Ingeniería - Universidad Diego Portales - Chile
>     www.ingenieria.udp.cl <http://www.ingenieria.udp.cl>
>     (56 2) 676 8125
>
>
>
> _______________________________________________
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>