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

From: Tengfei Chang <[email-masked]>
Date: Wed, 2 Nov 2016 15:29:54 +0100

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

---

From: Yasuyuki Tanaka <[email-masked]>
Date: Fri, 11 Nov 2016 12:50:22 +0100

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:
>    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/
> 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,
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 16 Nov 2016 23:05:43 +0900

@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 <
[email-masked]> wrote:

>>    defined by Section 4.3.4 of [I-D.ietf-6tisch-6top-protocol <
>> https://tools.ietf.org/html/draft-ietf-6tisch-6top-sf0-02#r
>> ef-I-D.ietf-6tisch-6top-protocol>].  TODO/

-- 
_______________________________________

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
_______________________________________

---

From: Tengfei Chang <[email-masked]>
Date: Wed, 16 Nov 2016 15:49:02 +0100

@Yatch,
I see the point. I have no doubt now about the behaviors  after the node
boot.

I am thinking another case that a node needs send a CLEAR command to
previous parent if it changed. I guess this is not mentioned in the draft?
@Thomas, maybe we can create an issue for that?
Let me know if this is already mentioned in the draft.

Tengfei

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Wed, 16 Nov 2016 12:02:04 -0300

Yasuyuki, Thomas,
                             I suggest to keep the CLEAR command
after reboot/failure.
Regards,

                                       Diego

-- 
DIEGO DUJOVNE
Profesor Asociado
Escuela de Informática y Telecomunicaciones
Facultad de Ingeniería - Universidad Diego Portales - Chile
www.ingenieria.udp.cl
(56 2) 676 8125

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 16 Nov 2016 15:06:20 +0000

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 <[email-masked]>
wrote:

> https://tools.ietf.org/html/draft-ietf-6tisch-6top-sf0-02#ref-I-D.ietf-6tisch-6top-protocol>].
> TODO/

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Wed, 16 Nov 2016 12:11:24 -0300

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 <[email-masked]>:

> On Thu, 17 Nov 2016 at 00:02 Prof. Diego Dujovne <
> [email-masked]> wrote:
>
>> Yasuyuki, Thomas,
>> https://tools.ietf.org/html/draft-ietf-6tisch-6top-sf0-02#
>> ref-I-D.ietf-6tisch-6top-protocol>].  TODO/

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 16 Nov 2016 15:16:22 +0000

That would be perfect, thanks!

---

From: Yasuyuki Tanaka <[email-masked]>
Date: Wed, 16 Nov 2016 18:39:18 +0100

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:
> On Thu, 17 Nov 2016 at 00:11 Prof. Diego Dujovne <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Thomas,
>     2016-11-16 12:06 GMT-03:00 Thomas Watteyne <[email-masked] <mailto:[email-masked]>>:
>
>         Diego,
>         On Thu, 17 Nov 2016 at 00:02 Prof. Diego Dujovne <[email-masked] <mailto:[email-masked]>> wrote:
>
>             Yasuyuki, Thomas,
>             2016-11-16 11:05 GMT-03:00 Thomas Watteyne <[email-masked] <mailto:[email-masked]>>:
>
>                 @Tengfei,
>                 On Fri, Nov 11, 2016 at 8:50 PM, Yasuyuki Tanaka <[email-masked] <mailto:[email-masked]>> wrote:
>
>                     Hi Tengfei,
>
>                         [email-masked] <mailto:[email-masked]>
>                     [email-masked] <mailto:[email-masked]>
>                 www.thomaswatteyne.com <http://www.thomaswatteyne.com>
>                 [email-masked] <mailto:[email-masked]>
>             www.ingenieria.udp.cl <http://www.ingenieria.udp.cl>
>             (56 2) 676 8125
>
>
>
>
>     --
>     DIEGO DUJOVNE
>     Profesor Asociado
>     www.ingenieria.udp.cl <http://www.ingenieria.udp.cl>
>     (56 2) 676 8125
>
>
>

---

From: Thomas Watteyne <[email-masked]>
Date: Sun, 20 Nov 2016 17:37:18 +0100

Yatch,
Please see inline.

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

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

> In fact, SF0 cannot tell which neighbor is the previous preferred
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?

>> On Thu, 17 Nov 2016 at 00:11 Prof. Diego Dujovne <
>> [email-masked] <mailto:[email-masked]>> wrote:
>>
>>     Thomas,
>> [email-masked] <mailto:[email-masked]>> wrote:
>>
>>             Yasuyuki, Thomas,
>>             2016-11-16 11:05 GMT-03:00 Thomas Watteyne <
>> [email-masked] <mailto:[email-masked]>>:
>>
>>                 @Tengfei,
>> [email-masked] <mailto:[email-masked]>>
>> wrote:
>>
>>                     Hi Tengfei,
>>
>>                            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/
>>                         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,

