Re: [Bloat] Sidebar re illustrating quality (was: New Version Notification for draft-cpaasch-ippm-responsiveness-00.txt)

[Sebastian Moeller <moeller0@gmx.de>]

So here is my take,

to assess the usefulness of an internet access link (any link probably, but being an end user myself, I want to limit myself to where I have first hand experience) there are a number of easier/harder to get numbers:

1) access rate: easy to measure (at least as HTTPS/TCP/IP goodput, gross rate of the bottleneck link is considerable harder to deduce)

2) latency to the end-point under test: also easy to measure (simply by running an ICMP probe stream before and during a speedtest; also some more enlightened speedtests already report both RTTs)
	 IMHO that actually should be a tuple of 
	latency without load RTT(unloaded) , and latency under saturating conditions RTT(saturated)
	=> if both numbers exist, the difference RTT(saturated) - RTT(unloaded) = Latency under load increase (LULI ;)) can be calculated
		which is a proxy of the level of latency degradation a user can expect as a function of load.

3) latency variation/jitter: also reasonable easy to measure with tools like MTR. Quite a number of use-cases work well with moderately high, but static RTTs but deteriorate quickly if the latency becomes too variable
	(Some access technologies, like WiFi or DOCSIS are prone to introduce jitter, as is XDSL when ITU G.998.4 G.INP retransmissions enter the picture)

4) packet loss: relatively hard to measure, but some tools like iperf seem to report retransmissions, 

5) packet re-ordering: hard to measure (IIUC) if severe enough this will manifest as apparent packet loss/replay attack
	

RPM. IMHO is nice additional way to address 2) above, but personally, I am less interested in how many hypothetical transactions I could perform per second as compared to how long each takes, as the latter still allows me to make reasonable guesses of completion time if I issue transactions in parallel, and the LULI measure can be reasonably compared with what ever latency budget a given task has.


Any attempt as trying to display all these five in one consistent plot is IMHO challenging, because such a plot should use a scale of equal severity for all its axis, otherwise it becomes really hard to parse as an aggregate, no?

Regards
        



> On Aug 21, 2021, at 03:22, Kenneth Porter <shiva@sewingwitch.com> wrote:
> 
> On 8/19/2021 6:58 PM, Dave Collier-Brown wrote:
>> Look at the barrel link, in that case: I'll send you a sketch off-list 
> 
> Ok, the sketch is of a spoked wheel with 3 spokes, for throughput, latency, and RPM, and the spoke for throughput is much longer. The circle represents the spoke of smallest radius, indicating the worst rating of the service. The ISP will try to sell based on the longest spoke to make itself look better than the actual user experience.
> 
> It's like taking the barrel illustration and "exploding" the barrel so its staves lie flat, radiating from the base. In that case, the shortest stave is the worst rating.
> 
> 
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat