[Cake] isp economics

[Dave Taht]

On Sat, Jul 28, 2018 at 11:39 AM Pete Heist <pete at heistp.net> wrote:

>
> On Jul 28, 2018, at 7:32 PM, Dave Taht <dave.taht at gmail.com> wrote:
>
>
> Exactly. Many members, including myself, are limited by our CPE links
> during off hours, and by the backhaul during high traffic hours.
>
>
> 3 items
>
> 1) Co-locating some essential services (like netflix) might be of help.
>
>
> That’s a good idea, will bring that up with the admins.
>
> Netflix is here now, but many folks seem to use “O2 TV Air”, which is a
> way to watch ordinary cable packages over any Internet connection (not just
> from O2). SD streams are 3Mbit and HD 6Mbit. Weirdly, they don’t pace out
> their data but there’s a characteristic “pulsing” of the streams every 5
> seconds that when I see it on the router's throughput graph I know, yep,
> that’s O2 TV. I’ll find out if their on-demand stuff has such a co-location
> option.
>
> https://openconnect.netflix.com/en/
>
> 2) If the members voted for more backhaul, the costs are understandable…
>
>
> Backhaul upgrades are coming into focus gradually, and upgrading those
> ALIX boxes which are tanks but...tanks.
>

apu2s are thus far being tanks for me. wndr3800s with multi-year cerowrt
uptimes now exist, too.


>
> I think some of the higher costs come from physical installations /
> placement rights. Surprising what towers can cost.
>
> 3) Philosophically I vastly prefer the concept of "everyone sharing
> the network", rather than rate plans, to create some market tension as
> to the available bandwidth at any given time of day.
>
>
> Agree wholeheartedly. Rate limiting members isn’t necessary for a
> non-profit (no profit motive) and especially if we can get fairness right,
> there’s no technical reason to do it that I know of either.
>
>
It would be a better world if more isps served their users and didn't buy
film studios.


> ubnt did add at least airtime fairness to airos a year or two back. It
> was not on by default. Their "TDMA" qos system was this insane mess of
> sfq rules when I tore it apart.... 8 years back.
>
>
> I don’t know what they’re doing in their newer AC stuff, but I'm surprised
> by what appears to be ~6-8ms latency
>

Something fq_codel-like is now in qualcomms proprietary firmware I'm told.
No ecn


> under load on the NanoStation 5 AC Loco’s I got for the camp’s backhaul.
> Is it really that good? This is in contrast to the 50+ms I see with rrul_be
> on the NanoStation M5 (without controlling the queue).
>

ubnt both cases? doubt it's the same bandwidth both cases. should be
proportional to the latency you are seeing. running 2x2 incurs a latency
penalty also.


> This test is straight AP to AP though, with probably 1 flow up and 1 down
> plus ping, so I want to get 2-4 more of these and do rrul_be through the
> Ethernet ports, to get more flows and UDP, and see how it looks then.
>

Run more flows. SFQ is per packet fq. They have right-sized buffers when
the link is running at close to the configured rate, not when it's
stuggling.

I also seem to remember they reduced the txop to ~2ms. turned off 802.11e.
I've recommended this for years now in the general case.

Their 100mbit ethernet devices also do flow control and are more often the
bottleneck than not, so the wifi runs empty more often.

I LIKE their gear. Despite all we've done here there are still things they
do better.


>
>
>

-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cake/attachments/20180728/a8e46085/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ns5ac_loco.png
Type: image/png
Size: 25819 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/cake/attachments/20180728/a8e46085/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ns5ac_loco.png
Type: image/png
Size: 25819 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/cake/attachments/20180728/a8e46085/attachment-0003.png>