[Rpm] Seeking RPM Server package for OpenWrt
hawkinsw at obs.cr
Wed Mar 23 20:58:15 PDT 2022
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
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!
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
> > 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:
> 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.
> Rpm mailing list
> Rpm at lists.bufferbloat.net
More information about the openwrt-devel