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