From: Pete Heist <peteheist@gmail.com>
To: Dave Taht <dave.taht@gmail.com>
Cc: Luca Muscariello <luca.muscariello@gmail.com>,
Cake List <cake@lists.bufferbloat.net>
Subject: Re: [Cake] Modification of DRR with deficit saving
Date: Fri, 5 Jan 2018 09:19:50 +0100 [thread overview]
Message-ID: <3B5853E8-7B19-4A83-BB59-4C1E47A935BB@gmail.com> (raw)
In-Reply-To: <CAA93jw43Ta39yhJ4QL7bN5xEm2pT6nSayok8C8NP-yOvcTrrOw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1655 bytes --]
> On Jan 4, 2018, at 5:20 PM, Dave Taht <dave.taht@gmail.com> wrote:
>
> Yes, SYN rate limiting is the default (and set very low) in nearly
> everything. That might be measurable. QUIC is now 7% of internet
> traffic.
>
> Done fixing the home. It's time to fix the rest of the internet. And
> that's not just queue theory but address assignment and routing.
> Here's
> a traceroute from where I sit in Nicaragua at the moment, post cake.
> How to figure out exactly how much NAT is on the path?
After the net neutrality rollback in the US (along with the ongoing cable monopolies there), it occurred to me that there may be more interest in cooperative ISPs. Frankly, I don’t know why it hasn’t happened sooner. But having worked with one in Europe, I saw a patchwork of “good enough, kind of” software that is stitched together to get the job done…stuff from Ubiquiti, other vendors and various open source projects of different vintages. In this case they did/do a great job with what’s available, but I think they'd be the first to admit it could be better.
There may be a need for more modern, cross-device management software to serve small to medium sized cooperative ISPs like this, and that there may be a viable, long-term business model here. I picture a small server on each device to be managed and a management server (serving a mobile-first, conversational UI?). Queueing is an important part of this, if a small part of the work as a whole, unfortunately. This wouldn’t be a small undertaking. I’m "just saying” (and getting off the original topic as well, just what I read here made me think of it)…
[-- Attachment #2: Type: text/html, Size: 8117 bytes --]
next prev parent reply other threads:[~2018-01-05 8:19 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-04 14:29 Toke Høiland-Jørgensen
2018-01-04 14:52 ` Dave Taht
2018-01-04 15:01 ` Jonathan Morton
2018-01-04 15:23 ` Luca Muscariello
2018-01-04 15:42 ` Dave Taht
2018-01-04 15:53 ` Luca Muscariello
2018-01-04 16:20 ` Dave Taht
2018-01-04 16:24 ` Luca Muscariello
2018-01-04 16:39 ` Dave Taht
2018-01-05 8:19 ` Pete Heist [this message]
2018-01-04 15:56 ` Sebastian Moeller
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/cake.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3B5853E8-7B19-4A83-BB59-4C1E47A935BB@gmail.com \
--to=peteheist@gmail.com \
--cc=cake@lists.bufferbloat.net \
--cc=dave.taht@gmail.com \
--cc=luca.muscariello@gmail.com \
/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