Kytos stats with OF table stats (Blueprint)

[gretelliz]

This discussion is for issues #330 and kytos-ng/of_core#96

Abstract

This is to support table statistics and concentrate the statistics into a single NApp.
Actions will involve flow_stats and of_core.

Motivation

Currently flow_stats is responsible to deal with flow statistics, which are exposed in endpoints:

• GET v1/flow/stats to get the flows stats by dpid.

• GET v1/packet_count/<flow_id> for packet count of a specific flow.

• GET v1/bytes_count/<flow_id> for bytes count of a specific flow.

• GET v1/packet_count/per_flow/<dpid> for packet count per flow.

• GET v1/bytes_count/per_flow/<dpid> for bytes count per flow.

However, OF table stats are not supported.

The goal is to evolve flow_stats into kytos_stats for kytos statistics, including OF table stats support.

Specification

Information about tables is requested with the OFPMP_TABLE type of the OFPT_MULTIPART_REQUEST message.
The request does not contain any data in the body.
The body of the reply consists of an array of struct ofp_table_stats, which contains:

• table_id: Identifier of table.
• active_count: Number of active entries.
• lookup_count: Number of packets looked up in table.
• matched_count: Number of packets that hit table.

Proposed Changes

• Add kytos_stats from flow_stats.
• New event from of_core.
• Update kytos_stats to suport OF table stats.

of_core

kytos/of_core.flow_stats.received will be renamed to kytos/of_core.kytos_stats.flow_stats.received
Also, of_core will support MultipartType.OFPMP_TABLE and a new event will be published, just so kytos_stats can subscribe and react accordingly.

Published Events

kytos/of_core.kytos_stats.table_stats.received

Event reporting OF table stats

Content:

   {
     "switch": <switch>
     "replies_tables": [<Table stats>]
   }

kytos_stats

A data structure will be updated with the kytos/of_core.kytos_stats.table_stats.received event.
This structure will be indexed by `table_id`` and will allow the following API endpoints to be added:

• GET /packets_looked/<table_id> to get the number of packets looked up in the table.

• GET /packets_matched/<table_id> to get the number of packets matching the table.

Future work

• Include the calculations to get statistics from EVCs, which is currently the responsibility of Zabbix wrapper.
• Support time series stats like: number of EVCs, number of switches, number of interfaces, links, controller uptime.
• Assess whether it is necessary to include prediction tools from the time series stats.

[viniarck]

Add kytos_stats from flow_stats.

Did you mean rename flow_stats as kytos_stats, right? Renaming the NApp will be a breakig change since the prefix before the v1 routes will change too, so remember to map tasks to adapt zabbix wrapper to still to submit requests to the correct endpoint.

[viniarck]

kytos/of_core.flow_stats.received will be renamed to kytos/of_core.kytos_stats.flow_stats.received

No need for this change. The name of the event here flow_stats actually means OpenFlow related and not because of flow_stats NApp's name. So we should keep it as it is. Similarly, for table_stats you can introduce a new kytos/of_core.table_stats.received instead of kytos/of_core.kytos_stats.table_stats.received. of_core doesn't need to know that kytos_stats exists, it's just publishing OpenFlow related stats for any subscribers, so let's name the events accordingly. See what I mean?

[gretelliz]

Thank you. Got it.

[viniarck]

To which switches should table stats be requested? Since this feature is optionally supported by switches and we don't know how reliable their implementation will be, I'll recommend to double check to only send if the switch has confirmed its capabilities:

controller.switches[dpid].features.capabilities.value & Capabilities.OFPC_TABLE_STATS == Capabilities.OFPC_TABLE_STATS

With flow stats we don't do this since it's widely known that's it's supported, but one day we probably should too to be safe.

[viniarck]

This structure will be indexed by `table_id`` and will allow the following API endpoints to be added:
GET /packets_looked/<table_id>
GET /packets_matched/<table_id>

You need to figure out how the data will be queried. Indexing only by table seems a bit limited, the original stats is by dpid by table, so the endpoint(s) shouldn't constrain that much. I have an initial impression that even just a single GET v1/table/stats would suffice, then you could provide query params filtering by dpid and optionally by table in case the client only needs a specific dpid and a specific table. Please confirm that if this would suffice based on what Zabbix Wrapper will query/filter for. Let's also keep an equivalent behavior of flow stats by updating the entries and not overwriting them, since in this iteration it will only keep stored in the application memory.

[gretelliz]

You are right. I also think that a single GET v1/table/stats is suffice.

[viniarck]

Right.

[viniarck]

Overall, the approach looks good, @gretelliz, nice to see how this is shaping up. I ended up opening the threads here, so we can continue here, but since this is supposed to be a blueprint, eventually you'll need to open a PR to kytos too a get it approved.

[viniarck]

The blueprint has landed on this PR #351, congrats, Gretel.

I'll go ahead and close this issue discussion.

[gretelliz]

Thank you!