[Rpm] Seeking RPM Server package for OpenWrt

[Bjørn Mork]

Christoph Paasch <cpaasch at apple.com> writes:

> Hello Bjorn,
>
> Thanks for taking a look at this! Please see inline:
>
>> On Mar 23, 2022, at 5:34 AM, Bjørn Mork via Rpm <rpm at lists.bufferbloat.net> wrote:
>> 
>> Paul Spooren <mail at 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
> <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 ?

It becomes relevant once one of the client or server implementations
start making assumptions about it.  Worst case is that you have two
implementations making different assumptions. So you specify strict
requirments to avoid that.

This is pretty basic for any API.  Maybe use OpenAPI or similar to
for clarity instead of the home-grown API spec?  


>> - 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.

They're relevant the same way the Content-Type is.  If you don't say
anything then you might end up with all sorts of incompatible
configurations.


> 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
> <https://github.com/network-quality/draft-ietf-ippm-responsiveness/issues/37>.

Yes, that makes sense.  Thanks for explaining.  And I believe you should
include the explanation in the draft as well.

>> - 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/
> <https://github.com/network-quality/server/>.

I believe it's common to include a reference implementation if it's
semi-trivial, like the server side of this spec is.

And it's not unheard of that this reference implementation is given as
configuration examples, in cases where the documenent can be implemented
by configuring existing software.  For example:
https://datatracker.ietf.org/doc/html/rfc8806

Now I must admit that I haven't actually tried.  But I assume it's
possible to use most web servers for this purpose.  Or a pretty simple
python script, maybe.  

>> - 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?

Re-reading this, I realize that I went out to harsh here.  Sorry.

I think it can be improved by replacing things like

   "It is left to the implementation what to do when saturation is not
   reached within that time-frame."

with a precise description of what to do.

But overall, you're right.  The algorithm is good enough.



Bjørn