[Rpm] Does RPM measurement *require* a valid SSL certificate

[Rich Brown <richb.hanover@gmail.com>]

I was about to send out the following invitation on the OpenWrt Forum (forum.openwrt.org) when I saw the following in https://github.com/network-quality/server

> NOTE: The networkQuality CLI tool will only connect to a server presenting a valid SSL certificiate [sic]. If you are using a custom CA, ensure the CA is trusted by the system.

This constraint dramatically complicates the rollout of networkQuality servers. In fact, it makes it impractical to run on a home router without a lot of farbling around with Let's Encrypt, etc.

Would the use of a self-signed certificate invalidate the RPM readings? If not, could this constraint be relaxed? Thanks.

Rich


======= Proposed Invitation to OpenWrt developers =========

Subject: Seeking RPM Server package for OpenWrt

Apple has designed an RPM Tool for macOS 12 and iOS 15 that measures the "responsiveness" of your network connection. (Responsiveness is the inverse of latency - the lower the latency, the higher the responsiveness.) 

The RPM Tool counts the number of round-trips per minute (RPM) while the line is fully loaded. A higher number (1,800 RPM and above) is excellent (that's 30 round-trips per second). Below 1,000 RPM is pretty bad. You can read more about it at:

https://www.bufferbloat.net/projects/bloat/wiki/toward_a_consumer_responsiveness_metric#a-proposed-metric-rpm 

Apple has servers that let you test the responsiveness from your device to their network infrastructure. But the RPM test can work locally, as well. It's often the case that local conditions, such as poorly-performing or weak Wi-Fi, dominate the connection. It's important to know whether it's your Wi-Fi, your router, or your ISP (and their connection to the rest of the world) that's causing problems.

Your mission, should you choose to accept it, is to implement the server end of the RPM tooling. It would likely be an OpenWrt package, and would listen to requests from the client on your phone/laptop so that it could measure responsiveness from the device to the router.

There's a full protocol spec in Section 5 of: https://datatracker.ietf.org/doc/html/draft-cpaasch-ippm-responsiveness-00#section-5