Subject: [6tisch] proposing text for the archi draft based on ML discussion

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 11 Feb 2014 08:15:38 +0000

Dear all:

I tried to summarize the agreement  / understanding we had on chunks in the following text.
Please comment; the plan is to publish a new architecture draft before cutoff.
Also, if you see that some items we discussed recently - apart from security which is starting a parallel path - are missing and should be added, please shime in.

"
7.5.  Distributing the reservation of timeslots

   6TiSCH expects a high degree of scalability together with a
   distributed routing functionality based on the RPL routing protocol.
   To achieve this goal, the spectrum must be allocated in a way that
   allows for spatial reuse between zones that will not interfere with
   one another.  In a large and spatially distributed network, a 6TiSCH
   node is in a better position to determine usage of spectrum in its
   vicinity than a centralized PCE that cannot directly measure energy
   in the wireless medium within the interference domain around the
   6TiSCH node.

   Additionally, going to a centralized PCE to allocate any single cell
   becomes increasingly costly on network resources as the system grows,
   and would not scale; nor would a design whereby each node would need
   to negotiate with each interfering neighbour for the use of any
   individual cell.  6TiSCH limits that interaction to RPL parents that
   will only negotiate with other RPL parents, and performs that
   negotiation by groups of cells as opposed to individual cells.  It is
   thus a 6TiSCH design point that RPL parents adjust dynamically and
   independently from the PCE the amount of bandwidth that is used to
   communicate between self and their children, in both directions; to
   do so, RPL parents distribute between themselves and interfering
   neighbor parents the virtual spectrum that is formed by the set of
   cells in the slotframe.

   The concept of chunk [I-D.ietf-6tisch-terminology]) is introduced to
   group cells for this operation of spectrum distribution.  The
   slotframe is formatted into chunks in a manner that is well-known by
   all nodes in the 6TiSCH network, each chunk identified by a unique
   chunk-ID.  6TiSCH defines the process of chunk ownership
   appropriation whereby a RPL parent detects that a chunk that is not
   owned in its interference domain, (e.g lack of energy detected in
   reference cells in that chunk) claims the chunk, and defends it in
   case another RPL parent would next attempt to appropriate the chunk
   while this parent still uses it.  The chunks is the basic unit of
   ownership that is used in that process.

   As a result of the process of chunk ownership appropriation, a RPL
   parent is the sole authority to decide which cell in the appropriated
   chunk can be used by which node in its interference domain.  IOW, it
   is implicitly delegated the right to manage the portion of the
   slotframe that is represented by the chunk.  The RPL parent may thus
   orchestrate which transmissions will occur in any of the cells in the
   chunk, by allocating cells from the chunk to any form of
   communication (unicast, multicast) in any direction between self and
   its children.  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.

   Chunks can also be delegated explicitly by the PCE to any node, in
   which case the node still needs to perform the appropriation process
   to validate that no other node has claimed that chunk already.  In
   case of successful appropriation, the PCE owns the cells in that
   chunk, and may use them as hard cells to set up tracks.

"

Pascal

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Tue, 11 Feb 2014 10:45:14 +0000

Thanks Pascal for having wrote such description of the chunk. It clearly shows where the need of chunk comes from, what a chunk is, and how it works.
I have only few minor comments/suggested changes (they are included among **). Feel free to consider/ignore them.
Thanks
Maria Rita

   **Moreover, the allocation of any single cell operated by a centralized PCE**
   becomes increasingly costly on network resources as the system grows,
   and would not scale; nor would a design whereby each node would need
   to negotiate with each interfering neighbour for the use of any
   individual cell.  6TiSCH limits that interaction to RPL parents that
   will only negotiate with other RPL parents, and performs that
   negotiation by groups of cells as opposed to individual cells.
   ** Thus, in 6TiSCH it has been designed**
  that RPL parents adjust dynamically and
   independently from the PCE the amount of bandwidth that is used to
   communicate between **them**self and their children, in both directions; to
   do so, RPL parents distribute between themselves and **the**  interfering
   neighbor parents the virtual spectrum that is formed by the set of
   cells in the slotframe.

   **To operate such spectrum distribution the concept of chunk [I-D.ietf-6tisch-terminology]) has been  introduced 
  for grouping cells. The
   slotframe is formatted into a set of chunks, each of them identified by a unique
   chunk-ID.  All nodes in the 6TiSCH network know about slotframe's formatting into chunks.
   6TiSCH defines the process of chunk ownership
   appropriation whereby a RPL parent detects a chunk that is not
   owned in its interference domain, (e.g.,  lack of energy detected in
   reference cells in that chunk); then it claims the chunk, and defends it in
   case another RPL parent  attempt to appropriate the chunk
   while it is still using it.**  The chunks is the basic unit of
   ownership that is used in that process.

   parent is the **only** authority to decide which cell in the appropriated
   communication (unicast, multicast) in any direction between **them** self and

