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.dujo...@mail.udp.cl <mailto:diego.dujo...@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.watte...@inria.fr <mailto:thomas.watte...@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.dujo...@mail.udp.cl <mailto: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 <thomas.watte...@inria.fr <mailto:thomas.watte...@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.tan...@toshiba.co.jp <mailto: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 <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
