[NNagain] [Bloat] CFP march 1 - network measurement conference

[Kathleen Nichols]

Can I give an email "thumbs up" to Bill Woodcock's email?

That information is certainly there in TCP. I don't know how much of 
QUIC is in the clear.

On 12/6/23 6:22 PM, Bill Woodcock via Bloat wrote:
> 
> 
>> On Dec 6, 2023, at 22:46, Sauli Kiviranta via Nnagain
>> <nnagain at 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
> 
> 
> _______________________________________________ Bloat mailing list 
> Bloat at lists.bufferbloat.net 
> https://lists.bufferbloat.net/listinfo/bloat