Re: [NNagain] CFP march 1 - network measurement conference

[Bill Woodcock <woody@pch.net>]

[-- Attachment #1: Type: text/plain, Size: 3550 bytes --]



> On Dec 6, 2023, at 22:46, Sauli Kiviranta via Nnagain <nnagain@lists.bufferbloat.net> 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


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 1463 bytes --]