[RFC] net/netstats L1/L2 per neighbor transfer statistics

[bergzand]

This WIP adds functionality for recording statistics split out per peer. The goal of these statistics are for RPL parent selection, for example based on the ETX of the connection to the potential parent.

A struct with these statistics is defined. At this moment an array of length 8 is added to the netdev struct. I went for this approach because ETX statistics can be radio dependent and if a device has multiple radios these statistics are clearly dependent on the radio. Statistics are updated on packets received from the neighbor or transmission to the neighbor.

Because the netdev callback used to process transmission result has no knowledge of the transmitted frame itself, I decided to implement a small ring buffer like construction to link transfers to the callback. This ring buffer assumes that the order of packets send to the radio and the callbacks are in the same order. The ring buffer consists of a array of netstats_peer_t pointers and 2 indexes for reading/writing positions. Multicast/broadcast transmissions are recorded as NULL ptr's preserving the order of this buffer.

RSSI and LQI values are kept as exponential weighted moving averages, this to have some average function over this data while keeping the stored data small. I prefer to store the RSSI values in dBm, but the current radio's return the raw values instead of dBm converted values.

I've added a netopt call to retrieve the statistics. I've used this to extend the ifconfig tool with these statistics.

This PR is a work in progress. It's probably not feasible to have this merged before the feature deadline.

I would like some feedback on the architecture build for this. If a different approach is preferred, I can rewrite this. Also, if a different algorithm for certain parts is preferred, I'd also like to hear

Todo:

• ETX calculations
• Implement byte counters
• Some kind of freshness indication
• RSSI in dBm, Needs a different PR to fix this in the radio drivers

[bergzand]

Added RFC tag :)

[bergzand]

Rebased and resolved merge conflict

[bergzand]

Rework of implementation, including a rename.

Now based on #7447 and #7448, works better with #6895.
ETX and freshness is implemented.

The byte and packet counters are under an extra pseudomodule because they are not necessary for application requiring ETX such as RPL MRHOF.

[bergzand]

No longer WIP.

[bergzand]

Prevents a segfault when no empty/stale entries are present and added support for ethernet devices.

Note that ETX doesn't really make sense with tap because there is no L2 ack mechanism, but it simplifies testing a lot.

[miri64]

@bergzand I assume you are planning to port this to #8198 in the future?

[bergzand]

Yes, At some point I hope to build a v2 of this based on #8198

[tcschmidt]

@bergzand #8198 is merged, how to adapt right now?

[bergzand]

@tcschmidt As requested here #8198 contained only the initial headers and code required for the layered approach. As long as the netdev stack is not adapted to actually use the code, it is not possible to reworking this PR in a useful way.

[benpicco]

@bergzand is this still true?
What needs to be done before it's possible to add neighbor statistics into the stack and where should they go now?

[miri64]

Ping @bergzand?

[bergzand]

@miri64 @benpicco Unfortunately I don't have time to work on this. I'm also not sure where this functionality should be hooked into the stack. Mostly as there are now multiple ideas floating around on how the link/phy layer should evolve.

[chrysn]

If this were resolved, would there be much work left to do to implement MRHOF? (The contiki users around me are kind of reluctant to switch that off).

[bergzand]

If this were resolved, would there be much work left to do to implement MRHOF? (The contiki users around me are kind of reluctant to switch that off).

Around 350 lines of code depending a bit on how much things changed in two years

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

[benpicco]

netstats_nb shouldn't have a dependency on netdev.

This might actually be useful.
I think there is a case for allowing device-specific extra information per-neighbor.
E.g. with at86rf215 you might want to use different data rates for different nodes, depending on how good the link quality is.
You could also talk to MR-O-QPSK nodes and legacy O-QPSK nodes simultaneously if there was a way to store which node used which modulation.

[miri64]

Would have thought the bot removes the stale label if you re-open the issue...

[benpicco]

@miri64 @benpicco Unfortunately I don't have time to work on this. I'm also not sure where this functionality should be hooked into the stack. Mostly as there are now multiple ideas floating around on how the link/phy layer should evolve.

I can take over. From what I gathered by talking to @miri64 was that it should not be part of GNRC (so not extending the NIB) but rather a separate L2 database - so pretty much what you did here.

[benpicco]

Wouldn't it be better to evict the entry with the worst signal?

[benpicco]

If those are just for printing out information, I'd rather drop them - 20 bytes / neighbor is quite a lot to keep around for curiosity's sake.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

[miri64]

Very timely, stale bot, very timely ;-).