Subject: [6tisch] [6TISCH] RELOCATE command in sixtop?

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

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 2 Nov 2016 15:06:32 +0000

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-masked]] On Behalf Of Tengfei Chang
Sent: mercredi 2 novembre 2016 15:47
To: [email-masked]
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.

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

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Wed, 2 Nov 2016 12:09:44 -0300

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

> 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-masked]] *On Behalf Of *Tengfei
> Chang
> *Sent:* mercredi 2 novembre 2016 15:47
> *To:* [email-masked]
> *Subject:* [6tisch] [6TISCH] RELOCATE command in sixtop?
>
>
>
> All,
>
>
>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> 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

---

From: Nicola Accettura <[email-masked]>
Date: Wed, 2 Nov 2016 16:45:25 +0100

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

---

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

I gather from this thread that there is a consensus on adding a RELOCATE
command to 6P.
I suggest we create an issue to capture this and take a minute from the 6P
presentation at the WG meeting tomorrow to gather feedback from the room.

-- 
_______________________________________

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
_______________________________________