Subject: [6tisch] Cell types for 6top protocol

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 8 Jan 2016 18:15:43 +0000

Dear all :

I took an action item at the 6tisch interim to address cell types in the 6top protocol:

As you know, a chunk is like a malloc heap, a set of resources that a node ( a RPL parent) attributes to be able to serve dynamic bandwidth needs with the 6top protocol.
Currently, the assumption was that the chunks are a partition of the CDU matrix, so chunks are not overlapping, and all cells in chunked space are identical, meant for dedicated unicast traffic like we foresee for tracks.
I pointed out at the interim today that for statistical traffic we may want to have overlapping chunks, in which case cells from different chunks but overlapping chunks may have a chance of collision *.
We discussed that the requester of cells in the 6top protocol may have a say on which type of cell is to be allocated, like high priority, unicast vs. shared, guaranteed non overlapping vs not.
This raises a number of questions:

1)      Do people see value in doing that?

2)      If so, should a chunk have properties, like should cells in a chunk have homogeneous properties?

3)      Should the type (unicast vs. shared) be a permanent property of the cell while it is free (it sits in a chunk), or one attributed by the parent when the cell is placed in a bundle and for the direction of that attribution?

What do you think?

Pascal

* note there is some Cisco IPR around overlapping chunks that that I need to dig if we pursue this direction.

---

From: Qin Wang <[email-masked]>
Date: Fri, 8 Jan 2016 21:59:14 +0000 (UTC)

Hi Pascal and all,
I think chunk is a good idea to avoid conflicts in cell allocation. According to my understanding, a Chunk is a part of a superframe, and thus inherits the properties of the superframe like priority. 
In the draft-ietf-6tisch-6top-interface, you can find two data structures related to Chunk, i.e. (1) ChunkList, List of the chunks assigned to the node
(2) ChunkCellList, List of all of the cells assigned to the node via the assignment of chunks
It may help to answer the questions.
ThanksQin 

    On Friday, January 8, 2016 1:16 PM, Pascal Thubert (pthubert) <[email-masked]> wrote:

  <!--#yiv8251087684 _filtered #yiv8251087684 {font-family:Wingdings;panose-1:5 0 0 0 0 0 0 0 0 0;} _filtered #yiv8251087684 {font-family:"Cambria Math";panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv8251087684 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;}#yiv8251087684 #yiv8251087684 p.yiv8251087684MsoNormal, #yiv8251087684 li.yiv8251087684MsoNormal, #yiv8251087684 div.yiv8251087684MsoNormal {margin:0cm;margin-bottom:.0001pt;font-size:11.0pt;font-family:"Calibri", sans-serif;}#yiv8251087684 a:link, #yiv8251087684 span.yiv8251087684MsoHyperlink {color:#0563C1;text-decoration:underline;}#yiv8251087684 a:visited, #yiv8251087684 span.yiv8251087684MsoHyperlinkFollowed {color:#954F72;text-decoration:underline;}#yiv8251087684 p.yiv8251087684MsoListParagraph, #yiv8251087684 li.yiv8251087684MsoListParagraph, #yiv8251087684 div.yiv8251087684MsoListParagraph {margin-top:0cm;margin-right:0cm;margin-bottom:0cm;margin-left:36.0pt;margin-bottom:.0001pt;font-size:11.0pt;font-family:"Calibri", sans-serif;}#yiv8251087684 span.yiv8251087684EmailStyle17 {font-family:"Calibri", sans-serif;color:windowtext;}#yiv8251087684 .yiv8251087684MsoChpDefault {font-family:"Calibri", sans-serif;} _filtered #yiv8251087684 {margin:70.85pt 70.85pt 70.85pt 70.85pt;}#yiv8251087684 div.yiv8251087684WordSection1 {}#yiv8251087684 _filtered #yiv8251087684 {} _filtered #yiv8251087684 {font-family:Symbol;} _filtered #yiv8251087684 {font-family:"Courier New";} _filtered #yiv8251087684 {font-family:Wingdings;} _filtered #yiv8251087684 {font-family:Symbol;} _filtered #yiv8251087684 {font-family:"Courier New";} _filtered #yiv8251087684 {font-family:Wingdings;} _filtered #yiv8251087684 {font-family:Symbol;} _filtered #yiv8251087684 {font-family:"Courier New";} _filtered #yiv8251087684 {font-family:Wingdings;} _filtered #yiv8251087684 {} _filtered #yiv8251087684 {} _filtered #yiv8251087684 {} _filtered #yiv8251087684 {} _filtered #yiv8251087684 {} _filtered #yiv8251087684 {} _filtered #yiv8251087684 {} _filtered #yiv8251087684 {} _filtered #yiv8251087684 {} _filtered #yiv8251087684 {}#yiv8251087684 ol {margin-bottom:0cm;}#yiv8251087684 ul {margin-bottom:0cm;}-->Dear all :    I took an action item at the 6tisch interim to address cell types in the 6top protocol:    As you know, a chunk is like a malloc heap, a set of resources that a node ( a RPL parent) attributes to be able to serve dynamic bandwidth needs with the 6top protocol. Currently, the assumption was that the chunks are a partition of the CDU matrix, so chunks are not overlapping, and all cells in chunked space are identical, meant for dedicated unicast traffic like we foresee for tracks. I pointed out at the interim today that for statistical traffic we may want to have overlapping chunks, in which case cells from different chunks but overlapping chunks may have a chance of collision *. We discussed that the requester of cells in the 6top protocol may have a say on which type of cell is to be allocated, like high priority, unicast vs. shared, guaranteed non overlapping vs not. This raises a number of questions:    1)     Do people see value in doing that? 2)     If so, should a chunk have properties, like should cells in a chunk have homogeneous properties? 3)     Should the type (unicast vs. shared) be a permanent property of the cell while it is free (it sits in a chunk), or one attributed by the parent when the cell is placed in a bundle and for the direction of that attribution?    What do you think?    Pascal    * note there is some Cisco IPR around overlapping chunks that that I need to dig if we pursue this direction.    
