Subject: [6tisch] OTF - 6top

From: Maria Rita PALATTELLA <[email-masked]>
Date: Fri, 13 Jun 2014 12:05:25 +0000

Dear all,

As it was announced yesterday, this morning we had a dedicated 6TiSCH call, for clarifying several concepts related to the interaction between OTF and 6top (minutes will be shared in the coming days, as usual).
Actually we have mainly discussed on the relationship between OTF and track (first slide of the attached slides).

After a long discussion, we have concluded that
(@Pascal, Thomas, all of you attending the call: please, feel free to fix anything that I may have misunderstood).

OTF is a layer3-mechanism that by interacting with 6top, allows to increase/decrease the bandwidth between two neighbor nodes (i.e., add/delete sofcells). Thus, it is a 1-hop protocol, that by checking the queue length, and the queued packets that may generated overflow, triggers the request to 6top of allocating new softcells for that source node with a specific neighbor (or in analogous way, the request of deleting softcells, if the queue has been empty for some time).
The new softcells that are allocated in the schedule for this couple of nodes, belongs to a best effort track, having TrackID=00.
Therefore, they can be used for forwarding on that hop any packet in the queue, regardless of the specific track it belongs to.
In fact, OTF will manage the global BW between two neighbor nodes, and not the BW allocated on that link, per each distinct track.

