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

Hi Pascal,

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.

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) <pthubert@cisco.com>:

> 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
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
>