[Rpm] Seeking RPM Server package for OpenWrt

[Will Hawkins]

Thank you for all the conversation around RPM. I am one of the
developers of the Go's client that is hosted on Github and I am glad
to answer any questions. It seems like there is already some great
conversation going. I am a little under water with the day job over
the next few days, but please don't assume that I am not interested or
engaged.

Thanks again, everyone! Also, sorry about the top posting -- I just
didn't have anything context sensitive and thought it made sense to
just go at the top!

Will

On Wed, Mar 23, 2022 at 3:23 PM Bjørn Mork via Rpm
<rpm at lists.bufferbloat.net> wrote:
>
> 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
> _______________________________________________
> Rpm mailing list
> Rpm at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/rpm