Subject: [6tisch] chunk definition

From: Maria Rita PALATTELLA <[email-masked]>
Date: Sun, 15 Dec 2013 02:06:38 +0000

•chunk: list of not-contiguous (i.e., well-distributed in time and frequency) unscheduled cells within the schedule. Chunks can be pre-programmed in a static schedule, or can be computed with the schedule by the PCE. Thus, the Slotframe will be formatted into chunks, each one identified by a chunk-ID.

A node (typically a RPL parent) looking for unscheduled cells, can claim a given chunk and auto-configure it (i.e., allocate the cells of the chunk to its children into bundles).

All, this is a potential definition of chunk. Let's discuss on the ML and converge to a final definition to be included in the terminology draft.

Please note that I will be traveling in West Africa in the following 3 weeks, an I will have very limit Internet access.
Thus, I will not be able to reply to your comments. sorry for that.

Wish all of you a great Xmas time, and all the best for 2014.
Maria Rita

---

From: Thomas Watteyne <[email-masked]>
Date: Mon, 16 Dec 2013 17:52:48 -0800

Maria Rita,
Happy travels!!

All,
When I read it, the definition seems to indicate that the cells in a chunk
cannot be contiguous. I would suggest to replace this by "not necessarily
contiguous" to.

Pascal,
Could you write up a sentence or two indicating when chunks are used. The
definitions currently indicates how a node can "get" a chunk, but not what
it does with it. I believe these sentences will be a great help for
steering the conversation,

Thomas

On Sat, Dec 14, 2013 at 6:06 PM, Maria Rita PALATTELLA <
[email-masked]> wrote:

>
>  •chunk: list of not-contiguous (i.e., well-distributed in time and
> frequency) unscheduled cells within the schedule. Chunks can be pre-programmed
> in a static schedule, or can be computed with the schedule by the PCE.
> Thus, the Slotframe will be formatted into chunks, each one identified by
> a chunk-ID.
>
> A node (typically a RPL parent) looking for unscheduled cells, can claim a
> given chunk and auto-configure it (i.e., allocate the cells of the chunk to
> its children into bundles).
>
> All, this is a potential definition of chunk. Let's discuss on the ML and
> converge to a final definition to be included in the terminology draft.
>
> Please note that I will be traveling in West Africa in the following 3
> weeks, an I will have very limit Internet access.
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 18 Dec 2013 15:26:23 +0000

What about this, Thomas?

.chunk: a well-known list of non-contiguous (i.e., well-distributed in time and frequency) cells within the schedule; a chunk represents a portion of the schedule that can be managed separately by an individual node. Chunks can be pre-programmed in a static schedule, or can be computed with the schedule by the PCE when the network bootstraps.

The Slotframe is formatted into chunks, each one identified by a unique chunk-ID. Chunks are used as a unit of delegation in order to group the processes of appropriation, as opposed to performing it on a per-cell basis. The PCE will grab a number of chunks for its own use, and eventually leave some other chunks free for its children to manage.

Chunks can be delegated explicitly by the PCE  to a node, or claimed autonomically by any node that participates to the distributed management of the schedule.  That node is typically a RPL parent looking for additional bandwidth to communicate with its children. A node is entitled to autoconfigure a chunk that does not appear to be used in the vicinity (there is no energy on the reference cells of that chunk)  and claim it by flooding a perimeter of interference, for instance using the trickle algorithm (MPL).

After a successful claiming phase, the node owns the chunk, IOW it is implicitly delegated the right to manage the portion of the schedule that is represented by the chunk. The node may thus orchestrate which transmissions will occur in any of the cells in the chunk. Initially, those cells are added to the heap of free cells, and then dynamically placed into existing bundles, in new bundles, or allocated opportunistically for one transmission. 

When possible, the node should allocate the reference cells in the chunk to constant traffic in order to ensure that the neighbors can easily discover 
that this chunk is in use.

Cheers,

Pascal

