Re: [6tisch] 6P and Sf0 issue: 6top protocol behaviour at boot
Correct Diego And that's a desired effect so that a node gets a lot of bandwidth to complete its join. You better complete a few at a time then have hundreds half way through and none fully done. We may actually reject a join if the queue is too long, exhausting=sleep well and come back in 10 Take care, Pascal Le 11 mars 2016 ? 00:25, Prof. Diego Dujovne mailto:diego.dujo...@mail.udp.cl>> a ?crit : Pascal, I was thinking of a worst-case condition: all neighbours are willing to join. A limited pool would satisfy only a part of them, thus putting the rest of the nodes in a join queue. Am I correct? Regards, Diego 2016-03-04 7:55 GMT-03:00 Pascal Thubert (pthubert) mailto:pthub...@cisco.com>>: Hello Diego: One suggestion would be that when a node attempts to join, the parent immediately grants a set of cells for the join process from a limited pool (to avoid DDOS). These cells are to be released at the end of the join and are there to boost the bandwidth for that critical phase. Cheers, Pascal From: 6tisch [mailto:6tisch-boun...@ietf.org<mailto:6tisch-boun...@ietf.org>] On Behalf Of Prof. Diego Dujovne Sent: jeudi 3 mars 2016 17:12 To: 6tisch@ietf.org<mailto:6tisch@ietf.org> Subject: [6tisch] 6P and Sf0 issue: 6top protocol behaviour at boot Dear all, Although it was discussed, there is no specification on the 6top behaviour at boot. The discussion point here is if the 6top messages shall be transmitted on minimal cells until the slotframe 1 (SFR1) has been populated enough to support the transactions. - The use of minimal is optional. In case minimal is used, the decision on when to switch is out of scope? - In case minimal is not used, shall we specify another mechanism to enable 6top to transmit messages? Thanks! Regards, Diego Dujovne -- DIEGO DUJOVNE Acad?mico Escuela de Ingenier?a en Inform?tica y Telecomunicaciones Facultad de Ingenier?a UDP www.ingenieria.udp.cl<http://www.ingenieria.udp.cl> (56 2) 676 8125 -- DIEGO DUJOVNE Acad?mico Escuela de Ingenier?a en Inform?tica y Telecomunicaciones Facultad de Ingenier?a UDP 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
Re: [6tisch] 6P and Sf0 issue: 6top protocol behaviour at boot
Pascal, I was thinking of a worst-case condition: all neighbours are willing to join. A limited pool would satisfy only a part of them, thus putting the rest of the nodes in a join queue. Am I correct? Regards, Diego 2016-03-04 7:55 GMT-03:00 Pascal Thubert (pthubert) : > Hello Diego: > > > > One suggestion would be that when a node attempts to join, the parent > immediately grants a set of cells for the join process from a limited pool > (to avoid DDOS). These cells are to be released at the end of the join and > are there to boost the bandwidth for that critical phase. > > > > Cheers, > > > > Pascal > > > > *From:* 6tisch [mailto:6tisch-boun...@ietf.org] *On Behalf Of *Prof. > Diego Dujovne > *Sent:* jeudi 3 mars 2016 17:12 > *To:* 6tisch@ietf.org > *Subject:* [6tisch] 6P and Sf0 issue: 6top protocol behaviour at boot > > > > Dear all, > > Although it was discussed, there is no specification > > on the 6top behaviour at boot. The discussion point here is if the > > 6top messages shall be transmitted on minimal cells until > > the slotframe 1 (SFR1) has been populated enough to support > > the transactions. > > - The use of minimal is optional. In case minimal is used, > > the decision on when to switch is out of scope? > > - In case minimal is not used, shall we specify another > > mechanism to enable 6top to transmit messages? > > Thanks! > > Regards, > > Diego Dujovne > > > -- > > DIEGO DUJOVNE > Académico Escuela de Ingeniería en Informática y Telecomunicaciones > Facultad de Ingeniería UDP > www.ingenieria.udp.cl > (56 2) 676 8125 > -- DIEGO DUJOVNE Académico Escuela de Ingeniería en Informática y Telecomunicaciones Facultad de Ingeniería UDP www.ingenieria.udp.cl (56 2) 676 8125 ___ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
Re: [6tisch] 6P and Sf0 issue: 6top protocol behaviour at boot
Hello Diego: One suggestion would be that when a node attempts to join, the parent immediately grants a set of cells for the join process from a limited pool (to avoid DDOS). These cells are to be released at the end of the join and are there to boost the bandwidth for that critical phase. Cheers, Pascal From: 6tisch [mailto:6tisch-boun...@ietf.org] On Behalf Of Prof. Diego Dujovne Sent: jeudi 3 mars 2016 17:12 To: 6tisch@ietf.org Subject: [6tisch] 6P and Sf0 issue: 6top protocol behaviour at boot Dear all, Although it was discussed, there is no specification on the 6top behaviour at boot. The discussion point here is if the 6top messages shall be transmitted on minimal cells until the slotframe 1 (SFR1) has been populated enough to support the transactions. - The use of minimal is optional. In case minimal is used, the decision on when to switch is out of scope? - In case minimal is not used, shall we specify another mechanism to enable 6top to transmit messages? Thanks! Regards, Diego Dujovne -- DIEGO DUJOVNE Académico Escuela de Ingeniería en Informática y Telecomunicaciones Facultad de Ingeniería UDP 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] 6P and Sf0 issue: 6top protocol behaviour at boot
Dear all, Although it was discussed, there is no specification on the 6top behaviour at boot. The discussion point here is if the 6top messages shall be transmitted on minimal cells until the slotframe 1 (SFR1) has been populated enough to support the transactions. - The use of minimal is optional. In case minimal is used, the decision on when to switch is out of scope? - In case minimal is not used, shall we specify another mechanism to enable 6top to transmit messages? Thanks! Regards, Diego Dujovne -- DIEGO DUJOVNE Académico Escuela de Ingeniería en Informática y Telecomunicaciones Facultad de Ingeniería UDP www.ingenieria.udp.cl (56 2) 676 8125 ___ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