*****Question: this last paragraph is not clear to me. In the first part you talk of delegation from the PCE to the node. In the second part, in case of appropriation, it is the PCE to owns the cells...From my understanding, it should be the node to owns them. Am I missing something?*************

-----Original Message-----
From: 6tisch [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: Tuesday, February 11, 2014 9:16 AM
To: [email-masked]
Cc: Thomas Watteyne ([email-masked]); Robert Assimiti
Subject: [6tisch] proposing text for the archi draft based on ML discussion

Dear all:

"

"

Pascal

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 11 Feb 2014 11:01:06 +0000

Thanks a bunch Maria Rita:

I have a terminology question for you. I want to represent the "matrix" and how chunks are mapped into that "matrix".

                +-----+-----+-----+-----+-----+-----+-----+     +-----+

   chan.Off. 0  |chnkA|chnkP|chnk7|chnkO|chnk2|chnkK|chnk1| ... |chnkZ|

                +-----+-----+-----+-----+-----+-----+-----+     +-----+

   chan.Off. 1  |chnkB|chnkQ|chnkA|chnkP|chnk3|chnkL|chnk2| ... |chnk1|

                +-----+-----+-----+-----+-----+-----+-----+     +-----+

                  ...

                +-----+-----+-----+-----+-----+-----+-----+     +-----+

   chan.Off. 15 |chnkO|chnk6|chnkN|chnk1|chnkJ|chnkZ|chnkI| ... |chnkG|

                +-----+-----+-----+-----+-----+-----+-----+     +-----+

                   0     1     2     3     4     5     6          M

Now, I'm wondering how we call that "matrix". Not a slotframe since that are multiple slotframes, all instantiations of the matrix but overlayed on one another.

Not the schedule since that is a local construct by everynode. So what's the term I should use?

I my text I started with "virtual spectrum". Dowe have something better, more appropriate?

Cheers,

Pascal

> From: Maria Rita PALATTELLA [mailto:[email-masked]]

> Sent: mardi 11 février 2014 11:45

> To: Pascal Thubert (pthubert); [email-masked]

> Subject: RE: proposing text for the archi draft based on ML discussion

> Thanks Pascal for having wrote such description of the chunk. It clearly shows

> where the need of chunk comes from, what a chunk is, and how it works.

> I have only few minor comments/suggested changes (they are included among

> **). Feel free to consider/ignore them.

>    **To operate such spectrum distribution the concept of chunk [I-D.ietf-6tisch-

> terminology]) has been  introduced

>    slotframe is formatted into a set of chunks, each of them identified by a

> unique

>    chunk-ID.  All nodes in the 6TiSCH network know about slotframe's formatting

> into chunks.

>    communication (unicast, multicast) in any direction between **them** self

> and

> *****Question: this last paragraph is not clear to me. In the first part you talk of

> delegation from the PCE to the node. In the second part, in case of

> appropriation, it is the PCE to owns the cells...From my understanding, it should

> be the node to owns them. Am I missing something?*************

> From: 6tisch [mailto:[email-masked]] On Behalf Of Pascal Thubert

> (pthubert)

> To: [email-masked]<mailto:[email-masked]>

> Cc: Thomas Watteyne ([email-masked]<mailto:[email-masked]>); Robert Assimiti

> I tried to summarize the agreement  / understanding we had on chunks in the

