netstats: add counter for retransmissions

[miri64]

Contribution description

This was cherry-picked out of #11068 (which became a huge mess during my experiment phase in preparation for the 6LoWPAN fragment forwarding paper.

This adds a retransmission counter to netstats. It also adds an implementation of that counter to gnrc_netif to count NETDEV_EVENT_TX_NOACK events as retransmissions in the interface's netstats (as no ACK from the receiver implies a retransmission). Lastly, the shell command is extended to print out the new counter.

Testing procedure

Flash gnrc_networking to two boards that have network devices that support retransmissions (I used two samr21-xpro

make -C examples/gnrc_networking flash # to two boards

make term to both of them in two different terminals.

Check if the retransmission counter for Layer 2 is 0

> ifconfig
[…]
Statistics for Layer 2
  RX packets 0  bytes 0
  TX packets 3 (Multicast: 3)  bytes 115
  TX succeeded 3 errors 0 retransmissions 0
[…]

Let them ping each other with unicast addresses in short intervals to stress the medium:

ping6 -i 10 -c 1000 "<the respective other node's link-local address>"

ifconfig should show retransmissions > 0 for Layer 2

[…]
Statistics for Layer 2
  RX packets 1162  bytes 41923
  TX packets 2103 (Multicast: 16)  bytes 75806
  TX succeeded 1173 errors 50 retransmissions 880

Issues/PRs references

Cherry-picked from #11068, but this PR has no dependencies.

[PeterKietzmann]

AFAIK (at least on the Atmel radio) this is not the total number of retransmissions but the number of transmissions where all retransmission attemts failed to get an ACK back.

[miri64]

I think that comment was supposed to the event handler? And isn't this the same? At least that is what we used in the past to count L2 retransmissions in our experiments. Or am I misunderstanding something?

[PeterKietzmann]

Ideally, we would count the absolute number of retransmissions here but this is not always the case (only speaking for the Atmel radio, we would need to lookup others). When this interrupt fires, MAX_RETIRES retransmissions failed to get an ACK, which is 4 by default. When an ACK appears after the second retransmission you won't notice.

[miri64]

If this event imposes radio-specific corner cases to the upper layer, the design is already broken. So we should really be sure what this event does exactly.

[PeterKietzmann]

So we should really be sure what this event does exactly.

Behavior of the Atmel radio was explained above. Next would be to find out handling on other devices.

[cladmi]

I remember a really old question from @OlegHahm asking if I knew how to get the hardware auto-retransmission counter, and I think we did not find anything.
So if the re-transmission is done by the hardware itself, it would not be noticed.

I think that is what Peter is talking about.

[OlegHahm]

@PeterKietzmann I think in some old branch of mine I fiddled around with setting the retry amount to zero and handle the retransmissions within the driver, but I don't remember the details any more.

[PeterKietzmann]

Thanks for your feedback. @cladmi yes, at least this is the case for AT86RF2XX. No idea about other devices that we support. @OlegHahm yes I know, that was even a (never merged) PR of yours that I reference from time to time.
To conclude: If "all" other devices than the Atmel radio do support this count, we could go with this PR. If not we might delay the discussion until there is more from the software MAC initiative (by @jia200x )

[miri64]

Ok. I'm leaving this PR open for now for later reference though (or if we need the counter for experiments again ;-)).

[cladmi]

It should not be used for experiments with samr21-xpro or iotlab-m3 though or results would be based on a too low value.

[PeterKietzmann]

Although having this kind of statistic would be great, this counter is misleading with the current state of integration. Radios that we know of don't report the actual number of retries and a software retransmission method is still absent (or am I mistaken)? I propose to close this PR with memo label set and tackle the task a little bit later when @jia200x continues his work on the lower layers. Do you agree @miri64? In any way, I will remove the release milestone tag.

[miri64]

How about renaming the counter to something like noack then. I don't see how a software retransmission method helps us in our situation or do you actually plan to use that instead of the hardware one for the at86rf231 when we are doing experiments. Having this instead of patching something in for all of our experiments that need to measure this, is definitely more helpful.

[PeterKietzmann]

First, merging this PR should IMO not be about the need for this counter in some individual experiments. Second, we never actually used this metric. Personally, I only look at this counter ( next to CSMA failure counter) to get an idea about link quality. Third, this event does not actually reflect the number of missing ACKs (as explained above) and it is very hardware specific, so I was even wondering weather we should implement this in a hardware specific module.

As a compromise: What if we name it "experimental" and document it somehow?
@jia200x can you please state your opinion here?

[jia200x]

The AT86RF233 has a retransmission counter (see XAH_CTRL_2). The AT86RF231 doesn't report any kind of retransmission counter, so it's impossible to get the actual number there while using Extended Mode.

As @PeterKietzmann describes incrementing a counter on "NOACK" while only give a lower bound and doesn't represent the actual value.

If we are going to add a retransmission counter, I would add at least a way to check if the radio support ACK retransmissions before displaying them to the user. They can be e.g dropped from the message.

if(radio_supports_retrans_counter)
{
    printf("retransmissions %u", stats->tx_retrans"); 
}

So we get

TX succeeded 45 errors 2

Instead of

TX succeeded 45 errors 2 retransmissions <a_lower_bound_value>

This radio_supports_retrans_counter can be obtained from a NETOPT or even better, from radio caps (see #11473).

Note that all radios running in Basic Mode with software IEEE802.15.4 implementation (WIP) will support the retransmission counter. So for experiments, it's possible to do this or use a radio that support the counter

[jia200x]

Note that for MAC layers supporting retransmission, the tx_retrans should be updated on every transmission, regardless of the status (NOACK, TX_COMPLETE or TX_COMPLETE_DATA_PENDING)

[miri64]

Second, we never actually used this metric.

We used it for https://arxiv.org/pdf/1905.08089.pdf (Fig. 9(c)) and I was under the impression we used it for https://arxiv.org/pdf/1806.01444.pdf.

But okay, if this is too device specific, then this shouldn't be included in gnrc_netif, but integrated differently. As I used this approach however for the 6LoWPAN paper, I like to keep it for posterity, so I'm closing this as Stated: archived.