From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from rn-mailsvcp-ppex-lapp14.apple.com (rn-mailsvcp-ppex-lapp14.rno.apple.com [17.179.253.33]) (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 3814C3CB35 for ; Thu, 24 Mar 2022 16:15:25 -0400 (EDT) Received: from pps.filterd (rn-mailsvcp-ppex-lapp14.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp14.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 22OK9Lkc019282; Thu, 24 Mar 2022 13:15:21 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=M8aubK0IxDSajLljV6EMEx+DxK3z5KhiRm9pfKjz1gc=; b=sueIuG3wgqrPwvG0YhUQgsBqbSXO+5+ei2m/9JYUJ6xmt6/IVD+KRAYGhRO9ilpoJ9Gp JWXQT5EHp+lx+ORDaCZ6FG3WSl/1GNx5/OJdjgtRPn5c1K1M6BoiGLe76hnQDS+4mY3u M8OnOUfsvQhQOy823+UpjhBrNMdITRKS14pDsmawLeUbS8kPGWl/1w001WRmPbZSlJVI IQzrZo30tSLXN1M6CGCZCwfeLonkVCP/I9ZYr8eua7FcVI7YoKZyxST7YQXa+rgQjC8d v1UqnKaEEZglj/Cq8fH7VcGArTRKDL61Ldo8f5Js/DEMpBubK6FqvA/AAcNz/b9AYmt/ HA== Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com [10.225.203.149]) by rn-mailsvcp-ppex-lapp14.rno.apple.com with ESMTP id 3ewc2c01qm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 24 Mar 2022 13:15:21 -0700 Received: from rn-mailsvcp-mmp-lapp01.rno.apple.com (rn-mailsvcp-mmp-lapp01.rno.apple.com [17.179.253.14]) by rn-mailsvcp-mta-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.16.20220118 64bit (built Jan 18 2022)) with ESMTPS id <0R9900YSFMXLTX60@rn-mailsvcp-mta-lapp01.rno.apple.com>; Thu, 24 Mar 2022 13:15:21 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp01.rno.apple.com by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.16.20220118 64bit (built Jan 18 2022)) id <0R9900800MTV9800@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Thu, 24 Mar 2022 13:15:21 -0700 (PDT) X-Va-A: X-Va-T-CD: 23fc52e70f15203fd31e1e73ec64ed63 X-Va-E-CD: bf8bcd32ed3d841483ad67ec6a69f9c4 X-Va-R-CD: e39dffeb72f797916b9249b4031c32a4 X-Va-CD: 0 X-Va-ID: fa0e7921-3a91-4580-a1da-134e469daa06 X-V-A: X-V-T-CD: 23fc52e70f15203fd31e1e73ec64ed63 X-V-E-CD: bf8bcd32ed3d841483ad67ec6a69f9c4 X-V-R-CD: e39dffeb72f797916b9249b4031c32a4 X-V-CD: 0 X-V-ID: b90db223-6cea-4511-ba4e-1b00aea467e3 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.850 definitions=2022-03-24_06:2022-03-24, 2022-03-24 signatures=0 Received: from smtpclient.apple ([17.192.155.238]) by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.16.20220118 64bit (built Jan 18 2022)) with ESMTPSA id <0R9900XAZMXK3S10@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Thu, 24 Mar 2022 13:15:20 -0700 (PDT) Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\)) From: Christoph Paasch In-reply-to: <87y2101ni8.fsf@miraculix.mork.no> Date: Thu, 24 Mar 2022 13:15:20 -0700 Cc: Paul Spooren , Rpm , openwrt-devel@lists.openwrt.org Content-transfer-encoding: quoted-printable Message-id: 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> <87y2101ni8.fsf@miraculix.mork.no> To: =?utf-8?Q?Bj=C3=B8rn_Mork?= X-Mailer: Apple Mail (2.3696.80.82.1.1) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.850 definitions=2022-03-24_06:2022-03-24, 2022-03-24 signatures=0 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: Thu, 24 Mar 2022 20:15:25 -0000 > On Mar 23, 2022, at 12:23 PM, Bj=C3=B8rn Mork wrote: >=20 > Christoph Paasch writes: >=20 >> Hello Bjorn, >>=20 >> Thanks for taking a look at this! Please see inline: >>=20 >>> 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. >>=20 >> 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/generat= or.en.html >> = ) >>=20 >>> 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 >>=20 >> In what way is the content-type relevant for the responsiveness = measurement ? >=20 > 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. We could add a line saying that the content-type does not matter and = must be ignored. > This is pretty basic for any API. Maybe use OpenAPI or similar to > for clarity instead of the home-grown API spec?=20 I feel like OpenAPI is quite a different beast compared to what we are = doing here. >>> - not defining ciphers or any other TLS options, despite the rather >>> restrictive TLSv1.3 requirment >>=20 >> 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. >=20 > 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. This is a deployment problem, not a specification-problem for the = particular purpose of measuring responsiveness. For example, we don't specify whether IPv4 or IPv6 should be used. Also, if we list cipher-suites and one of them gets deprecated our RFC = would need to be updated as well. >> 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/3= 7 >> = . >=20 > Yes, that makes sense. Thanks for explaining. And I believe you should > include the explanation in the draft as well. >=20 >>> - no config examples for common web servers >>=20 >> 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/ >> . >=20 > I believe it's common to include a reference implementation if it's > semi-trivial, like the server side of this spec is. >=20 > 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 Yeah, it could make sense to put something in the appendix = (https://github.com/network-quality/draft-ietf-ippm-responsiveness/issues/= 39) >=20 > 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 >>=20 >> 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? >=20 > Re-reading this, I realize that I went out to harsh here. Sorry. >=20 > I think it can be improved by replacing things like >=20 > "It is left to the implementation what to do when saturation is not > reached within that time-frame." >=20 > with a precise description of what to do. There are two approaches here: Either, the implementation aborts and errors out. Or, the implementation nevertheless measures the responsiveness and = either presents the result as a valid result or as a result with a low = confidence score. We can probably outline the options that an implementation has. = (https://github.com/network-quality/draft-ietf-ippm-responsiveness/issues/= 40) Thanks for your feedback, Christoph