From: Paul Spooren <mail@aparcar.org>
To: Rich Brown <richb.hanover@gmail.com>
Cc: "Bjørn Mork" <bjorn@mork.no>,
openwrt-devel <openwrt-devel@lists.openwrt.org>,
Rpm <rpm@lists.bufferbloat.net>
Subject: Re: [Rpm] Seeking RPM Server package for OpenWrt
Date: Wed, 23 Mar 2022 13:02:37 +0000 [thread overview]
Message-ID: <5099D842-68F6-469F-9B54-6E996F669B61@aparcar.org> (raw)
In-Reply-To: <B441EEF6-84A2-4C8B-8D99-02059D55C6A9@gmail.com>
> On 23. Mar 2022, at 12:57, Rich Brown <richb.hanover@gmail.com> wrote:
>
> Bjørn,
>
> Thanks for these comments.
>
>> On Mar 23, 2022, at 8:34 AM, Bjørn Mork <bjorn@mork.no> wrote:
>>
>> There is no need to read anything from a file or device. You can just
>> serve the same memory buffer in a loop.
Thanks, I’ll check that in case I work on a server for OpenWrt.
>
> That might satisfy Paul Spooren's concern.
>
>> 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
I guess it simply don’t matter, just like the content itself? In their demo setups they host either a single `x` (small file) or 4G times `x` (large file).
>> - not defining ciphers or any other TLS options, despite the rather
>> restrictive TLSv1.3 requirment
>> - no config examples for common web servers
https://github.com/network-quality/server
>> - no actual client algorithm
I found this implementation but din’t skim through the full code yet:
https://github.com/network-quality/goresponsiveness/blob/main/networkQuality.go
>>
>> 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.
>
> Although I took an editorial pass over an earlier version of the RFC, I'm not in a position to address your questions.
>
> Let me propose this process for continuing the conversation. With this response, I'm cc'ing:
>
> - openwrt-devel
> - RPM mailing list
> - named individuals
>
> Not everyone is subscribed to both lists, but cc'ing everyone who responds should keep everyone included.
>
> Thank you.
>
> Rich
next prev parent reply other threads:[~2022-03-23 13:02 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-23 11:28 Rich Brown
2022-03-23 12:05 ` Paul Spooren
2022-03-23 12:34 ` Bjørn Mork
2022-03-23 12:57 ` Rich Brown
2022-03-23 13:02 ` Paul Spooren [this message]
2022-03-23 18:40 ` Christoph Paasch
2022-03-23 19:23 ` Bjørn Mork
2022-03-24 3:58 ` Will Hawkins
2022-03-24 20:15 ` Christoph Paasch
2022-03-23 12:39 ` Rich Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/rpm.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5099D842-68F6-469F-9B54-6E996F669B61@aparcar.org \
--to=mail@aparcar.org \
--cc=bjorn@mork.no \
--cc=openwrt-devel@lists.openwrt.org \
--cc=richb.hanover@gmail.com \
--cc=rpm@lists.bufferbloat.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox