Tengfei, all, the idea of relocation is very useful, I agree. A RELOCATE command would require the same reliable process for maintaining the schedule knowledge consistent between both sides of the transaction. Which is in practice identical to that of an ADD command.
Maybe it is possible to use the same abstract command to make add/relocate with the same kind of reliable process (request, response). Add and relocate operation have much more in common than a delete command (there is only a one-way packet in that transaction). What do you think? Nicola 2016-11-02 16:09 GMT+01:00 Prof. Diego Dujovne <[email protected]>: > Pascal, > The relocation process from SF0 is meant > also to detect collisions after random allocation, among > other sources of packet loss, such as narrowband > interference or noise. > Regards, > > Diego > > 2016-11-02 12:06 GMT-03:00 Pascal Thubert (pthubert) <[email protected]>: > >> Hello Tengfei; >> >> >> >> this looks very useful in the context of the minimal cell allocation >> (Xavi’s random appropriation and collision detection). >> >> >> >> Take care, >> >> >> >> Pascal >> >> >> >> *From:* 6tisch [mailto:[email protected]] *On Behalf Of *Tengfei >> Chang >> *Sent:* mercredi 2 novembre 2016 15:47 >> *To:* [email protected] >> *Subject:* [6tisch] [6TISCH] RELOCATE command in sixtop? >> >> >> >> All, >> >> >> >> I would like to propose an idea to add a new command called RELOCATE >> command in sixtop. >> >> This RELOCATE sixtop command will contains the cells to be added and >> removed in single packet. >> >> >> >> Without RELOCATE command, the relocation is done through adding one cell >> first then deleting one cell. >> >> With RELOCATE command, once the sixtop transaction for relocation >> successes, the relocation process is done. >> >> >> >> There are several benefit from RELOCATE: >> >> >> >> 1.save overhead of relocation process. >> >> 2. avoid the influence of relocation on SF0. It requires SF0 to take the >> relocation into consideration if the cell is added through relocation or >> not. SF0 may take different decision. >> >> >> >> What do you think? >> >> >> >> Tengfei >> >> >> >> >> >> >> -- >> >> Chang Tengfei, >> >> Pre-Postdoctoral Research Engineer, Inria >> >> _______________________________________________ >> 6tisch mailing list >> [email protected] >> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch > >
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
