On Dec 6, 2023, at 22:46, Sauli Kiviranta via Nnagain
<[email protected]> wrote: What would be a
comprehensive measurement? Should cover all/most relevant areas?
It’s easy to specify a suite of measurements which is too heavy to be
easily implemented or supported on the network. Also, as you point
out, many things can be derived from raw data, so don’t necessarily
require additional specific measurements.
Payload Size: The size of data being transmitted. Event Rate: The
frequency at which payloads are transmitted. Bitrate: The
combination of rate and size transferred in a given test.
Throughput: The data transfer capability achieved on the test
path.
All of that can probably be derived from sufficiently finely-grained
TCP data. i.e. if you had a PCAP of a TCP flow that constituted the
measurement, you’d be able to derive all of the above.
Bandwidth: The data transfer capacity available on the test path.
Presumably the goal of a TCP transaction measurement would be to
enable this calculation.
Transfer Efficiency: The ratio of useful payload data to the
overhead data.
This is a how-its-used rather than a property-of-the-network. If
there are network-inherent overheads, they’re likely to be not
directly visible to endpoints, only inferable, and might require
external knowledge of the network. So, I’d put this out-of-scope.
Round-Trip Time (RTT): The ping delay time to the target server and
back. RTT Jitter: The variation in the delay of round-trip time.
Latency: The transmission delay time to the target server and
back. Latency Jitter: The variation in delay of latency.
RTT is measurable. If Latency is RTT minus processing delay on the
remote end, I’m not sure it’s really measurable, per se, without the
remote end being able to accurately clock itself, or an independent
vantage point adjacent to the remote end. This is the old
one-way-delay measurement problem in different guise, I think.
Anyway, I think RTT is easy and necessary, and I think latency is
difficult and probably an anchor not worth attaching to anything we
want to see done in the near term. Latency jitter likewise.
Bit Error Rate: The corrupted bits as a percentage of the total
transmitted data.
This seems like it can be derived from a PCAP, but doesn’t really
constitute an independent measurement.
Packet Loss: The percentage of packets lost that needed to be
recovered.
Yep.
Energy Efficiency: The amount of energy consumed to achieve the
test result.
Not measurable.
Did I overlook something?
Out-of-order delivery is the fourth classical quality criterion.
There are folks who argue that it doesn’t matter anymore, and others
who (more compellingly, to my mind) argue that it’s at least as
relevant as ever.
Thus, for an actual measurement suite:
- A TCP transaction
…from which we can observe:
- Loss - RTT (which I’ll just call “Latency” because that’s what
people have called it in the past) - out-of-order delivery - Jitter
in the above three, if the transaction continues long enough
…and we can calculate:
- Goodput
In addition to these, I think it’s necessary to also associate a
traceroute (and, if available and reliable, a reverse-path
traceroute) in order that it be clear what was measured, and a
timestamp, and a digital signature over the whole thing, so we can
know who’s attesting to the measurement.
-Bill
_______________________________________________ Bloat mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/bloat
