From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 821AE3B29E for ; Wed, 23 Mar 2022 23:58:27 -0400 (EDT) Received: by mail-ej1-x635.google.com with SMTP id dr20so6681639ejc.6 for ; Wed, 23 Mar 2022 20:58:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=obs-cr.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=UKtFZXxVCT368j5RER8r5A3pD8IwgGHBixVMkEuvb48=; b=YrSe9xJmkkvzNBmjuXqDtaSkcvXTcRcNMWCXGfxN3H0xpa1txQ6KQMDEXnyGOhO0PY g5ED+PrU5pEUUaCCWpWEcwLCC9ziDPvAhRIfO/YhkU7SdH+MOINzETRKGJUI/p/1tEPQ envwTCIfTAgDCAH4b2ojRQGq3OZcOD7tnVVqcry3HLNewmjVbaHV0uET4dtDyL+Ipobk eEF8j9ShIj17vmygiCqqGVMUVjZ+HntBURNUZB//SNaVA2/Wo7dMAr0iEgi6sWkl7AMv nGSSnwzAvM9CpbLnbZinVs5eSzqxddtTgmIholvqkt0N0DyyWWcJfzd73kgzURxpeCPg xl1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=UKtFZXxVCT368j5RER8r5A3pD8IwgGHBixVMkEuvb48=; b=gdl7P4V+Lh5bUfmx4ABoi7qPhDXzmr3C4IHqgWV8SfOWYi6dh4iyNk7KsDARhurYV0 94CF0CuP3hVOiohxnijqoU1jvklsBlbtCTQ8kalfByrh2BwbWRSkFKMOdR2A7TXqUN/6 Vz3am1VoKv1NAj3jjYliZy9ADOuWS3bxPf2s8vPnsrrQ+CJteZw7pCEXRdy399w4+sVl QAahp9W6aAs/T5Xx5cZnBPskjqiZ2T+gOcLB6RoUAI3SPnUr2xVag6AL9QbCJJZYIQks CPOrSzfxnlj10eXNNg1kJNQ0rKmy+b32kzh///as7sZ+m81qHezy+UDYhZZlLKIcJNGa RuNg== X-Gm-Message-State: AOAM532RDG9BObDrZix0bLpyDsjk+RDbDbX5HQy55/8nztUHPpzsK4xB qFWlHA07wOpMdXOkFZk8ozglPAQdMbC4QoYNtymfSw== X-Google-Smtp-Source: ABdhPJyy6cgTsedKQtHUmkoy8RK59g2syYHvkREfDnNbSFEFGVBRgV6gjYcBhtn9E1s9tZpk8U55Bxy79aHOOLhmp+E= X-Received: by 2002:a17:907:9718:b0:6e0:6faa:3aa with SMTP id jg24-20020a170907971800b006e06faa03aamr3607818ejc.307.1648094306049; Wed, 23 Mar 2022 20:58:26 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: <87y2101ni8.fsf@miraculix.mork.no> From: Will Hawkins Date: Wed, 23 Mar 2022 23:58:15 -0400 Message-ID: To: =?UTF-8?Q?Bj=C3=B8rn_Mork?= Cc: Christoph Paasch , Rpm , openwrt-devel@lists.openwrt.org, Paul Spooren Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 03:58:27 -0000 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=C3=B8rn Mork via Rpm wrote: > > 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: > >> > >> Paul Spooren 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/plugins/gene= rator.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 measure= ment ? > > 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/issue= s/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. > > >> - 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 > _______________________________________________ > Rpm mailing list > Rpm@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/rpm