[Bloat] goresponsiveness learned a few tricks...

[Bloat] goresponsiveness learned a few tricks...

[Sebastian Moeller]

Just a quick shoutout to Will Hawkins goresponsiveness effort (h++ps://github.com/network-quality/goresponsiveness: open source go implementation along the lines of the RPM IETF responsiveness draft (h++ps://github.com/network-quality/draft-ietf-ippm-responsiveness).

The goal I think is a quick latency under working conditions/latency under load for the rest of us. I think the draft likely will get a last call soon, so whoever wants to add something to the spec or just wants to comment, now would be a good time:

goresponsiveness is currently acquiring a few nice features, like the ability to compare the latency between idle and working conditions, run both saturating loads concurrently, and to report the sub results for the "self" probes (measuring latency within the load generating connection/flow) and the "foreign" probes (measuring latency outside of the load generating flows)

bash-3.2$ ./networkQuality --relative-rpm --rpm.parallel --config mensura.cdn-apple.com --port 443 --path /api/v1/gm/config --rpm.timeout 120 --extended-stats --rpm.mnp 32 --logger-filename go_networkQuality_20231228_223707 --detailed
01-08-2024 19:37:07 UTC Go Responsiveness to mensura.cdn-apple.com:443...
Baseline RPM:  2813 (P90)
Baseline RPM:  3888 (Single-Sided 5% Trimmed Mean)
Results:
========
Download:
	Throughput: 80.367 Mbps (10.046 MBps), using 13 parallel connections.
	Extended Statistics:
		Maximum Segment Size: 1208
		Total Bytes Retransmitted: 2860
		Retransmission Ratio: 0.25%
		Total Bytes Reordered: 140968234
		Average RTT: 34.30769230769231
	RPM: 264 (P90)
	RPM: 509 (Single-Sided 5% Trimmed Mean)
========
Upload:
	Throughput: 30.124 Mbps (3.766 MBps), using 9 parallel connections.
	Extended Statistics:
		Maximum Segment Size: 1208
		Total Bytes Retransmitted: 466855
		Retransmission Ratio: 0.95%
		Total Bytes Reordered: 700
		Average RTT: 37
	RPM: 676 (P90)
	RPM: 2536 (Single-Sided 5% Trimmed Mean)
========
Final RPM Calculation stats:
	Total Self Probes:            933
	Total Foreign Probes:         2799
	Trimmed Self Probes Count:    46
	Trimmed Foreign Probes Count: 139
	P90 Self RTT:                 0.379444841
	P90 Foreign RTT:              0.031294024999999996
	Trimmed Mean Self RTT:        0.035124
	Trimmed Mean Foreign RTT:     0.017979

Final RPM: 292 (P90)
Final RPM: 2260 (Single-Sided 5% Trimmed Mean)
Final RPM (Self Only): 158 (P90)
Final RPM (Self Only): 1708 (Single-Sided 5% Trimmed Mean)
Final RPM (Foreign Only): 1917 (P90)
Final RPM (Foreign Only): 3337 (Single-Sided 5% Trimmed Mean)
Working Conditions RPM Effect:   162% (P90)
Working Conditions RPM Effect:    53% (Single-Sided 5% Trimmed Mean)


The beauty of the self and foreign reports is that here we can see that my cake'd upstream does a decent job to preserve foreign responsiveness while in the self responsiveness we see how TCP self-congests like there is no tomorrow... Please ignore the download direction, this is over a 100 Mbps USB ethernet dongle and my true download shaper is set to 105 Mbps, so this is mostly the bad USB dongle in action...

Re: [Bloat] goresponsiveness learned a few tricks...

[Juliusz Chroboczek]

> (h++ps://github.com/network-quality/draft-ietf-ippm-responsiveness).

There's quite a few good ideas in this draft, but the one that I find
intriguing is reporting RTT values in RPM (units of 1/60 Hz) rather than
milliseconds.

I wonder how well this works.  I'll experiment with undergrads.

-- Juliusz

Re: [Bloat] goresponsiveness learned a few tricks...

[Sebastian Moeller]

Hi Julien,

On 8 January 2024 22:04:23 CET, Juliusz Chroboczek <jch@irif.fr> wrote:
>> (h++ps://github.com/network-quality/draft-ietf-ippm-responsiveness).
>
>There's quite a few good ideas in this draft, but the one that I find
>intriguing is reporting RTT values in RPM (units of 1/60 Hz) rather than
>milliseconds.

That idea, reporting the reciprocal has been around for some time, I think I first heard it from Jonathan Morton. But this is the first implementation....

Now personally I tend to think about 'latency' as sort of a budget, and then accounting where this budget is spent is easier with durations than periods. But I understand the attraction of 'bigger is better' numbers as well. Though most people also know smaller is better number, like product prices or taxes owed, but I digress.


>
>I wonder how well this works.  I'll experiment with undergrads.

The goresponsiveness code is quite readable and might give a convenient starting point for some quick and dirty exploration...

>
>-- Juliusz

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [Bloat] goresponsiveness learned a few tricks...

[David Schinazi]

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

My understanding is that Apple chose to report RTT as an inverse because
people are used to "higher number means better". The target audience for
network speed tests is the average slightly-tech-savvy consumer, and those
aren't all familiar with what latency means. Also, car enthusiasts like
RPMs :-)
David

On Mon, Jan 8, 2024 at 1:53 PM Sebastian Moeller via Bloat <
bloat@lists.bufferbloat.net> wrote:

> Hi Julien,
>
> On 8 January 2024 22:04:23 CET, Juliusz Chroboczek <jch@irif.fr> wrote:
> >> (h++ps://github.com/network-quality/draft-ietf-ippm-responsiveness).
> >
> >There's quite a few good ideas in this draft, but the one that I find
> >intriguing is reporting RTT values in RPM (units of 1/60 Hz) rather than
> >milliseconds.
>
> That idea, reporting the reciprocal has been around for some time, I think
> I first heard it from Jonathan Morton. But this is the first
> implementation....
>
> Now personally I tend to think about 'latency' as sort of a budget, and
> then accounting where this budget is spent is easier with durations than
> periods. But I understand the attraction of 'bigger is better' numbers as
> well. Though most people also know smaller is better number, like product
> prices or taxes owed, but I digress.
>
>
> >
> >I wonder how well this works.  I'll experiment with undergrads.
>
> The goresponsiveness code is quite readable and might give a convenient
> starting point for some quick and dirty exploration...
>
> >
> >-- Juliusz
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>

[-- Attachment #2: Type: text/html, Size: 2470 bytes --]

Re: [Bloat] goresponsiveness learned a few tricks...

[Sebastian Moeller]

Hi David,


> On Jan 9, 2024, at 00:15, David Schinazi <dschinazi.ietf@gmail.com> wrote:
> 
> My understanding is that Apple chose to report RTT as an inverse because people are used to "higher number means better". The target audience for network speed tests is the average slightly-tech-savvy consumer, and those aren't all familiar with what latency means. Also, car enthusiasts like RPMs :-)

	Yes, I understand the rationale, I am just not buying it 100%. As I said people are well accustomed to values were "less is more" (prices, taxes, marathon times, ...) and I am not sure whether catering to the lowest common denominator is all that superior to teaching folks the relevant numbers... After all the trade-off is that now if people want to decompose or aggregate RPM values they need to deal with fractions... However for the responsiveness draft I fully accept that ship has sailed and "bigger is better" it is ;)


Regards
	Sebastian


> David
> 
> On Mon, Jan 8, 2024 at 1:53 PM Sebastian Moeller via Bloat <bloat@lists.bufferbloat.net> wrote:
> Hi Julien,
> 
> On 8 January 2024 22:04:23 CET, Juliusz Chroboczek <jch@irif.fr> wrote:
> >> (h++ps://github.com/network-quality/draft-ietf-ippm-responsiveness).
> >
> >There's quite a few good ideas in this draft, but the one that I find
> >intriguing is reporting RTT values in RPM (units of 1/60 Hz) rather than
> >milliseconds.
> 
> That idea, reporting the reciprocal has been around for some time, I think I first heard it from Jonathan Morton. But this is the first implementation....
> 
> Now personally I tend to think about 'latency' as sort of a budget, and then accounting where this budget is spent is easier with durations than periods. But I understand the attraction of 'bigger is better' numbers as well. Though most people also know smaller is better number, like product prices or taxes owed, but I digress.
> 
> 
> >
> >I wonder how well this works.  I'll experiment with undergrads.
> 
> The goresponsiveness code is quite readable and might give a convenient starting point for some quick and dirty exploration...
> 
> >
> >-- Juliusz
> 
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] goresponsiveness learned a few tricks...

[Michael Richardson]

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


David Schinazi via Bloat <bloat@lists.bufferbloat.net> wrote:
    > My understanding is that Apple chose to report RTT as an inverse because
    > people are used to "higher number means better". The target audience
    > for

Yes.  Stuart was pretty clear about this being the reason for the decision.
It seemed sound then and I still think it's sound.

    > network speed tests is the average slightly-tech-savvy consumer, and those
    > aren't all familiar with what latency means. Also, car enthusiasts like

Marketing people like bigger numbers.
That's where we want things to go: into advertisements.

(I keep asking for 128-bit internet, because it's better than 32-bit 1980s
crap, but then they answer: "Oh, yes! we have 125Mbs LTE")



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 511 bytes --]