> following text.

> Also, if you see that some items we discussed recently - apart from security

> which is starting a parallel path - are missing and should be added, please shime

> in.

> [email-masked]<mailto:[email-masked]>

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Tue, 11 Feb 2014 12:54:20 +0000

Pascal, first of all, let me check if we are well aligned.

Such "matrix" summarizes all the chunks belonging to different parent nodes. For each nodes, the chunks  may be formed by cells belonging to different slotframe. Is it right?
The height of the matrix is equal to the number of available channel offset values, while the length M is a function of the overlapping among concurrent slotframes (in case of a single slotframe, it will be equal to the sloframe size).
Such matrix does not match with the schedule, because the latter includes scheduled cells, but cells within a chunk are not necessary scheduled.

After said that, what about calling the matrix, chunk distribution matrix? Or spectrum usage/distribution matrix?

Maria Rita

From: Pascal Thubert (pthubert) [mailto:[email-masked]]
Sent: Tuesday, February 11, 2014 12:01 PM
To: Maria Rita PALATTELLA; [email-masked]
Cc: Thomas Watteyne ([email-masked]); Robert Assimiti
Subject: RE: proposing text for the archi draft based on ML discussion

                  ...

                   0     1     2     3     4     5     6          M

Cheers,

Pascal

> To: Pascal Thubert (pthubert); [email-masked]<mailto:[email-masked]>

---

From: Tom Phinney <[email-masked]>
Date: Tue, 11 Feb 2014 10:20:45 -0800

Or channel usage/distribution matrix,
since this addresses only 802.15.4 channels, not spectrum in
general (as we will have to do for more-agile next-generation
radios)?

===

On 2014.02.11 04:54, Maria Rita
PALATTELLA wrote:

Pascal, first
of all, let me check if we are well aligned.

Such “matrix”
summarizes all the chunks belonging to different parent
nodes. For each nodes, the chunks  may be formed by cells
belonging to different slotframe. Is it right?

The height of
the matrix is equal to the number of available channel
offset values, while the length M is a function of the
overlapping among concurrent slotframes (in case of a single
slotframe, it will be equal to the sloframe size).

Such matrix
does not match with the schedule, because the latter
includes scheduled cells, but cells within a chunk are not
necessary scheduled.

After said
that, what about calling the matrix,
chunk distribution matrix? Or spectrum
usage/distribution matrix?

Maria Rita

From:
Pascal Thubert (pthubert) [mailto:[email-masked]]

Cc: Thomas Watteyne ([email-masked]);
Robert Assimiti

Subject: RE: proposing text for the archi draft
based on ML discussion

I have a terminology question for you. I
want to represent the “matrix” and how chunks are mapped into
that “matrix”.

chan.Off. 0
|chnkA|chnkP|chnk7|chnkO|chnk2|chnkK|chnk1| ... |chnkZ|

chan.Off. 1
|chnkB|chnkQ|chnkA|chnkP|chnk3|chnkL|chnk2| ... |chnk1|

...

chan.Off. 15
|chnkO|chnk6|chnkN|chnk1|chnkJ|chnkZ|chnkI| ... |chnkG|

0     1     2     3
4     5     6          M

Now, I’m wondering how we call that
“matrix”. Not a slotframe since that are multiple slotframes,
all instantiations of the matrix but overlayed on one another.

Not the schedule since that is a local
construct by everynode. So what’s the term I should use?

I my text I started with “virtual
spectrum”. Dowe have something better, more appropriate?

Cheers,

Pascal

> Thanks Pascal for having wrote such
description of the chunk. It clearly shows

