Re: Packet Loss: .08%
Packet loss is a pointless metric for consumers, impossible to represent or calculate accurately within the ISP, and does not belong on a consumer facing label.
A)The amount of packet loss you experience is dependent on the load you place on the network. With a rigorously defined test using X TCP CUBIC flows, in either direction, you can calculate what the packet loss should for that load should be at the exact RTT of the path, but even then the number is sensitive to the buffering or AQM technique on the path, (and even more so to any of the other dozen plus TCP variants). In many cases, MORE packet loss is better than less, as misguided attempts at eliminating loss have led to enormous induced latencies due to "bufferbloat", which makes the network worse.
https://blog.apnic.net/2020/01/22/bufferbloat-may-be-solved-...
B) The whole concept of packet loss is nearly impossible to calculate. It's loss. You can't see it directly, only infer, that it happened on the path, by observing a retransmit. It could have happened at the client, the wifi path, the router, any of the wires inbetween, the switch, the gateway. You can't directly observe loss in many cases, and in others, you want to induce loss to get good congestion control to hold latencies low.
Timely packet loss, while essential to the correct operation of the internet, cannot be represented by a single percentage number, period. The correct answer to this proposed item on the label, would be:
Packet Loss: Yes.
"Packet loss" is more interesting to nerds than consumers, who don't know what it means. Arguably it needs a better name.
"Delays due to retransmission" is short enough to fit the label, and is what a packet loss means _to the reader of the label_, rather than to me.
Perhaps this graphic will help: https://www.domos.no/news-updates/latency-explained-in-a-pag...
Re: Latency: 35%
I would substitute "baseline latency" to the DFZ as this number, and also report on "working latency". https://www.bitag.org/documents/BITAG_latency_explained.pdf
Jitter, is usually also induced by other traffic on the link. It's really difficult to come up with metrics for these, there is some interesting work going on here, notably Apple's new "responsiveness" networkQuality test, and caida's jitterbug suite.