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

Yatch,
Please see inline.

On Wed, Nov 16, 2016 at 6:39 PM, Yasuyuki Tanaka <
yasuyuki9.tanaka@toshiba.co.jp> wrote:

> Hi Diego and Tengfei,
>
> diego> I suggest to keep the CLEAR command after reboot/failure.
>
> It's fine for me, too.
>

that's what we agreed upon during the WG meeting in Seoul this week, so
we're in sync.

> 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.
>
>
I agree with you that SF0 will realize the cells to the previous preferred
parent aren't used, and remove. Sending an explicit CLEAR will speed things
up, and avoid for the previous preferred parent to waste energy listening
to those. A CLEAR wouldn't hurt, right?

> 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/d
>> raft-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
>>
>>
> _______________________________________________
> 6tisch mailing list
> 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
_______________________________________