Thomas Watteyne, PhD

www.thomaswatteyne.com

---

From: Yasuyuki Tanaka <[email-masked]>
Date: Mon, 21 Nov 2016 13:08:12 +0100

Hi Thomas,

> 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?

This is right. But, I don't think it's a SF0 job. The thing is that
SF0 knows nothing about RPL.

If SF0 provided an API to send CLEAR to a particular neighbor, RPL
could trigger the CLEAR request to a previous preferred parent on its
parent switch, I guess.

Best,
Yatch

---

From: Thomas Watteyne <[email-masked]>
Date: Mon, 21 Nov 2016 14:23:48 +0100

Yatch,

Hmm, good point. I'm with you that have SF0 be independent from higher
layer stuff is the right design approach.

But SF0 doesn't really offer any API for upper-layers (it would be against
its "minimal" nature). Could we say something to the effect that, if SF0
realizes connection to a particular neighbor is no longer needed (for
example a change in parent by the routing protocol) SF0 MAY send CLEAR
requests to neighbor to speed up the cleanup process of the cells with that
neighbors?

Thomas

Thomas Watteyne, PhD

www.thomaswatteyne.com

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Mon, 21 Nov 2016 10:26:09 -0300

Yatch,
         From my point of view, the only entities allowed
to talk to 6P are the SFs, so a clear command should
be triggered by the SF. From the point of view of the
SF, there will be no more effectively used cells towards
that particular neighbour, thus reducing the number of
cells to the OVERPROVISION value.
Regards,

                                 Diego

---

From: Yasuyuki Tanaka <[email-masked]>
Date: Mon, 21 Nov 2016 15:17:31 +0100

Hi Thomas,

> Could we say something to the effect that, if SF0 realizes
> connection to a particular neighbor is no longer needed (for example
> a change in parent by the routing protocol) SF0 MAY send CLEAR
> requests to neighbor to speed up the cleanup process of the cells
> with that neighbors?

I guess so. I would say it's a use-case description for CLEAR. To me,
it seems the 6P draft is a right place to add something as you
suggested. In that sense, "SF0" in the text above could be replaced
with "SF", anonymous one:

    If a SF realizes connection to a particular neighbor is no longer
    needed (for example a change in parent by the routing protocol),
    the SF MAY send CLEAR requests to the neighbor to speed up the
    cleanup process of the cells with that neighbors.

# Honestly, I'm not sure what "with that neighbors" suggested...

By the way, the API thing I mentioned is a hypothetical scenario; I
respect the "minimal" nature of SF0. :-)

Best,
Yatch

---

From: Yasuyuki Tanaka <[email-masked]>
Date: Mon, 21 Nov 2016 15:19:02 +0100

Thank you, Diego.

I believe I have correct understanding as you explained.

Best,
Yatch

On 2016/11/21 14:26, Prof. Diego Dujovne wrote:
> 2016-11-21 9:08 GMT-03:00 Yasuyuki Tanaka <[email-masked] <mailto:[email-masked]>>:
>
>     Hi Thomas,
>
>     https://www.ietf.org/mailman/listinfo/6tisch <https://www.ietf.org/mailman/listinfo/6tisch>
>
>
>
>
> --
> DIEGO DUJOVNE
> Profesor Asociado

---

From: Michael Richardson <[email-masked]>
Date: Mon, 21 Nov 2016 11:10:45 -0500

Yasuyuki Tanaka <[email-masked]> wrote:
    >> previous preferred parent to waste energy listening to those. A CLEAR
    >> wouldn't hurt, right?

    > This is right. But, I don't think it's a SF0 job. The thing is that SF0
    > knows nothing about RPL.

    > could trigger the CLEAR request to a previous preferred parent on its

Your SF0 layer could provide whatever internal API it wants to your RPL
implementation.  This is hardly a standardization issue or problem; this is a
quality of implementation issue.

The observation of *when* RPL should clear traffic reservation may have some
impact on the SF0 protocol, but I'd think it would be just some
implementation advice.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Thomas Watteyne <[email-masked]>
Date: Tue, 22 Nov 2016 08:03:56 +0100

Yatch,
Agreed. Let's me start a different thread where I summarize your suggestion
and ask for WG consensus.
Thomas

Thomas Watteyne, PhD

www.thomaswatteyne.com