From: 6tisch [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: lundi 16 décembre 2013 17:53
To: Maria Rita PALATTELLA
Cc: [email-masked]
Subject: Re: [6tisch] chunk definition

Maria Rita,
Happy travels!!

All,
When I read it, the definition seems to indicate that the cells in a chunk cannot be contiguous. I would suggest to replace this by "not necessarily contiguous" to.

Pascal,
Could you write up a sentence or two indicating when chunks are used. The definitions currently indicates how a node can "get" a chunk, but not what it does with it. I believe these sentences will be a great help for steering the conversation,

Thomas

On Sat, Dec 14, 2013 at 6:06 PM, Maria Rita PALATTELLA <[email-masked]> wrote:

.chunk: list of not-contiguous (i.e., well-distributed in time and frequency) unscheduled cells within the schedule. Chunks can be pre-programmed in a static schedule, or can be computed with the schedule by the PCE. Thus, the Slotframe will be formatted into chunks, each one identified by a chunk-ID.
A node (typically a RPL parent) looking for unscheduled cells, can claim a given chunk and auto-configure it (i.e., allocate the cells of the chunk to its children into bundles).

---

From: Qin Wang <[email-masked]>
Date: Thu, 19 Dec 2013 06:37:16 +0800

Pascal,

I'm a little bit confused by the term "schedule" you used to describe
chunk. According to my understanding, schedule is a data structure set by
6top and used by TSCH to communicate. But a chunk is a set of cells managed
inside 6top sublayer, and cannot be seen by TSCH directly. Thus, chunk
should not be a list of cells within that schedule. Right?

Thanks
Qin

On Wed, Dec 18, 2013 at 11:26 PM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

> What about this, Thomas?
>
> .chunk: a well-known list of non-contiguous (i.e., well-distributed in
> time and frequency) cells within the schedule; a chunk represents a portion
> of the schedule that can be managed separately by an individual node.
> Chunks can be pre-programmed in a static schedule, or can be computed with
> the schedule by the PCE when the network bootstraps.
>
> The Slotframe is formatted into chunks, each one identified by a unique
> chunk-ID. Chunks are used as a unit of delegation in order to group the
> processes of appropriation, as opposed to performing it on a per-cell
> basis. The PCE will grab a number of chunks for its own use, and eventually
> leave some other chunks free for its children to manage.
>
> Chunks can be delegated explicitly by the PCE  to a node, or claimed
> autonomically by any node that participates to the distributed management
> of the schedule.  That node is typically a RPL parent looking for
> additional bandwidth to communicate with its children. A node is entitled
> to autoconfigure a chunk that does not appear to be used in the vicinity
> (there is no energy on the reference cells of that chunk)  and claim it by
> flooding a perimeter of interference, for instance using the trickle
> algorithm (MPL).
>
> After a successful claiming phase, the node owns the chunk, IOW it is
> implicitly delegated the right to manage the portion of the schedule that
> is represented by the chunk. The node may thus orchestrate which
> transmissions will occur in any of the cells in the chunk. Initially, those
> cells are added to the heap of free cells, and then dynamically placed into
> existing bundles, in new bundles, or allocated opportunistically for one
> transmission.
>
> When possible, the node should allocate the reference cells in the chunk
> to constant traffic in order to ensure that the neighbors can easily
> discover
> .chunk: list of not-contiguous (i.e., well-distributed in time and
> frequency) unscheduled cells within the schedule. Chunks can be
> pre-programmed in a static schedule, or can be computed with the schedule
> by the PCE. Thus, the Slotframe will be formatted into chunks, each one
> identified by a chunk-ID.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 19 Dec 2013 06:28:20 +0000

I understand Qin,

Maybe I should use slotframe?

The idea is that when a well is allocated, it is taken from the heap of free cells and placed in the schedule.

Would you suggest a rewording?

Cheers,

Pascal

From: Qin Wang [mailto:[email-masked]]
Sent: mercredi 18 décembre 2013 14:37
To: Pascal Thubert (pthubert)
Cc: Thomas Watteyne; Maria Rita PALATTELLA; [email-masked]
Subject: Re: [6tisch] chunk definition

Pascal,

I'm a little bit confused by the term "schedule" you used to describe chunk. According to my understanding, schedule is a data structure set by 6top and used by TSCH to communicate. But a chunk is a set of cells managed inside 6top sublayer, and cannot be seen by TSCH directly. Thus, chunk should not be a list of cells within that schedule. Right?

Thanks
Qin

On Wed, Dec 18, 2013 at 11:26 PM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
What about this, Thomas?

Cheers,

Pascal

From: 6tisch [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Thomas Watteyne
Sent: lundi 16 décembre 2013 17:53
To: Maria Rita PALATTELLA
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [6tisch] chunk definition

Maria Rita,
Happy travels!!

All,

Pascal,

Thomas

On Sat, Dec 14, 2013 at 6:06 PM, Maria Rita PALATTELLA <[email-masked]<mailto:[email-masked]>> wrote:

_______________________________________________
6tisch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tisch

_______________________________________________
6tisch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tisch

---

From: Qin Wang <[email-masked]>
Date: Thu, 19 Dec 2013 22:06:41 +0800

Pascal,

I think slotframe is suitable. Here is my suggestion of rewording, not many
difference from original one.

.chunk: a well-known list of non-contiguous (i.e., well-distributed in time
and frequency) cells within a slotframe; a chunk represents a portion of a
slotframe that can be managed separately by an individual node. Chunks can
be pre-programmed, or can be computed by the PCE when the network
bootstraps.

Chunks can be delegated explicitly by the PCE  to a node, or
claimed automatically by any node that participates to the distributed
cell scheduling process.  That node is typically a RPL parent looking for
additional bandwidth to communicate with its children. A node is entitled
to autoconfigure a chunk that does not appear to be used in the vicinity
(there is no energy on the reference cells of that chunk)  and claim it by
flooding a perimeter of interference, for instance using the trickle
algorithm (MPL).

After a successful claiming phase, the node owns the chunk, IOW it is
implicitly delegated the right to manage the portion of the cells that is
represented by the chunk. The node may thus orchestrate which transmissions
will occur in any of the cells in the chunk. Initially, those cells are
added to the heap of free cells, and then dynamically placed into existing
bundles, in new bundles, or allocated opportunistically for one
transmission.

When possible, the node should allocate the reference cells in the chunk to
constant traffic in order to ensure that the neighbors can easily discover
that this chunk is in use.

What do you think?

Qin

On Thu, Dec 19, 2013 at 2:28 PM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

> *From:* Qin Wang [mailto:[email-masked]]
> *Sent:* mercredi 18 décembre 2013 14:37
> *To:* Pascal Thubert (pthubert)
> *Cc:* Thomas Watteyne; Maria Rita PALATTELLA; [email-masked]
>
> *Subject:* Re: [6tisch] chunk definition
>
>
>
> Pascal,
>
>
>

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 19 Dec 2013 11:58:54 -0800

Pascal, all,

I believe the text above explains several use cases (PCE allocating,
parents managing  for children, node claiming); the definition could be
more "generic", i.e. just indicating that chunks are a group of cells
identified by a chunkID.

Quick question: if node A wants to add a cell to its bundle to node B,
which chunk does it use? it's own? B's?

Thomas

On Thu, Dec 19, 2013 at 6:06 AM, Qin Wang <[email-masked]> wrote:

> Pascal,
>
> I think slotframe is suitable. Here is my suggestion of rewording, not
> many difference from original one.
>
> time and frequency) cells within a slotframe; a chunk represents a portion
> of a slotframe that can be managed separately by an individual node. Chunks
> can be pre-programmed, or can be computed by the PCE when the network
> bootstraps.
>
>
>> When I read it, the definition seems to indicate that the cells in a
>> chunk cannot be contiguous. I would suggest to replace this by "not
>> necessarily contiguous" to.
>>
>> Pascal,
>> A node (typically a RPL parent) looking for unscheduled cells, can claim
>> a given chunk and auto-configure it (i.e., allocate the cells of the chunk
>> to its children into bundles).
>>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 19 Dec 2013 22:41:56 +0000

Hello Thomas:

I agree. If we decide to use chunks then that text could end up in the Archie. For your definition, I think we need to differentiate from a bundle. The bundle matches an active link whereas a chunk relates to management responsibility.

As you indicate below,all there is to a chunk is really to group the process by which a node obtains the cells it needs to manage mocally the associated portion of its slotframe. It needs some kind of cell budget, and a new chunk is like a funding round...

If the design point is that the RPL parent allocates the cell, then the parent picks from its pool of free cells for both directions.

For RSVP-TE style A to B cell allocation, we'll have to decide. Intuitively I'd go for B providing the cell to A - just like it would provide a label - as part of the return path, what do you think?

Pascal

Le 19 déc. 2013 à 11:59, "Thomas Watteyne" <[email-masked]<mailto:[email-masked]>> a écrit :

Pascal, all,

I believe the text above explains several use cases (PCE allocating, parents managing  for children, node claiming); the definition could be more "generic", i.e. just indicating that chunks are a group of cells identified by a chunkID.

Quick question: if node A wants to add a cell to its bundle to node B, which chunk does it use? it's own? B's?

Thomas

On Thu, Dec 19, 2013 at 6:06 AM, Qin Wang <[email-masked]<mailto:[email-masked]>> wrote:
Pascal,

I think slotframe is suitable. Here is my suggestion of rewording, not many difference from original one.

.chunk: a well-known list of non-contiguous (i.e., well-distributed in time and frequency) cells within a slotframe; a chunk represents a portion of a slotframe that can be managed separately by an individual node. Chunks can be pre-programmed, or can be computed by the PCE when the network bootstraps.

Chunks can be delegated explicitly by the PCE  to a node, or claimed automatically by any node that participates to the distributed cell scheduling process.  That node is typically a RPL parent looking for additional bandwidth to communicate with its children. A node is entitled to autoconfigure a chunk that does not appear to be used in the vicinity (there is no energy on the reference cells of that chunk)  and claim it by flooding a perimeter of interference, for instance using the trickle algorithm (MPL).

After a successful claiming phase, the node owns the chunk, IOW it is implicitly delegated the right to manage the portion of the cells that is represented by the chunk. The node may thus orchestrate which transmissions will occur in any of the cells in the chunk. Initially, those cells are added to the heap of free cells, and then dynamically placed into existing bundles, in new bundles, or allocated opportunistically for one transmission.

What do you think?

Qin

On Thu, Dec 19, 2013 at 2:28 PM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
I understand Qin,

Cheers,

Pascal

From: Qin Wang [mailto:[email-masked]<mailto:[email-masked]>]
Sent: mercredi 18 décembre 2013 14:37
To: Pascal Thubert (pthubert)
Cc: Thomas Watteyne; Maria Rita PALATTELLA; [email-masked]<mailto:[email-masked]>

Pascal,

Thanks
Qin

Cheers,

Pascal

Maria Rita,
Happy travels!!

All,

Pascal,

Thomas

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 20 Dec 2013 14:47:05 +0000

I love it, Qin;

Let us conclude at the call.

We may need to define delegation and appropriation, which are the processes by which the PCE gives away the control of a chunk to a device, and the process by which a device takes over that control in an more autonomic fashion, like an autoconf.

Cheers,

Pascal

Sent: jeudi 19 décembre 2013 15:07

Pascal,

What do you think?

Qin

Cheers,

Pascal

Pascal,

Thanks
Qin

Cheers,

Pascal

Maria Rita,
Happy travels!!

All,

Pascal,

Thomas