Subject: [6tisch] Statistics and Monitoring Function, was: Re: OTF - 6top

From: Guillaume Gaillard <[email-masked]>
Date: Thu, 26 Jun 2014 23:38:18 +0200

Hi all,

I would like to answer this question of Maria Rita :

2014-06-13 14:05 GMT+02:00 Maria Rita PALATTELLA 
<[email-masked] <mailto:[email-masked]>>:

    MonitoringStatusList provides per neighbor and slotframe statistics.
    @Qin: can you explain better what info are in such list?

The contents of such list are specified in 6 top MIB, Qin provided them 
in this e mail:
http://www.ietf.org/mail-archive/web/6tisch/current/msg01693.html
Table 3 : Monitoring Status List
Table 4 : Statistics Metric List

In my understanding of draft draft-wang-6tisch-6top-sublayer-0 [1], 
(Sections 3.3, 3.4, 5, and 6):

- Statistics and Metrics may be defined by some upper layers and 
collected by 6top;
- The 6top Monitoring Function should use the statistic data in order to 
compute the monitored status according to the specified metrics.

Qin, is that correct ?

Then, the Monitoring Status List (Table 3) gives values for each 
Slotframe. Whereas the Statistics Metric List (Table 4) gives values on 
a specified quantity of slotframes (cf. the Window field : "measurement 
period, in Number of the slotframe size";).

Is that still correct ?

For example, upper layer "Layer 7" wants to know the average PDR of link 
A->B during a period of 5 slotframes. In order to do this:
- We configure the Statistic Function by giving a Statistic Metric List 
with a window of 5;
- We read the PDR value for link A->B for each slotframe (as configured 
in the Monitoring Function);
- We compute the average of the 5 obtained values to get the final metric.

Is that corresponding to the drafts ?

What about the metric: "PDR from A to C (A->B->C) during a given period 
of time" ?

Maybe we could clarify the roles and the behaviors of the Monitoring and 
Statistics Functions, in the sublayer draft, what do you think ?

Sincerely,

*Guillaume Gaillard***

Orange Labs Meylan/CITI INRIA-INSA Lyon

PhD student "SLA for Multi-Service Wireless Sensor Networks"

Advisors D. Barthel, F. Valois, F. Theoleyre

[1] http://tools.ietf.org/html/draft-wang-6tisch-6top-sublayer-00

2014-06-13 14:05 GMT+02:00 Maria Rita PALATTELLA 
<[email-masked] <mailto:[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).

    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

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

---

From: Qin Wang <[email-masked]>
Date: Fri, 27 Jun 2014 12:15:23 -0700

Hi Guillaume,

Thank you very much for answering the question of Maria Rita. (I have to say sorry to Maria Rita for late response)

(1) Indeed, MonitoringStatusList and StatisticsMetricList are used for conducting statistics functions. The latest version of the two Lists is in the draft-ietf-6tisch-6top-interface-00, defined in YANG model.

(2) You are right, StatisticsMetricList is configured by upper layer, and it will be associated to CellList, so as 6top will know how to collect data and compute statistics for each cell.
MonitoringStatusList is a per slotframe & neighbor statistics and will be updated by 6top. Besides upper layer, 6top itself may use it to conducting Monitoring Functions of 6top, such as re-allocating slotOffset & channelOffset when 6top find the link quality of some softcell is much lower than average.

(3) The process of getting A->B PDR is correct.

(4) Regarding A->B->C, PDR, 6top does not support to get it directly. But, I think, in theory, if you know A->B PDR and B->C PDR via 6top, you will be able to estimate the A->B->C PDR. BTW, why you need A->B->C PDR?

(5) I do agree that we should describe the roles of the Lists, and how they work.

Thanks
Qin 

On Friday, June 27, 2014 5:38 AM, Guillaume Gaillard <[email-masked]> wrote:

Hi all, 

2014-06-13 14:05 GMT+02:00 Maria Rita PALATTELLA <[email-masked]>:

>
>MonitoringStatusList provides per neighbor and slotframe statistics.   @Qin: can you explain better what info are in such list?

The contents of such list are specified in 6 top MIB, Qin provided them in this e mail:
http://www.ietf.org/mail-archive/web/6tisch/current/msg01693.html

In my understanding of draft draft-wang-6tisch-6top-sublayer-0 [1], (Sections 3.3, 3.4, 5, and 6):

- Statistics and Metrics may be defined by some upper layers and collected by 6top;
- The 6top Monitoring Function should use the statistic data in order to compute the monitored status according to the specified metrics.

Qin, is that correct ?

Then, the Monitoring Status List (Table 3) gives values for each Slotframe. Whereas the Statistics Metric List (Table 4) gives values on a specified quantity of slotframes (cf. the Window field : "measurement period, in Number of the slotframe size";).

Is that still correct ?

For example, upper layer "Layer 7" wants to know the average PDR of link A->B during a period of 5 slotframes. In order to do this:
- We configure the Statistic Function by giving a Statistic Metric List with a window of 5;
- We read the PDR value for link A->B for each slotframe (as configured in the Monitoring Function);
- We compute the average of the 5 obtained values to get the final metric.

What about the metric: "PDR from A to C (A->B->C) during a given period of time" ?

Maybe we could clarify the roles and the behaviors of the Monitoring and Statistics Functions, in the sublayer draft, what do you think ?

Sincerely,

Guillaume Gaillard

2014-06-13 14:05 GMT+02: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).
> 
>(@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? 
> 
> 
>[email-masked]

[email-masked]

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Sun, 29 Jun 2014 15:33:58 +0000

Many thanks Guillaume and Qin for your feedbacks. I have taken them into account while updating the new version of the OTF draft.
Regards,
Maria Rita

From: 6tisch [mailto:[email-masked]] On Behalf Of Qin Wang
Sent: Friday, June 27, 2014 9:15 PM
To: Guillaume Gaillard; [email-masked]
Subject: Re: [6tisch] Statistics and Monitoring Function, was: Re: OTF - 6top

Hi Guillaume,

Thanks
Qin

On Friday, June 27, 2014 5:38 AM, Guillaume Gaillard <[email-masked]<mailto:[email-masked]>> wrote:

Hi all,

2014-06-13 14:05 GMT+02:00 Maria Rita PALATTELLA <[email-masked]<mailto:[email-masked]>>:

Qin, is that correct ?

Is that still correct ?

Sincerely,

Guillaume Gaillard

2014-06-13 14:05 GMT+02:00 Maria Rita PALATTELLA <[email-masked]<mailto:[email-masked]>>:
Dear all,

OTF and 6top commands

OTF – 6top interface

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

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