> I have only few minor
comments/suggested changes (they are included among

>    distributed routing
functionality based on the RPL routing protocol.

>    **Moreover, the allocation of
any single cell operated by a centralized PCE**

>    communicate between **them**self
and their children, in both directions; to

>    do so, RPL parents distribute
between themselves and **the**  interfering

>    **To operate such spectrum
distribution the concept of chunk [I-D.ietf-6tisch-

>    slotframe is formatted into a
set of chunks, each of them identified by a

>    chunk-ID.  All nodes in the
6TiSCH network know about slotframe's formatting

>    owned in its interference
domain, (e.g.,  lack of energy detected in

>    reference cells in that chunk);
then it claims the chunk, and defends it in

>    communication (unicast,
multicast) in any direction between **them** self

>    case of successful
appropriation, the PCE owns the cells in that

> *****Question: this last paragraph
is not clear to me. In the first part you talk of

> appropriation, it is the PCE to
owns the cells...From my understanding, it should

> Subject: [6tisch] proposing text
for the archi draft based on ML discussion

> Please comment; the plan is to
publish a new architecture draft before cutoff.

> which is starting a parallel path -
are missing and should be added, please shime

>    distributed routing
functionality based on the RPL routing protocol.

>    Additionally, going to a
centralized PCE to allocate any single cell

>    The concept of chunk
[I-D.ietf-6tisch-terminology]) is introduced to

>    communication (unicast,
multicast) in any direction between self and

>    case of successful
appropriation, the PCE owns the cells in that

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 12 Feb 2014 10:30:51 -0800

Pascal,

All, I believe the description of where chunks can be useful makes sense in
the architecture draft. I do oppose, however, the following statement:

   individual cell.

I have heard this statement many times, and, stated this way, is
inaccurate. Rather than going into lengthy discussions about scalability of
this or that mechanism, I propose we do not make any claims. I would much
rather present chunks as an optional mechanism which can be used by a
6TiSCH network for a variety of reasons. Once the mechanism is in place,
depending on the typo of application and the network contraints, it can be
used.

If we agree on that, I believe we should remove the text above.

Thomas

On Tue, Feb 11, 2014 at 10:20 AM, Tom Phinney <[email-masked]> wrote:

>  Or *channel usage/distribution matrix*, since this addresses only
> 802.15.4 channels, not spectrum in general (as we will have to do for
> more-agile next-generation radios)?
> ===
>  On 2014.02.11 04:54, Maria Rita PALATTELLA wrote:
>
> Such "matrix" summarizes all the chunks belonging to different parent
> nodes. For each nodes, the chunks  may be formed by cells belonging to
> different slotframe. Is it right?
>
> The height of the matrix is equal to the number of available channel
> offset values, while the length M is a function of the overlapping among
> concurrent slotframes (in case of a single slotframe, it will be equal to
> the sloframe size).
>
> Such matrix does not match with the schedule, because the latter includes
> scheduled cells, but cells within a chunk are not necessary scheduled.
>
>
>
> After said that, what about calling the matrix, *chunk distribution
> matrix*? Or *spectrum usage/distribution matrix*?
>
>
>
> Maria Rita
>
>
>
>
>
>
>
> *From:* Pascal Thubert (pthubert) [mailto:[email-masked]<[email-masked]>]
>
> *Sent:* Tuesday, February 11, 2014 12:01 PM
> *To:* Maria Rita PALATTELLA; [email-masked]
>
> *Cc:* Thomas Watteyne ([email-masked]); Robert Assimiti
> *Subject:* RE: proposing text for the archi draft based on ML discussion
>
>
>
> I have a terminology question for you. I want to represent the "matrix"
> and how chunks are mapped into that "matrix".
>
>
>
>
>
> Now, I'm wondering how we call that "matrix". Not a slotframe since that
> are multiple slotframes, all instantiations of the matrix but overlayed on
> one another.
>
> > From: Maria Rita PALATTELLA [mailto:[email-masked]<[email-masked]>
> ]
>
> > From: 6tisch [mailto:[email-masked] <[email-masked]>]
> On Behalf Of Pascal Thubert
>
> > (pthubert)
>
> 6tisch mailing [email-masked]://www.ietf.org/mailman/listinfo/6tisch
>
>
>

---

From: Qin Wang <[email-masked]>
Date: Thu, 13 Feb 2014 03:12:15 +0800

+1

Qin

On Thu, Feb 13, 2014 at 2:30 AM, Thomas Watteyne <[email-masked]
> wrote:

> Pascal,
>
> All, I believe the description of where chunks can be useful makes sense
> in the architecture draft. I do oppose, however, the following statement:
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 12 Feb 2014 19:40:50 +0000

OK then,

Though I think we are not talking about the same thing. What this text aims at saying is that going x hops to the root each time a node wishes to get (rid of) a cell in the process if dynamically changing a bundle is increasingly costly as x grows. Which seems obvious. And we are shooting for large networks.

This text is *not* referring to that old discussions on whether centralized scales and to which point; rather it discusses dynamic schedule management, which is a problem specific to distributed routing.

In any case please feel free to amend / erase that piece on the repo, I certainly agree that we canlive without it.

Cheers,

Pascal

Le 12 févr. 2014 à 20:12, "Qin Wang" <[email-masked]<mailto:[email-masked]>> a écrit :

+1

Qin

On Thu, Feb 13, 2014 at 2:30 AM, Thomas Watteyne <[email-masked]<mailto:[email-masked]>> wrote:
Pascal,

All, I believe the description of where chunks can be useful makes sense in the architecture draft. I do oppose, however, the following statement:

I have heard this statement many times, and, stated this way, is inaccurate. Rather than going into lengthy discussions about scalability of this or that mechanism, I propose we do not make any claims. I would much rather present chunks as an optional mechanism which can be used by a 6TiSCH network for a variety of reasons. Once the mechanism is in place, depending on the typo of application and the network contraints, it can be used.

Thomas

On Tue, Feb 11, 2014 at 10:20 AM, Tom Phinney <[email-masked]<mailto:[email-masked]>> wrote:
Or channel usage/distribution matrix, since this addresses only 802.15.4 channels, not spectrum in general (as we will have to do for more-agile next-generation radios)?
===
On 2014.02.11 04<tel:2014.02.11%2004>:54, Maria Rita PALATTELLA wrote:
Pascal, first of all, let me check if we are well aligned.

Such “matrix” summarizes all the chunks belonging to different parent nodes. For each nodes, the chunks  may be formed by cells belonging to different slotframe. Is it right?
The height of the matrix is equal to the number of available channel offset values, while the length M is a function of the overlapping among concurrent slotframes (in case of a single slotframe, it will be equal to the sloframe size).
Such matrix does not match with the schedule, because the latter includes scheduled cells, but cells within a chunk are not necessary scheduled.

Maria Rita

From: Pascal Thubert (pthubert) [mailto:[email-masked]]
Sent: Tuesday, February 11, 2014 12:01 PM
To: Maria Rita PALATTELLA; [email-masked]<mailto:[email-masked]>

I have a terminology question for you. I want to represent the “matrix” and how chunks are mapped into that “matrix”.

                  ...

                   0     1     2     3     4     5     6          M

Now, I’m wondering how we call that “matrix”. Not a slotframe since that are multiple slotframes, all instantiations of the matrix but overlayed on one another.

Not the schedule since that is a local construct by everynode. So what’s the term I should use?

I my text I started with “virtual spectrum”. Dowe have something better, more appropriate?

Cheers,

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 13 Feb 2014 12:32:31 +0000

Hello Thomas and Qin:

What about this replacement text ?

         Uses cases for distributed routing are often associated with a
         statistical distribution of best-effort traffic with variable needs for
         bandwidth on each individual link. With 6TiSCH, the link abstraction
         is implemented as a bundle of cells, and the size of a bundle will be
         optimal when both the energy wasted on idle listening and the packet
         drops due to congestion loss are minimized. This can be maintained if
         the number of cells in a bundle is adapted dynamically, and with enough
         reactivity, to match the variations of best-effort traffic. In turn,
         the agility to fulfil the needs for additional cells improves when the
         number of interactions with other devices and the protocol latencies
         are minimized.

Cheers,

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: mercredi 12 février 2014 19:31
To: Tom Phinney
Cc: Maria Rita PALATTELLA; Pascal Thubert (pthubert); [email-masked]; Robert Assimiti
Subject: Re: [6tisch] proposing text for the archi draft based on ML discussion

Pascal,

Thomas

Maria Rita

                  ...

                   0     1     2     3     4     5     6          M

Cheers,

Pascal

6tisch mailing list