fix: Packet loss now returns the value of the current frame instead of connection lifetime

[Rosme]

Fix the way the packet loss was calculated where it was over a connection lifetime instead of a frame.

MTT-3389

Changelog

• Fixed issue where PacketLoss would return the packet loss over a connection lifetime instead of a single frame.

Testing and Documentation

• Includes integration tests.

[simon-lemay-unity]

I understand the benefit of tracking packet loss on a smaller time scale, but I'm worried that a frame is too small a scale. I don't think we see enough packets per frame to gather a good metric of packet loss on the network. For example, if 10 packets are received per frame (which would be a consequent volume of traffic), then packet loss can't be lower than 10% for any frame. Users are only likely to see long periods of 0% packet loss, interspersed with spikes of 10%-20%. That's not practical to figure out packet loss on the network, since you then have to count the total number of frames between these spikes (e.g. a 10% spike every 10 frame means 1% packet loss on the network, which is a more realistic and useful figure). I think tracking packet loss over periods of say a second might be more useful and accurate.

[Rosme]

I understand the benefit of tracking packet loss on a smaller time scale, but I'm worried that a frame is too small a scale. I don't think we see enough packets per frame to gather a good metric of packet loss on the network. For example, if 10 packets are received per frame (which would be a consequent volume of traffic), then packet loss can't be lower than 10% for any frame. Users are only likely to see long periods of 0% packet loss, interspersed with spikes of 10%-20%. That's not practical to figure out packet loss on the network, since you then have to count the total number of frames between these spikes (e.g. a 10% spike every 10 frame means 1% packet loss on the network, which is a more realistic and useful figure). I think tracking packet loss over periods of say a second might be more useful and accurate.

We decided to go this route as RNSM actually allow you to configure over how many samples and how long you want the packet loss to be. Since this is used by the tools, it's an easy way to get the value and leave in the end of the user how much precision and flexibility they want.

[NoelStephensUnity]

Other than the very minor whitespace issue, it looks good to me.

[ian-m-unity]

Would it make sense to return 0 in this case? It would mean that you don't need to store the previous value 🤔

[ian-m-unity]

Just a question, maybe what you have is already the best approach

[ian-m-unity]

Approved with one suggestion :)