From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from rn-mailsvcp-ppex-lapp44.apple.com (rn-mailsvcp-ppex-lapp44.rno.apple.com [17.179.253.48]) (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 57A3A3B29E for ; Wed, 23 Mar 2022 14:40:58 -0400 (EDT) Received: from pps.filterd (rn-mailsvcp-ppex-lapp44.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp44.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 22NIZ3su000514; Wed, 23 Mar 2022 11:40:54 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=QypzcbA8MO5N6hLSlw+ESPPNjdHX9WyLfE9AWWhwpSk=; b=OKyedBCfhoRSRNfOCnQql3ORtPnzYoUDBD+JKga+8rTMeYy/z3cm8zVUZ8MlRFZljm0c iqz9UDpHd4nFj0Qz2Aw6R1fdiSSr5qnTULUeV3aOCbvNBuz+zvXr+6jk5KaQwMytVRl0 vs3GxNhYNalesXCaBX5D2mVumWPV0SaoSCzmwhbZAMvY33110g3P4xTzoyWNiyNmnf7y 9nO4UOgHBgbOx2Al/rskgn8QD50s/JvLMX2PuVsl7F7ogW3JiT59vnKi5v7NNEZJmicy 4sy1wfsDc6O3mNVhTLP9YGTNAogVH2Kkunih647rGVtTDJqXImlncGmgVNczlrDJACSX IQ== Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by rn-mailsvcp-ppex-lapp44.rno.apple.com with ESMTP id 3ewap7qsk5-12 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 23 Mar 2022 11:40:54 -0700 Received: from rn-mailsvcp-mmp-lapp04.rno.apple.com (rn-mailsvcp-mmp-lapp04.rno.apple.com [17.179.253.17]) by rn-mailsvcp-mta-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.16.20220118 64bit (built Jan 18 2022)) with ESMTPS id <0R97000T1NW5QUM0@rn-mailsvcp-mta-lapp03.rno.apple.com>; Wed, 23 Mar 2022 11:40:53 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp04.rno.apple.com by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.16.20220118 64bit (built Jan 18 2022)) id <0R9700M00N84A500@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Wed, 23 Mar 2022 11:40:53 -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: 9f1f7f1c-5d3d-4e3a-af9b-2662a5cf92ae 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: 5b6cf2fa-54f8-4941-98d6-15212ac4ab76 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.850 definitions=2022-03-23_04:2022-03-23, 2022-03-23 signatures=0 Received: from smtpclient.apple ([17.192.155.238]) by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.16.20220118 64bit (built Jan 18 2022)) with ESMTPSA id <0R9700RHDNW48900@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Wed, 23 Mar 2022 11:40:52 -0700 (PDT) From: Christoph Paasch Message-id: <96E1CDEB-2329-4263-BE8F-1A9CC7E8BDD3@apple.com> Content-type: multipart/alternative; boundary="Apple-Mail=_6F70D7BB-659D-4D76-889C-335FEC524A55" MIME-version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\)) Date: Wed, 23 Mar 2022 11:40:52 -0700 In-reply-to: <87mthg4zl7.fsf@miraculix.mork.no> Cc: Paul Spooren , Rpm , openwrt-devel@lists.openwrt.org To: =?utf-8?Q?Bj=C3=B8rn_Mork?= References: <94079409-E562-40E6-BF4E-A0A94A926A76@gmail.com> <230DF5D9-1784-4077-819D-B4128CB08686@aparcar.org> <87mthg4zl7.fsf@miraculix.mork.no> 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-23_04:2022-03-23, 2022-03-23 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: Wed, 23 Mar 2022 18:40:58 -0000 --Apple-Mail=_6F70D7BB-659D-4D76-889C-335FEC524A55 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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/generat= or.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 ? > - 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. 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 = . > - 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/ = . > - 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? > The last point is obviously the biggest problem. You can do whatever > you want when implementng this, so the results from different clients > will not be comparable at all. >=20 > IMHO it's better let this soak for a while until they've reversed the > blah-blah to content ratio. This doesn't look like a finished = protocol. We are actively looking for feedback like yours. Please explain more in = detail what exactly is unclear, especially regarding the client = algorithm. Thanks, Christoph --Apple-Mail=_6F70D7BB-659D-4D76-889C-335FEC524A55 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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 <rpm@lists.bufferbloat.net> wrote:

Paul = Spooren <mail@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=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.

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/plug= ins/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 ?

- 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.

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-responsivene= ss/issues/37.

- 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/.

- 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?

The last point is obviously the biggest problem.  You = can do whatever
you want when implementng this, so the = results from different clients
will not be comparable at = all.

IMHO it's better let this soak for a = while until they've reversed the
blah-blah to content = ratio.  This doesn't look like a finished protocol.

We = are actively looking for feedback like yours. Please explain more in = detail what exactly is unclear, especially regarding the client = algorithm.


Thanks,
Christoph


= --Apple-Mail=_6F70D7BB-659D-4D76-889C-335FEC524A55--