Thanks for taking a look at this! Please see inline:

On Mar 23, 2022, at 5:34 AM, Bjørn Mork via Rpm <rpm@lists.bufferbloat.net> wrote:

Paul Spooren <mail@aparcar.org> writes:

The spec wants a 8GB file which seems a bit much for common home
routers. We could look into reading from /dev/zero since the body
content isn’t relevant but still the device is likely slower at
offering the content than your laptop can chew. A dedicated device
could be required.

There is no need to read anything from a file or device. You can just
serve the same memory buffer in a loop.

That's right! It does not really need to be a file. Some webserver implementations have such a capability to generate random content in memory. (e.g., https://docs.trafficserver.apache.org/en/9.0.x/admin-guide/plugins/generator.en.html)

I did a quick look at the document and it seems under-specified. Page
after page with blah-blah, but
- not defining Content-Type for any of the URLs

In what way is the content-type relevant for the responsiveness measurement ?

- not defining ciphers or any other TLS options, despite the rather
restrictive TLSv1.3 requirment

I'm not sure in what way the cipher-suites are relevant to the responsiveness measurement itself. In terms of deployment, it is the same as for any other webservice. It is something that is usually not specified in an IETF-draft as cipher-suites come and go.

The TLSv1.3 requirement comes from the fact that we want to measure TLS handshake latency, and by requiring TLSv1.3 we know that the handshake is exactly 1 round-trip. Probably something to clarify in the draft! I filed https://github.com/network-quality/draft-ietf-ippm-responsiveness/issues/37.

- no config examples for common web servers

It is uncommon for an IETF-draft to provide such kind of configurations, because IETF-drafts are aiming to be implementation independent as implementations change, but standards don't.

We have several configurations (and two implementations - one in Go and one in Swift) available at https://github.com/network-quality/server/.

- no actual client algorithm

Section 4 of the draft tries to explain the client algorithm. With specifically Section 4.1.4 formalizing the "working conditions" generation. Can you explain a bit more what parts are unclear to you?

The last point is obviously the biggest problem. You can do whatever
you want when implementng this, so the results from different clients
will not be comparable at all.

IMHO it's better let this soak for a while until they've reversed the
blah-blah to content ratio. This doesn't look like a finished protocol.

We are actively looking for feedback like yours. Please explain more in detail what exactly is unclear, especially regarding the client algorithm.

Thanks,

Christoph