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

[Thomas Watteyne]

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

On Mon, Nov 21, 2016 at 5:10 PM, Michael Richardson 
wrote:

>
> Yasuyuki Tanaka  wrote:
> >> 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.
>
> 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 , Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
>
> ___
> 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
___
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

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

[Michael Richardson]

Yasuyuki Tanaka  wrote:
>> 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.

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 , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

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

[Yasuyuki Tanaka]

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

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

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

[Thomas Watteyne]

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

On Mon, Nov 21, 2016 at 1:08 PM, Yasuyuki Tanaka <
yasuyuki9.tan...@toshiba.co.jp> wrote:

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


-- 
___

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
___
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

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

[Yasuyuki Tanaka]

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

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

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

[Yasuyuki Tanaka]

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

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

@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 
> 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 
].
  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 
https://www.ietf.org/mailman/listinfo/6tisch


___
6tisch mailing list

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

[Thomas Watteyne]

That would be perfect, thanks!

On Thu, 17 Nov 2016 at 00:11 Prof. Diego Dujovne 
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 :
>
> 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.dujo...@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 :
>
> @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.tan...@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
> 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
> ___
>
> ___
> 6tisch mailing list
> 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
> (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
> (56 2) 676 8125
>
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

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

[Prof. Diego Dujovne]

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 :

> 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.dujo...@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 :
>>
>> @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.tan...@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
>> 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
>> ___
>>
>> ___
>> 6tisch mailing list
>> 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
>> (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
(56 2) 676 8125
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

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

[Thomas Watteyne]

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 
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 :
>
> @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.tan...@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
> 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
> ___
>
> ___
> 6tisch mailing list
> 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
> (56 2) 676 8125
>
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

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

[Prof. Diego Dujovne]

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

   Diego

2016-11-16 11:05 GMT-03:00 Thomas Watteyne :

> @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.tan...@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#r
>>> ef-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
>>> 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
> ___
>
> ___
> 6tisch mailing list
> 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
(56 2) 676 8125
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

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

[Tengfei Chang]

@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

On Wed, Nov 16, 2016 at 3:05 PM, Thomas Watteyne 
wrote:

> @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.tan...@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#r
>>> ef-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
>>> 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
> ___
>
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
>


-- 
Chang Tengfei,
Pre-Postdoctoral Research Engineer, Inria
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

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

[Thomas Watteyne]

@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.tan...@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#r
>> ef-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
>> 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
___
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

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

[Tengfei Chang]

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
].
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
https://www.ietf.org/mailman/listinfo/6tisch