From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from louie.mork.no (louie.mork.no [IPv6:2001:41c8:51:8a:feff:ff:fe00:e5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 40F633B29E for ; Wed, 23 Mar 2022 15:23:57 -0400 (EDT) Received: from canardo.dyn.mork.no ([IPv6:2a01:799:c9f:8600:0:0:0:1]) (authenticated bits=0) by louie.mork.no (8.15.2/8.15.2) with ESMTPSA id 22NJNn8C600948 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=OK); Wed, 23 Mar 2022 19:23:51 GMT Received: from miraculix.mork.no ([IPv6:2a01:799:95f:8b0a:1e21:3a05:ad2e:f4a6]) (authenticated bits=0) by canardo.dyn.mork.no (8.15.2/8.15.2) with ESMTPSA id 22NJNn9A1611794 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=OK); Wed, 23 Mar 2022 20:23:49 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mork.no; s=b; t=1648063429; bh=6fAed6jjNp4j7LbPEb4R+MRQAmn2JUVtNr64MMndDzo=; h=From:To:Cc:Subject:References:Date:Message-ID:From; b=Zm54oRlwQz5LEnUmuA/LiCLp1lWlOdItFCC0sWzesMbh/zC2PU3QP3hBtA+TaK0pM igY2LqFQ8AUGXpPvsk4Qw8v6qBqMconjrJlMtGn+lpBCV2vEeH2OOv8N6/cyX/gHrK dkpPKdSEpBbQKsUZPgNXvXTrq0fTZSogX3JJ6p3o= Received: (nullmailer pid 1126158 invoked by uid 1000); Wed, 23 Mar 2022 19:23:43 -0000 From: =?utf-8?Q?Bj=C3=B8rn_Mork?= To: Christoph Paasch Cc: Paul Spooren , Rpm , openwrt-devel@lists.openwrt.org Organization: m References: <94079409-E562-40E6-BF4E-A0A94A926A76@gmail.com> <230DF5D9-1784-4077-819D-B4128CB08686@aparcar.org> <87mthg4zl7.fsf@miraculix.mork.no> <96E1CDEB-2329-4263-BE8F-1A9CC7E8BDD3@apple.com> Date: Wed, 23 Mar 2022 20:23:43 +0100 In-Reply-To: <96E1CDEB-2329-4263-BE8F-1A9CC7E8BDD3@apple.com> (Christoph Paasch's message of "Wed, 23 Mar 2022 11:40:52 -0700") Message-ID: <87y2101ni8.fsf@miraculix.mork.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: clamav-milter 0.103.3 at canardo X-Virus-Status: Clean Subject: Re: [Rpm] Seeking RPM Server package for OpenWrt X-BeenThere: rpm@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: revolutions per minute - a new metric for measuring responsiveness List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2022 19:23:57 -0000 Christoph Paasch writes: > Hello Bjorn, > > Thanks for taking a look at this! Please see inline: > >> On Mar 23, 2022, at 5:34 AM, Bj=C3=B8rn Mork via Rpm wrote: >>=20 >> Paul Spooren writes: >>=20 >>> 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=E2=80=99t relevant but still the device is likely slower at >>> offering the content than your laptop can chew. A dedicated device >>> could be required. >>=20 >> 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/genera= tor.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 measureme= nt ? 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?=20=20 >> - 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 > . 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/ > . 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.=20=20 >> - 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=C3=B8rn