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

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Xavi

1)      Do people see value in doing that?

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).



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.

Ø  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) <[e-mail]<mailto:[e-mail]>>:
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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/6tisch