Said that, I think we need to re-define the interaction between OTF and 6top (and somehow discuss the other points that were in the agenda, see attached slides, but we couldn't for luck of time).

OTF and 6top commands

For sure OTF will use CREATE.softcell, DELETE.softcell commands, basic commands for increasing/decreasing BW.
By doing so, OTF provides a POLICY to generate CREATE/DELETE soft cells commands (policy that is out of 6top scope). But other policies may be defined in the future, different from the one provided by OTF.

If OTF operates on the total BW, based on the queues' length (as stated before), I do believe that OTF will not use the READ.cell command. The latter allows to get information, about a set of metrics (LQI, EXT, PDR), for a specific cell. But, OTF (unlike 6top)  shouldn't know what are the specific cells allocated between two neighbor nodes.
On the contrary, I believe that the READ.cell command should be used by the 6top Monitoring Function, in order to detect the soft cells that should be re-allocated.  Do you agree?
In detail, the Monitoring function, with its re-allocation feature, provides better cells for given BW requirements from OTF. But OTF will not need to know when cells are moved within the schedule. Such info should be kept only by 6top.

Getting statistic from 6top

The statistic data is kept in 4 data structure of 6top MIB: CellList, MonitoringStatusList, NeighborList, and QueueList.
CellList, because it provides per (specific) cell statistics, shouldn't be used by OTF. Do you agree?
MonitoringStatusList provides per neighbor and slotframe statistics.   @Qin: can you explain better what info are in such list?
OTF will use the NeighborList, that provide per neighbor statistics. By knowing about the connectivity of that pair of nodes, OTF can decide to ask 6to for adding/deleting cells.
OTF should use also the QueueList, that provides per Queue statistic.  Still to be discussed (it was done partially some time ago): how to associate queue to priority or tracks.

OTF - 6top interface

OTF may use the CoAP + YANG model for accessing 6top MIB. To be better investigated. Or shall we define a different model?

Thanks for going through the email, and provide your feedbacks.
Regards,
Maria Rita

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Fri, 20 Jun 2014 00:43:37 -0400

Dear all,
             I provide some comments below.
Regards,

                        Diego

2014-06-13 8:05 GMT-04:00 Maria Rita PALATTELLA <
[email-masked]>:

>  Dear all,
>
>
>
> As it was announced yesterday, this morning we had a dedicated 6TiSCH
> call, for clarifying several concepts related to the interaction between
> OTF and 6top (minutes will be shared in the coming days, as usual).
>
> Actually we have mainly discussed on the relationship between OTF and
> track (first slide of the attached slides).
>
>
>
> *OTF is a layer3-mechanism that by interacting with 6top, allows to
> increase/decrease the bandwidth between two neighbor nodes (i.e.,
> add/delete sofcells). Thus, it is a 1-hop protocol, that by checking the
> queue length, and the queued packets that may generated overflow, triggers
> the request to 6top of allocating new softcells for that source node with a
> specific neighbor (or in analogous way, the request of deleting softcells,
> if the queue has been empty for some time).*
>

DD: Queue length is one of the possible metrics, the algorithm within OTF
may use other metrics.

>  *The new softcells that are allocated in the schedule for this couple of
> nodes, belongs to a best effort track, having TrackID=00.*
>
> *Therefore, they can be used for forwarding on that hop any packet in the
> queue, regardless of the specific track it belongs to. *
>
> *In fact, OTF will manage the global BW between two neighbor nodes, and
> not the BW allocated on that link, per each distinct track.*
>
>
>

>
> Said that, I think we need to re-define the interaction between OTF and
> 6top (and somehow discuss the other points that were in the agenda, see
> attached slides, but we couldn’t for luck of time).
>
>
>
> *OTF and 6top commands*
>
>
>
> By doing so, OTF provides a POLICY to generate CREATE/DELETE soft cells
> commands (policy that is out of 6top scope). But other policies may be
> defined in the future, different from the one provided by OTF.
>
>
>
> If OTF operates on the total BW, based on the queues’ length (as stated
> before), I do believe that OTF will not use the READ.cell command. The
> latter allows to get information, about a set of metrics (LQI, EXT, PDR),
> for a specific cell. But, OTF (unlike 6top)  shouldn’t know what are the
> specific cells allocated between two neighbor nodes.
>
> On the contrary, I believe that the READ.cell command should be used by
> the 6top Monitoring Function, in order to detect the soft cells that should
> be re-allocated.  Do you agree?
>

DD: I do agree that OTF cannot take any decisions on statistics which will
change when 6top decides to dynamically move softcells on the schedule.
Nevertheless, as stated before, I think queue length is only one of the
possible metrics or high-level statistics OTF can use.

>  In detail, the Monitoring function, with its re-allocation feature,
> provides better cells for given BW requirements from OTF. But OTF will not
> need to know when cells are moved within the schedule. Such info should be
> kept only by 6top.
>
>
>
>
>
> *Getting statistic from 6top*
>
>
>
> The statistic data is kept in 4 data structure of 6top MIB: CellList,
> MonitoringStatusList, NeighborList, and QueueList.
>
> CellList, because it provides per (specific) cell statistics, shouldn’t be
> used by OTF. Do you agree?
>

DD: I do agree. Cell-specific statistics are not significant to OTF, since
softcells can be relocated.

>  MonitoringStatusList provides per neighbor and slotframe statistics.   @Qin:
> can you explain better what info are in such list?
>
> OTF will use the NeighborList, that provide per neighbor statistics. By
> knowing about the connectivity of that pair of nodes, OTF can decide to ask
> 6to for adding/deleting cells.
>
> OTF should use also the QueueList, that provides per Queue statistic.  Still
> to be discussed (it was done partially some time ago): how to associate
> queue to priority or tracks.
>
>
>

DD: 1- Can OTF decide on the priority or tracks for the allocated
softcells?
       2- As far as I can understand, under this conditions, we are
assuming that, if we want to change the BW between two neighbour nodes,
there must be at least one track with a scheduled softcell in it. Is this
correct?

>  *OTF – 6top interface*
>
>
>
> OTF may use the *CoAP + YANG model* for accessing 6top MIB. To be better
> investigated. Or shall we define a different model?
>
>
>

DD: Although it would be nice to have one single interaction standard
between modules, I believe that 6top API would accomplish the same task
with less overhead.

-- 
DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
www.ingenieria.udp.cl
(56 2) 676 8125