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 <r...@lists.bufferbloat.net> wrote: > > Christoph Paasch <cpaa...@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 > >> <r...@lists.bufferbloat.net> wrote: > >> > >> Paul Spooren <m...@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 > r...@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/rpm _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