_______________________________________________
6tisch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6tisch

---

From: Xavier Vilajosana <[email-masked]>
Date: Sat, 9 Jan 2016 06:54:45 +0100

Hi Pascal,

Yes but for me this is something that the SF must address. 6P should not be
aware of that.

2)      If so, should a chunk have properties, like should cells in a chunk
have homogeneous properties?

I see it as having the SF virtualize chunks and fragment them as desired.
Then they can have a container ID which differentiates them. Devices not
aiming to do that fragmentation can assign a single container ID to the
chunk and use it. Nodes aiming to differentiate cells in the chunk can
fragment them by defining new container IDs.

3)      Should the type (unicast vs. shared) be a permanent property of the
cell while it is free (it sits in a chunk), or one attributed by the parent
when the cell is placed in a bundle and for the direction of that
attribution?

This is one way to implement that. I can think of a node having a list of
cell IDs that can be shared as well. The overhead might be the same. Note
that in most implementations OFF cells are not kept anywhere. If we need to
keep that (type) information we need to keep a data structure for them even
they are OFF so we incur memory overhead.

my 5 cents.,

regards

Xavi

2016-01-08 19:15 GMT+01:00 Pascal Thubert (pthubert) <[email-masked]>:

> As you know, a chunk is like a malloc heap, a set of resources that a node
> ( a RPL parent) attributes to be able to serve dynamic bandwidth needs with
> the 6top protocol.
>
> Currently, the assumption was that the chunks are a partition of the CDU
> matrix, so chunks are not overlapping, and all cells in chunked space are
> identical, meant for dedicated unicast traffic like we foresee for tracks.
>
> I pointed out at the interim today that for statistical traffic we may
> want to have overlapping chunks, in which case cells from different chunks
> but overlapping chunks may have a chance of collision *.
>
> We discussed that the requester of cells in the 6top protocol may have a
> say on which type of cell is to be allocated, like high priority, unicast
> vs. shared, guaranteed non overlapping vs not.
>
> 3)      Should the type (unicast vs. shared) be a permanent property of
> the cell while it is free (it sits in a chunk), or one attributed by the
> parent when the cell is placed in a bundle and for the direction of that
> attribution?
>
>
>
> What do you think?
>
>
>
> Pascal
>
>
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sat, 9 Jan 2016 09:24:43 +0000

Hello Xavi

Yes but for me this is something that the SF must address. 6P should not be aware of that.

> well, I’m sure the 6P does not care about which chunk of type blah the cell should come from, but if a chunk is typed, then the child may need to tell the parent what type of chunk is expected.

->  Now, it might be that the type of chunk is obvious from the type of cell in which case there is no need to signal the type of chunk, just the type of cell

-> and then, if all cells in a bundle are of a same type, then then is no need to signal the type of cell, as long as the bundle is indicated

-> Then we’ll note that there will be a need to signal the creation of a bundle. This will be useful for tracks.

> In short:

- > We need to define if there are cell properties that we need to manipulate or if all cells are equivalent

----> candidate would be shared be unicast, priority, origin chunk properties …

-> We need to define if there are chunk properties or if all chunks are equivalent

----> candidate would be partitionned vs. overlapping, origin CUD if we support multiple…,

- > We need to figure if these properties are

----> to be signaled individually at the cell allocation

----> or if they are inherited from the chunk type (in that case we’d need to signal the chunk type)

----> and or if they are inherited from the target bundle (which needs be signaled anyway).

I see it as having the SF virtualize chunks and fragment them as desired. Then they can have a container ID which differentiates them. Devices not aiming to do that fragmentation can assign a single container ID to the chunk and use it. Nodes aiming to differentiate cells in the chunk can fragment them by defining new container IDs.

This is one way to implement that. I can think of a node having a list of cell IDs that can be shared as well. The overhead might be the same. Note that in most implementations OFF cells are not kept anywhere. If we need to keep that (type) information we need to keep a data structure for them even they are OFF so we incur memory overhead.

Ø  Makes sense to keep it that way. Which boils down whether cells have permanent properties vs. transient properties. Permanent properties could be associated to the chunk the come from so we do not have to maintain a state for OFF frames (which are still in the free pool). Transient properties (such as this cell is used in this bundle as a shared cell of priority P2) could be associated to the bundle if design for homogeneous bundles, which I hope we do. That is really what I’m hinting above

Have a great week end!

Pascal

2016-01-08 19:15 GMT+01:00 Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>:
Dear all :

What do you think?

Pascal

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