[Cake] apologies for the email flood

[Dave Taht via Cake]

it has been a long time since I cleaned out the backlog of email in
the cake mailboxes.

I am hoping at least some of that did not wind up in a spam folder?
Particularly to gmail?

-- 
https://www.youtube.com/watch?v=BVFWSyMp3xg=1098s Waves Podcast
Dave Täht CSO, LibreQos
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

[Cake] waves podcast is out

[Dave Taht via Cake]

I did my usual bufferbloat rap on this pretty excellent podcast. What
I am most proud of however,
was showing off my mom´s art in this segment here, including her most
powerful piece "Sad Sam".

https://www.youtube.com/watch?v=BVFWSyMp3xg=1098s

-- 
https://www.youtube.com/watch?v=N0Tmvv5jJKs Epik Mellon Podcast
Dave Täht CSO, LibreQos
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

[Cake] fq_codel in vyos

[Dave Taht via Cake]

It is amazing how many different ways people can do themselves in with
knobs. In this case there was an off-by-1000 error in calculating the
fq_codel target and interval.

https://forum.vyos.io/t/what-kind-of-performance-should-be-expected-when-applying-fq-codel-on-a-shaper-policy/13841

But I am delighted to see the switch happening over there in the
upcoming release.


-- 
https://blog.cerowrt.org/post/2024_predictions/
Dave Täht CSO, LibreQos
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] cake's ack-filter vs GSO

[Dave Taht via Cake]

My memory about all this stuff is extremely scrambled by the mvneta
driver which ws the first thing that drove me to consider GSO
splitting in the first place.

That evolved significantly. I also remember XMIT_more costing us more
bandwidth than it gained, on the wndr3800, due to eating more cpu or
icache. Then there was the change in how inbound skbs were processed
overall, and innumerable attempts to remove locks from pfifo_fast, and
... ghu knows what else has changed. How does packet pacing affect
things? How much BBRv3 buffers?

I am no longer certain of anything. I am pretty sure, however, that
vikings were not black.

https://gizmodo.com/google-anti-woke-babies-gemini-black-vikings-1851275422

I asked the latest AIs for summaries as to what fq_codel does, what
products it is in, and it was slightly wrong in all cases.

What products have fq_codel in them?" was pretty good.

It just missed apple.

Asking gemini again:

"Is the pie aqm better than fq_codel? How do both compare to CAKE" was also fun.

It generated a really nice table. And made my skin itch at the inaccuracies.

Is the pie aqm better than fq_codel? How do both compare to CAKE?

On Fri, Feb 23, 2024 at 11:39 AM Toke Høiland-Jørgensen  wrote:
>
> Dave Taht  writes:
>
> > On Sun, Feb 18, 2024 at 8:37 AM Toke Høiland-Jørgensen  wrote:
> >>
> >> Dave Taht via Cake  writes:
> >>
> >> > It has been years since I looked at cake's code.
> >> >
> >> > Does anyone remember why we do not ack-filter a gso-split?
> >>
> >> Because a GSO packet cannot be a pure ACK, so it wouldn't be filtered
> >> anyway...
> >
> > But a GRO packet can, and most likely IS a pure ack packet train that
> > could and should be thinned. I think. Yes?
>
> Erm, no, because those would have header differences and so wouldn't be
> combined into a single GRO packet...
>
> -Toke



-- 
https://blog.cerowrt.org/post/2024_predictions/
Dave Täht CSO, LibreQos
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] cake's ack-filter vs GSO

[Dave Taht via Cake]

On Sun, Feb 18, 2024 at 8:37 AM Toke Høiland-Jørgensen  wrote:
>
> Dave Taht via Cake  writes:
>
> > It has been years since I looked at cake's code.
> >
> > Does anyone remember why we do not ack-filter a gso-split?
>
> Because a GSO packet cannot be a pure ACK, so it wouldn't be filtered
> anyway...

But a GRO packet can, and most likely IS a pure ack packet train that
could and should be thinned. I think. Yes?

Anyway, I put in for a small grant a few months ago with NLNET on this
(and keep hoping that somewhere out there, there are more orgs using
cake willing to throw in? I mean there are hundreds now! Can anyone
reach out to them?)

It might be approved in a month or so - but it also had scope in
looking at transports and the BSDs, and I keep hoping to somehow find
enough resources to have a project with 3 core folk running at it part
time for 2 years.

https://docs.google.com/document/d/1tTYBPeaRdCO9AGTGQCpoiuLORQzN_bG3TAkEolJPh28/edit

Elsewhere a volunteer started some work on validating the fq_codel
implementations of openbsd and freebsd. The results are interesting!
The "wrong" openbsd version with a 400 count cap does not behave much
differently from the one with the pure newton invsqrt approximation in
the tests so far. Can anyone suggest tests to exercise it?

Do I have the energy to write them up yet? No. I might start yet
another mailing list to discuss it. My long term hope is to gain
enough experience, somehow get cake ported over to those OSes
eventually, but I would settle for just quieting the noise in the
opnsense world.

I am trying to have a BQL discussion on the netdev list also, about
virtio-net...

Maybe this presentation will gain traction:
https://www.youtube.com/watch?v=rWnb543Sdk8=2603s


>
> -Toke



--
https://blog.cerowrt.org/post/2024_predictions/
Dave Täht CSO, LibreQos
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

[Cake] cake's ack-filter vs GSO

[Dave Taht via Cake]

It has been years since I looked at cake's code.

Does anyone remember why we do not ack-filter a gso-split?

https://github.com/dtaht/sch_cake/blob/master/sch_cake.c#L1901


-- 
40 years of net history, a couple songs:
https://www.youtube.com/watch?v=D9RGX6QFm5E
Dave Täht CSO, LibreQos
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

[Cake] glados does tom-tom

[Dave Taht via Cake]

https://www.youtube.com/watch?v=tQxIgJooqHg

-- 
40 years of net history, a couple songs:
https://www.youtube.com/watch?v=D9RGX6QFm5E
Dave Täht CSO, LibreQos
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] CAKE AQM- security

[Dave Taht via Cake]

The cake mailing list is more appropriate for this question, but as it
has not come up much before, I figured I would attempt to answer it.

In general, FQ and AQM technologies are more resistant to simple
floods and even DDOS attacks than a FIFO. Starting with FQ first,
a single DOS (or unresponsive flow) ends up invisible to the overall
operation of the queues aside from running the qdisc to its memory
limit. Fq_codel then drops robustly (the drop_batch facility drops 64
packets at a time), or cake engages the "blue" algorithm which
operates on a per packet basis, usually before it hits the memory
limit. Both of these defenses operate independently of if a packet is
ECN marked or not.

There was an infamous bug where the odhcpd client would have an
overflow at 51 days, and then flood the upstream with dhcpv6 requests,
which was invisible to the fq_codeled end user (but not the
provider!). Had it been on a FIFO perhaps that bug would have been
noticed sooner.

Running out of memory somewhere in the system in general has bad
side-effects but they are common to all queueing mechanisms. fq_codel
and cake are perhaps more subject to running small systems out of
memory than most FIFOs as their defaults are sized to handle 10Gbit
traffic. Openwrt patches down cake and fq_codel to saner defaults for
tiny systems (64MB ram typically) running at less than a gbit/sec.

A DDOS attack is handled fairly well (and in all cases better than a
FIFO, we think - luca muscarillo has a paper on it) by a FQ technology
- the hash used against the 5 tuple is salted by a random number
created at instantation time so the underlying tuple must have many,
many flows in order to completely disable the link. 1024 flows will
knock out cake, but a FIFO would have fallen over long before that.

These days on DC links where we see fq_codel, there are multiple
hardware queues so there are 1024*cores fq_codel queues in play. There
is a slight difference between cake and fq_codel, where in that case
fq_codel attempts to get the total queue time down below 5ms (by
default) over time and load, even dropping the last packet in a queue,
where cake takes the latency hit and tries to deliver the last packet
in a queue, except when blue is engaging. We keep hoping to see more
cake in the DC...

Moving onto AQM technology:

There was an attack published against RED many years ago which used
short bursts and RED's decay time to cause collateral damage. I think
all single queued AQMs are subject to attacks like these, but to what
extent is unknown.

Adding ECN into the mix increases the vulnerability to non-ecn'd
packets to be dropped while the ECN packets are preserved.

A ping -f -s 1400 -Q 1 somewhere is sufficient to DOS the dualpi L4S
queue. -Q 1 or -Q 2 sufficient to DOS a single codel, pie, or RED
queue (with ecn enabled)

The simplicity of ECN'd DOS attacks like these led to us leaving ecn
off by default in the single queued implementations of codel and pie,
but we were encouraged to enable ECN for fq_codel and fq_pie so
RFC3168 style ecn is supported by default for the users of it there,
at least in Linux.

The L4S architecture specification contains elaborate out of band
defenses against {D}DOS attacks but not in the qdisc itself (e.g. the
code I have seen has neither the drop_batch or blue facilities in
fq_codel and cake). In serious cases of DOS or DDOSes the current
architectures for blackholing that sort of traffic somewhere else via
bgp/cloudflare/etc apply. I am not aware of any service presently
targetting coping with mis-marked, mis-behaving ECN'd traffic, nor of
any ECN-enabled attacks, though I viewed those as inevitable if ecn
ever took off.

There are no doubt "interesting" new edge cases and attacks against
these AQM and FQ technologies, which cost me sleep because I cannot
forecast what they will be, and will no doubt take heat for one when
one inevitably occurs.

On Thu, Jan 25, 2024 at 12:20 AM Muhammad Ahsan
 wrote:
>
>
>
> Hi,
>
>
>
> I was wondering , if anyone can share the security related part of  CAKE AQM .
>
> I mean the security considerations CAKE takes into account in preventing 
> against certain LDDOS, spoofing type attacks. etc
>
>
>
>
>
> Rgds,
>
> Ahsan



-- 
40 years of net history, a couple songs:
https://www.youtube.com/watch?v=D9RGX6QFm5E
Dave Täht CSO, LibreQos
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

[Cake] cake on vyos

[Dave Taht via Cake]

Fun POST and discussion here:

https://news.ycombinator.com/item?id=39101564


-- 
40 years of net history, a couple songs:
https://www.youtube.com/watch?v=D9RGX6QFm5E
Dave Täht CSO, LibreQos
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] Ubiquity (Unifi ) Smart Queues

[Dave Taht via Cake]

Principal limitation for libreqos on a small box is has to have
multiple hardware queues and support eBPF.

Seriously folks, running libreqos at home is *serious overkill*,
although I have to admit the traffic graphs are mesmerizing!!! One of
our ISPs has been setting them to music:
https://www.youtube.com/@trendaltoews7143

Herbert has been working on adding all sorts of other analytics to it also.

On Tue, Jan 9, 2024 at 12:07 PM dave seddon  wrote:
>
> Nils - I guess you could run LibreQoS on N100?
>
> On Tue, Jan 9, 2024 at 8:57 AM Nils Andreas Svee via Cake 
>  wrote:
>>
>> On Jan 9, 2024, at 17:05, Dave Taht  wrote:
>>
>> On Tue, Jan 9, 2024 at 10:40 AM Nils Andreas Svee via Cake
>>  wrote:
>>
>> Though frankly, I don’t plan on updating the sch_cake and tc binaries when 
>> new firmwares are released anymore, as they don’t publish the GPL archives 
>> on their webpage after the redesign, and they don’t respond to requests for 
>> them either by the looks of the forums. So if it breaks there’s not much I 
>> can do anymore.
>>
>>
>> This irks me enormously. It is the direct outcome of the cambium
>> elevate lawsuit, where both companies lost, the ISPs lost, open source
>> practices long established about publishing sources, lost, and the
>> lawyers went on to other nasty things leaving this trail of awful
>> precedents  in their wake.
>>
>> https://www.mtin.net/blog/ubnt-vs-cambium/
>>
>> Wow, hadn’t read about that. They even sued an ISP just for using Cambium’s 
>> software on their hardware?
>> That is crazy, just evil corporate lawyers doing their thing I guess.
>>
>> I do not know what to do about it. It also irks me that as a
>> contributor to "smart queues" they are not maintaining it well.
>>
>> It leaves something to be desired yes, and I would’ve hoped to see CAKE 
>> included too of course,
>> but even WireGuard is only available in the latest release candidates with 
>> the redesigned web UI, so I’m not holding my breath.
>>
>> I still have an EdgeRouter 4 that serves the family farm and one of the 
>> 8-port switches under my desk, if only because I don’t wanna spend money on 
>> replacing them, and they do serve their purpose.
>>
>> I’ve since moved though, and now live in an area that has FTTH, so I needed 
>> something beefier to handle CAKE on a 750/750 subscription, because 
>> obviously there’s still bloat even on that ;)
>>
>> One of those Chinese boxes with a N100 in it and OpenWrt on top works 
>> wonders :)
>>
>> Best Regards,
>> Nils Andreas Svee
>> ___
>> Cake mailing list
>> Cake@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cake
>
>
>
> --
> Regards,
> Dave Seddon
> +1 415 857 5102



-- 
40 years of net history, a couple songs:
https://www.youtube.com/watch?v=D9RGX6QFm5E
Dave Täht CSO, LibreQos
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] Ubiquity (Unifi ) Smart Queues

[Dave Taht via Cake]

On Tue, Jan 9, 2024 at 10:40 AM Nils Andreas Svee via Cake
 wrote:

> Though frankly, I don’t plan on updating the sch_cake and tc binaries when 
> new firmwares are released anymore, as they don’t publish the GPL archives on 
> their webpage after the redesign, and they don’t respond to requests for them 
> either by the looks of the forums. So if it breaks there’s not much I can do 
> anymore.

This irks me enormously. It is the direct outcome of the cambium
elevate lawsuit, where both companies lost, the ISPs lost, open source
practices long established about publishing sources, lost, and the
lawyers went on to other nasty things leaving this trail of awful
precedents  in their wake.

https://www.mtin.net/blog/ubnt-vs-cambium/

I do not know what to do about it. It also irks me that as a
contributor to "smart queues" they are not maintaining it well.

>
> Best Regards,
> Nils Andreas Svee
>
> On Jan 3, 2024, at 14:44, Pete Heist via Cake  
> wrote:
>
> On Tue, 2024-01-02 at 10:59 -0800, dave seddon via Cake wrote:
>
> I thought people might be interested to see what Ubiquity/Unifi is
> doing with "Smart Queues" on their devices.  The documentation on
> their website is not very informative.
> 
> "Smart Queue" Implementation
>
> Looks like they only apply tc qdiscs to the Eth2, and sadly this is
> NOT cake, but fq_codel.
>
> And cake isn't available :(
>
> root@USG-Pro-4:~# tc qdisc replace dev eth0 cake bandwidth 100m rtt
> 20ms
> Unknown qdisc "cake", hence option "bandwidth" is unparsable
>
>
> Hi Dave, there's a community contributed version of Cake for EdgeRouter
> devices that I've been using for years on production ER-X's:
>
> https://community.ui.com/questions/Cake-compiled-for-the-EdgeRouter-devices/fc1ff27c-f321-4344-8737-fcc755cae8a2
>
> I don't think that works for UniFi/USG devices, however, and one should
> note the disclaimer and be careful when installing it. Also, it must be
> re-installed after every upgrade.
>
> Cheers,
> Pete
>
> ___
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
>
>
> ___
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake



-- 
40 years of net history, a couple songs:
https://www.youtube.com/watch?v=D9RGX6QFm5E
Dave Täht CSO, LibreQos
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] Ubiquity (Unifi ) Smart Queues

[Dave Taht via Cake]

It is so nice to see this list come to life again.
I just wanted to point out that the inbound drop rate was merely .03%
in the first email.

Elsewhere we keep hearing of 1-2% drop rates being common, and I just
aint seeing it in any of the larger scale data I have been getting
from the libreqos deployment. Maybe that´s how fifos collapse in slow
start a lot more than we have ever observed. Maybe it is retransmits
going wild at 250ms worth of buffering.

scale=10
10688/29185742
.0003662062

I still have to sit back and admire you all for this magnificent
achievement of cake. I am not really the gloating sort, but seeing
juniper go up for sale to hpe today, at a firesale price, is oddly
satisfying.

https://blog.cerowrt.org/post/juniper/



On Tue, Jan 9, 2024 at 10:40 AM Nils Andreas Svee via Cake
 wrote:
>
> You’re unlikely to do any real harm though, but the warning is there cause 
> you can potentially soft brick your router using it. I’ve run into that 
> myself if I remember correctly, where after a firmware upgrade the kernel had 
> slightly changed, so loading the sch_cake module caused it to panic. And I 
> had it start through /config/scripts/post-config.d of course, so it would 
> happen on every restart.
>
> Nothing a factory reset won’t solve, but annoying when if you’re messing 
> about remotely :)
>
> As for USG, I think I used to have some binaries for those too. I do still 
> have some old kernel sources for them laying around in a repo.
> It’s been awhile, but I probably stopped building for those as it wasn’t as 
> straightforward to keep up with the versions of the firmware.
>
> Though frankly, I don’t plan on updating the sch_cake and tc binaries when 
> new firmwares are released anymore, as they don’t publish the GPL archives on 
> their webpage after the redesign, and they don’t respond to requests for them 
> either by the looks of the forums. So if it breaks there’s not much I can do 
> anymore.
>
> Best Regards,
> Nils Andreas Svee
>
> On Jan 3, 2024, at 14:44, Pete Heist via Cake  
> wrote:
>
> On Tue, 2024-01-02 at 10:59 -0800, dave seddon via Cake wrote:
>
> I thought people might be interested to see what Ubiquity/Unifi is
> doing with "Smart Queues" on their devices.  The documentation on
> their website is not very informative.
> 
> "Smart Queue" Implementation
>
> Looks like they only apply tc qdiscs to the Eth2, and sadly this is
> NOT cake, but fq_codel.
>
> And cake isn't available :(
>
> root@USG-Pro-4:~# tc qdisc replace dev eth0 cake bandwidth 100m rtt
> 20ms
> Unknown qdisc "cake", hence option "bandwidth" is unparsable
>
>
> Hi Dave, there's a community contributed version of Cake for EdgeRouter
> devices that I've been using for years on production ER-X's:
>
> https://community.ui.com/questions/Cake-compiled-for-the-EdgeRouter-devices/fc1ff27c-f321-4344-8737-fcc755cae8a2
>
> I don't think that works for UniFi/USG devices, however, and one should
> note the disclaimer and be careful when installing it. Also, it must be
> re-installed after every upgrade.
>
> Cheers,
> Pete
>
> ___
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
>
>
> ___
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake



-- 
40 years of net history, a couple songs:
https://www.youtube.com/watch?v=D9RGX6QFm5E
Dave Täht CSO, LibreQos
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

[Cake] got no idea if commscope uses cake, but

[Dave Taht via Cake]

https://www.commscope.com/globalassets/digizuite/956410-low-latency-home-ebook-eb-116763-en.pdf

-- 
:( My old R campus is up for sale: https://tinyurl.com/yurtlab
Dave Täht CSO, LibreQos
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

[Cake] Bufferbloat.net fund drive

[Dave Taht via Cake]

Donations to the core bufferbloat effort are at an all time low,
$832.00/month. [1]

I am presently also in the process of finalizing a response to a FCC
NOI for which I will conduct another funding (and signature!) drive
later this week. It is due December 1, and I hope to start circulating
a rough draft nov 27th.

This past year:

Presently bufferbloat.net's fixed expenses run at about $542/month for
Linode hosting of the website and the worldwide fleet of flent test
servers. We have a grant from Equinix for bare metal hardware (but
mostly used that up for libreqos (other uses of bare metal wanted?)).
We had another grant from NLnet covering some but *far* from all of
LibreQos's costs. Thank you to both those orgs for their support this
past year!

... but if anyone (or their organisation) would like to throw in to
keeping the servers alive, and to me for maintaining and moderating
these lists... please click here: https://www.patreon.com/dtaht . I
have to admit being a little overstretched, right now.

For the past year, most (nearly all of mine, anyway) of our efforts
have been focused on making LibreQos the fastest, most stable CAKE
shaping and packet analysis tool anyone has ever seen, making ISPs
capable of deploying better user experiences, overnight.

The LibreQos team shipped v1.4 with massive improvements across the
board last week!

We have not got around to a bigger release announcement yet - there
were some teething pains that might result in a v1.4.1 respin!
LibreQos can push 25Gbits for 10,000 ISP network subscribers across 20
cores of Xeon running 50% idle through 10k instances of the CAKE
qdisc. For an ISP, the CAPEX/subscriber to deploy is a few dozen
pennies, once, the time-to-first-deployment measured in weekends. Tell
your ISPs about it? The core of LibreQos is GPLv2 software, available
from github and leverages C, python and Rust.

A huge thanks to herbert, robert, frank, trendal, dan, lachlan, mark,
naiux and the other 180 people in the matrix chat channel now using it
for all the development and testing and deployment to date.

LibreQoE, LLC (the group of founders behind it, which includes me)
have a plan for a commercial addon for LTS (Long-term statistics) for
this but the core shaping and analysis engine will always remain libre
software. rust/python/C developers, testers, the merely curious
network nerd, the ISP that wants to make serious strides on latency
and make their gamers and voipers and videoconfrencers happier, please
have at it. I will be talking more abut LibreQoS's global analysis of
worldwide packet flow statistics  at the upcoming UnderstandingLatency
conference Dec 11-13.

I was very pleased to see the OpenWrt 23 release happen last month,
chock full of net goodness (my thanks to everyone on that team!) I
hope y'all have been upgrading! If you are in a donating mood, that
org always could use some, too.

In other business...

I really need to sit down and write up all the amazing stuff that
happened this year sometime next month. Please forgive me for if I
missed you below... or step forth and toot your own horn? Drop me an
email privately and tell me what you did so I can include it in the
end of year report?

Especially at this moment: I would like to thank Dave Seddon very much
to getting at the bottom of all the ARM64 issues w/fq_codel and w/cake
we have been seeing all year. It turned out that nearly half the arm64
ethernet drivers he looked at were broken in some way, that there are
some severe memory bandwidth issues that affect even FIFOs on the low
end... and that the pi5 is looking good. There has been some progress
on fixing those arm drivers since.

I would like to thank also Jamal at netdevconf for asking me for talks
in Canada last month. It had a focusing effect, and brought me into
contact with a new generation of developers.

Moving forward into next year, in particular right now, on my mind -
if anyone knows of some org that can help on the next version of cake
as the next openwrt development cycle ramps up (making it multicore
among other things), please let me know off-list.

https://docs.google.com/document/d/1tTYBPeaRdCO9AGTGQCpoiuLORQzN_bG3TAkEolJPh28/edit#heading=h.vbbnfu73wlpp

Thank you everyone for all your efforts in beating the bloat,
worldwide. Never has so much been accomplished by so many, on so
little, in (admittedly) 14 years of working together, mostly as
volunteers, as we have. I feel like we are finally rounding the corner
on these projects.

Suggestions for other things to focus on next year, welcomed! Happy
thanksgiving... and if you have not seen "Alices Restaurant,
Illustrated", check it out on youtube. It's a gas.

[1] Bufferbloat.net is not a 501c(3), just an outgrowth of
TekLibre.net's other activities.

-- 
Dave Täht CSO, LibreQos
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

[Cake] a cilium bandwidth manager test series

[Dave Taht via Cake]

https://github.com/cilium/cilium/issues/29083

-- 
:( My old R campus is up for sale: https://tinyurl.com/yurtlab
Dave Täht CSO, LibreQos
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

[Cake] end of an era

[Dave Taht via Cake]

https://www.linkedin.com/posts/dtaht_nudist-resort-in-los-gatos-mountains-on-market-activity-7129105142087389184-UF2S

-- 
Oct 30: https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html
Dave Täht CSO, LibreQos
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

[Cake] our stuff on a mt7628AN

[Dave Taht via Cake]

This fella (in mexico) just reflashed 200+ old cnpilot routers to the
latest openwrt release. Nice results! +Nagging cambium to do the same,
extra sweet.

https://community.cambiumnetworks.com/t/bufferbloat-on-cnpilot-19xy-platform-support-of-fq-codel-and-cake/95757


-- 
Oct 30: https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html
Dave Täht CSO, LibreQos
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

[Cake] Fwd: [NetDev-People] Cambium cnPilot 190W: New life for old hardware, improving reliability & performance with OpenWrt, fq_codel & cake

[Dave Taht via Cake]

From ewaste to something great.

-- Forwarded message -
From: Ignacio Ocampo via people 
Date: Sun, Oct 15, 2023 at 1:47 PM
Subject: [NetDev-People] Cambium cnPilot 190W: New life for old
hardware, improving reliability & performance with OpenWrt, fq_codel &
cake
To: 
Cc: Ignacio Ocampo 


Hi there, I'm new on this distribution list. But wanted to share this
article I post about improving the reliability and performance of old
hardware with new software. It has to do with Linux Kernel, FQ_Codel
and Cake, and building an OpenWrt image.

https://blog.nafiux.com/posts/cnpilot_r190w_openwrt_bufferbloat_fqcodel_cake/

-- 
Ignacio Ocampo

___
people mailing list -- peo...@netdevconf.info
To unsubscribe send an email to people-le...@netdevconf.info


-- 
Oct 30: https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html
Dave Täht CSO, LibreQos
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] some comprehensive arm64 w/cake results

[Dave Taht via Cake]

really lovely, thank you. I hope we can get flent fixed. That risc
result was awful. Does it have BQL? Are there specs on the ethernet
interface?

This risc-v beaglebone just came out today:
https://www.beagleboard.org/boards/beaglev-ahead

On Sun, Oct 15, 2023 at 8:11 AM dave seddon  wrote:
>
> G'day,
>
> I've put more work into a test framework around the qdisc tests, but 
> unfortunately flent doesn't work easily with Ubuntu LTS ( 
> https://github.com/tohojo/flent/issues/232, which I think is an issue with 
> flent parsing the fping output ).
>
> Results and graphs in this sheet:
> https://docs.google.com/spreadsheets/d/1T59QwEdNwJFm4TgDFA_NY98gicOm8ABXKvDsSIMz9ag/edit#gid=1203641125
>
> Raw results of x2 test runs are here:
> https://github.com/randomizedcoder/qdisc_results/blob/main/qdisc/report.csv
>
> Each run:
> https://github.com/randomizedcoder/qdisc_results/blob/main/qdisc/2023-10-13T18%3A45%3A45/report.csv
> https://github.com/randomizedcoder/qdisc_results/blob/main/qdisc/2023-10-14T14%3A22%3A53/report.csv
>
> Full iperf outputs are available too, for example: 
> https://github.com/randomizedcoder/qdisc_results/blob/main/qdisc/2023-10-13T18%3A45%3A45/nanopi-r2s/fq_codel/iperf/test/16_iperf/stdout
>
> Logs for each run are also available, for example: 
> https://github.com/randomizedcoder/qdisc_results/blob/main/qdisc/2023-10-13T18%3A45%3A45/log.json
>
> The code repo updated here: https://github.com/randomizedcoder/cake , with 
> thehttps://github.com/randomizedcoder/cake/blob/main/README.md which explains 
> how the test work.
> Updated google doc is started here: 
> https://docs.google.com/document/d/1fYKj3BS89aB9drg_DsSq289xSdVQhn1zUJYCj0WuCs0/edit?usp=sharing
>
> Based on the questions on this list earlier, there is a folder with device 
> information for each of the devices
> https://github.com/randomizedcoder/cake/tree/main/device_info
>
> For example, the Pi4 and the Lichee Pi (risc-v) hardware layout is here:
> - 
> https://github.com/randomizedcoder/cake/blob/main/device_info/pi4/hwloc-ls-pi4.png
> - 
> https://github.com/randomizedcoder/cake/blob/main/device_info/lpi4a/hwloc-ls-lpi4a.png
>
> The switch has also been upgraded to a Cisco 3750x, which I think based on 
> the "show interface" output has a max queue size of 40 frames.  The test 
> process clears the counters before each test and gathers the "show interface" 
> output at the end.
>
> The Lichee Pi 4A doesn't look good ( 
> https://wiki.sipeed.com/hardware/en/lichee/th1520/lp4a.html )
>
>
> I really wish the flent was working, so I'll probably see if I can work out 
> the parsing.
>
> Thanks,
> Dave Seddon
>
> On Fri, Oct 13, 2023 at 10:25 AM dave seddon  wrote:
>>
>> My bad.  There's a bug for this Looks like I have to downgrade fping
>>
>> https://github.com/tohojo/flent/issues/232
>> https://github.com/schweikert/fping/issues/203
>>
>> On Fri, Oct 13, 2023 at 8:59 AM dave seddon  wrote:
>>>
>>> G'day,
>>>
>>> I've been working away on automation of the tests.  Pretty close to having 
>>> much nicer tests with a lot more details.  I've also got the risc-v device 
>>> working.
>>>
>>> However, I've run into something funny with flent.  Flent is not happy with 
>>> fping or ping.
>>>
>>> das@3rd:~/Downloads/cake/cmd/run_qdiscs_tests$ /usr/bin/sudo /usr/sbin/ip 
>>> netns exec network101 /usr/bin/flent rrul --output  
>>> /tmp/qdisc/2023-10-13T15:53:21/pi4/noqueue/flent/test/15_flent/flent_pi4_noqueue.png
>>>  --data-dir /tmp/qdisc/2023-10-13T15:53:21/pi4/noqueue/flent/test/15_flent/ 
>>> --format summary --plot all_scaled --title-extra 
>>> 2023-10-13T15:53:21_pi4_noqueue --note 2023-10-13T15:53:21_pi4_noqueue 
>>> --extended-metadata --host 172.17.51.10 --length 60 --ipv4 --socket-stats
>>> Starting Flent 2.0.1 using Python 3.10.12.
>>> Starting rrul test. Expected run time: 70 seconds.
>>> WARNING: Found fping, but couldn't parse its output. Not using. 
>>>  < ???
>>> ERROR: Runner Ping (ms) ICMP failed check: Cannot parse output of the 
>>> system ping binary (/usr/bin/ping). Please install fping v3.5+.<- ??
>>>
>>> das@3rd:~/Downloads/cake/cmd/run_qdiscs_tests$ dpkg --list | grep ping
>>> ii  fping 5.1-1 
>>>   amd64sends ICMP ECHO_REQUEST packets to network hosts
>>> ii  iputils-ping  3:20211215-1  
>>>   amd64Tools to test the reachability of network hosts
>>> ii  kpartx0.8.8-1ubuntu1.22.04.1
>>>   amd64create device mappings for partitions
>>> ii  libharfbuzz0b:amd64   2.7.4-1ubuntu3.1  
>>>   amd64OpenType text shaping engine (shared library)
>>> das@3rd:~/Downloads/cake/cmd/run_qdiscs_tests$ fping --version
>>> fping: Version 5.1
>>> das@3rd:~/Downloads/cake/cmd/run_qdiscs_tests$ ping -V
>>> ping from iputils 20211215
>>>
>>> 

[Cake] vyos w/fq_codel and cake

[Dave Taht via Cake]

After successfully having got them to switch the default over to
fq_codel last week,
I started looking over their very old skool traffic shaping policies.
Does anyone here use vyos? I used to really like it, but kind of went
pure openwrt, and now very little at all.

https://forum.vyos.io/t/qos-qoe-support-in-vyos/12376/2

https://docs.vyos.io/en/latest/configuration/trafficpolicy/index.html


-- 
Oct 30: https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html
Dave Täht CSO, LibreQos
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

[Cake] some comprehensive arm64 w/cake results

[Dave Taht via Cake]

A huge thanks to dave seddon for buckling down and doing some comprehensive
testing of a variety of arm64 gear!

https://docs.google.com/document/d/1HxIU_TEBI6xG9jRHlr8rzyyxFEN43zMcJXUFlRuhiUI/edit#heading=h.bpvv3vr500nw

-- 
Oct 30: https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html
Dave Täht CSO, LibreQos
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

[Cake] Fwd: [Rpm] Fwd: Firewalla App 1.56 Beta (part 1): Wi-Fi Test, CAKE and more

[Dave Taht via Cake]

anyone here have a firewalla?

-- Forwarded message -
From: Frantisek Borsik via Rpm 
Date: Wed, Sep 6, 2023 at 9:12 AM
Subject: [Rpm] Fwd: Firewalla App 1.56 Beta (part 1): Wi-Fi Test, CAKE and
more
To: Jeremy Austin via Rpm 


CAKE is in 拾 good job, Dave!


All the best,

Frank
Frantisek (Frank) Borsik

https://www.linkedin.com/in/frantisekborsik
Signal, Telegram, WhatsApp: +421919416714
iMessage, mobile: +420775230885
Skype: casioa5302ca
frantisek.bor...@gmail.com


-- Forwarded message -
From: Firewalla 
Date: Wed, 6 Sep 2023 at 5:18 PM
Subject: Firewalla App 1.56 Beta (part 1): Wi-Fi Test, CAKE and more
To: 




*Quick News*



   - Gold SE
   

   beta wave 1 has shipped. Wave 2 coming soon.
   - The Firewalla Rack Mount
   

   Pre-Sale is on now! Tooling going through testing.


*Firewalla App 1.56 BETA Release, Part 1*


*Firewalla App version 1.56 *
*is
now available to beta users on iOS and Android!* Here are some of the new
features in this update:



   - Wi-Fi Performance Test Tool
   - Smart Queue - CAKE (Public Beta)
   - Local Port in Smart Queue Rules
   - Server Certificate in AnyConnect
   - and more ...

Note that some new features require box version 1.977 or above, currently
available on Firewalla Gold SE production version, Gold Beta version,
Purple, Purple SE, and Blue Plus Early Access versions.


*Wi-Fi Test Tool (Requires Box 1.977) *


Our new *Wi-Fi Test* tool makes it easy to find the best and worst Wi-Fi
spots around your house. When your phone is connected to Firewalla’s local
network, you can use this feature to test the connection from your phone to
your box. You can switch between download, upload, and ping latency tests.
For step-by-step instructions, check out our video tutorial

.


If you’re connected to the *VPN Server*
,
the feature will be displayed as *VPN Test* instead of Wi-Fi Test. VPN Test
will show you the speed from your phone to your Firewalla box via VPN.


*Smart Queue - CAKE (Public Beta)*


CAKE (Common Applications Kept Enhanced) is a shaping-capable queue
discipline which uses both AQM and FQ.


Smart Queue - CAKE is now available for all Gold, Purple, and Purple SE
boxes. To switch to CAKE, tap *Smart Queue* on the box's main screen,
tap *Queue
Type* -> *CAKE*, and save. For step-by-step instructions, check out our video
tutorial

.

   - CAKE is best used with low-speed Internet.
   - CAKE is in Public Beta. If you have any feedback, please post it here
   

   .



*Local Port in Smart Queue Rules*


We now support specifying a *Local Port* as the target in *Smart Queue
Rules*. Check out our video tutorial

for step-by-step instructions.

[Cake] Some more cakemq thoughts

[Dave Taht via Cake]

From: 
https://docs.google.com/document/d/1tTYBPeaRdCO9AGTGQCpoiuLORQzN_bG3TAkEolJPh28/edit#heading=h.s3q8pyu1s825

...

The kernel has over 2500 places where it can drop packets, many of
which have been instrumented with the  “Drop_reason” facility. No
qdisc has drop_reason encoded into it yet. (Suggested names:
DROP_REASON_{CONGEST, OVERFLOW, FLOOD, SPIKE}).

QOS-MAP mirroring the same syntax as the wifi interface, this
establishes a direct correspondence between cake “tins” and the
settings for the linux wifi qos-map facility.

VLAN-MAP This maps from vlans to tins

NOWASHNQB - cake defaults to nowash allowing the passage of all dscps,
the addition of the NOWASHNQB state means it will wash out everything
except NQB.


-- 
Oct 30: https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html
Dave Täht CSO, LibreQos
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

[Cake] cakemq V further thoughts

[Dave Taht via Cake]

I continue to revise and edit this piece.

https://docs.google.com/document/d/1tTYBPeaRdCO9AGTGQCpoiuLORQzN_bG3TAkEolJPh28/edit

Today I came up with two other possible objectives to tackle, so
instead of re-re-re-re-rereading the above, they are:

BANG mode - there are certain cases where it it known that the
bandwidth is going to drop significantly (examples include a cnwave to
5ghz backup transition and Starlinks’15s update cycle) where it makes
sense to drop a bunch of packets immediately rather than wait for the
shift to gradually be seen.

tc qdisc change dev eth0 root cake bandwidth  bang

Cake-autorate rework - the first attempt at doing this directly in
cake frankly… does not work well. There has been a lot of innovation
in the sqm-autorate and cake-autorate projects, which live in
userspace today that might be applied more directly. BANG mode, above,
is an untried inspiration to cake autorate, and would also cope with
L4S flows by doing drops on big rate changes, rather than marks.


-- 
Oct 30: https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html
Dave Täht CSO, LibreQos
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] cakemq

[Dave Taht via Cake]

On Sat, Jul 29, 2023 at 3:20 PM David P. Reed  wrote:
>
> Here's me wearing my business executive/business consulting hat:

You look good in a hat!

>
>
> If you want a market that fits Cake very well, SME corporate routers and 
> building-scale routers are perfect. Whereever there's a bottleneck behind 
> which you have many PCs and consumer devices, etc. Cake can do the job. 
> (That's better than the bulk of the low end home routers, which still are 
> installed in apartments with one family as the only traffic source, so just 
> buying a faster link typically manages the bottleneck OK today).

I agree that there are markets in the small biz space. However a lot
of fq_codel and cake has already entered that market (fq_codel on
pfsense,  cake on things like riverbed, evenroute pro, mikrotik), and
I have no idea how well it is doing. In any case, building a routing
or firewalling product from cake out is quite an undertaking, and my
goal with writing up some needed features was to find a way to just
support further development.

>
>
> Let's say you are a startup in the Bay Area - you get a Comcast Business 
> service connection, and then start hiring people with laptops. And maybe you 
> have some "lights out" server capacity at some colo you pay for, but you 
> don't buy the highest speed service for your server traffic to get to your 
> developers' machines (either in the office or remote).
>
> Seems to me that Cake is the answer, and that answer will run in mini-PCs 
> (heftier CPUs than today's home routers) that have 2 NICs, each that are GigE 
> or 2.5 GigE or 40 GigE, depending on your bottleneck bandwidth of the service 
> you can buy from Comcast Business or your colo facility.

I strongly agree that lil business routers that do more of the right
things would be good, also "managed wifi".

>
>
> Cake will "just solve" the problem of congestion at that bottleneck, by 
> pushing back traffic rates fairly to the endpoints on a flow by flow basis.
>
>
>
> Now lots of small businesses run something like pFSense at that bottleneck 
> point on that hardware.
>
> Others seem to even run something more complex like Proxmox (because it costs 
> next to nothing) with one of the VMs being the "router".
>
>
>
> I'm sure there are lots of small IT support shops that install and maintain 
> these appliances out there. I don't know any personally, but it's crazy for a 
> small business to have a full time employee maintain that interconnect.

I know of a few managed services companies, but they are small.

>
>
> So, given that Cake would make them more money,

I am not entirely certain that reducing service calls makes that kind
of shop "more money".

>they must be convincable to share some of that with Cake developers. Because 
>they have deep pockets, Comcast Business (which is a VERY different business 
>from Comcast residential Internet) would be the first place I'd look. 
>Presumably they dela with Value Added Resellers who specialize in provisioning 
>small and medium businesses.

I think that some large ISPs' business units would be interested, but
that they would to existing vendors more than someone new and shiny.

>
>
> (I once had a nice conversation with Jason Livingood about how Comcast 
> Business is independent and should be thought of as having very different 
> tech needs. He might be able to tell you who at Comcast Business might be a 
> good contact. The same with all the other business Internet access providers 
> out there.)

Thank you for your thoughts.

>
>
>
> On Saturday, July 29, 2023 4:49pm, "Dave Taht via Cake" 
>  said:
>
> > thank you sebastian and dave for your comments and feedback so far. I
> > would like to find other markets for cake, more statistics worth
> > collecting, and other ideas, in the hope that we could find something
> > fundable out of the mix.
> >
> > On Fri, Jul 28, 2023 at 9:07 AM Dave Taht  wrote:
> > >
> > > I don't know if it is possible to multithread cake or not. But I
> > > started writing the ideas up here:
> > >
> > >
> > https://docs.google.com/document/d/1tTYBPeaRdCO9AGTGQCpoiuLORQzN_bG3TAkEolJPh28/edit?usp=sharing
> > >
> > > Pretty fragmentary, other use cases, other features, other
> > > mis-features, and thoughts requested.
> > >
> > > --
> > > Podcast: https://www.youtube.com/watch?v=bxmoBr4cBKg
> > > Dave Täht CSO, LibreQos
> >
> >
> >
> > --
> > Podcast: https://www.youtube.com/watch?v=bxmoBr4cBKg
> > Dave Täht CSO, LibreQos
> > ___
> > Cake mailing list
> > Cake@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/cake
> >



-- 
Podcast: https://www.youtube.com/watch?v=bxmoBr4cBKg
Dave Täht CSO, LibreQos
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] cakemq

[Dave Taht via Cake]

thank you sebastian and dave for your comments and feedback so far. I
would like to find other markets for cake, more statistics worth
collecting, and other ideas, in the hope that we could find something
fundable out of the mix.

On Fri, Jul 28, 2023 at 9:07 AM Dave Taht  wrote:
>
> I don't know if it is possible to multithread cake or not. But I
> started writing the ideas up here:
>
> https://docs.google.com/document/d/1tTYBPeaRdCO9AGTGQCpoiuLORQzN_bG3TAkEolJPh28/edit?usp=sharing
>
> Pretty fragmentary, other use cases, other features, other
> mis-features, and thoughts requested.
>
> --
> Podcast: https://www.youtube.com/watch?v=bxmoBr4cBKg
> Dave Täht CSO, LibreQos



-- 
Podcast: https://www.youtube.com/watch?v=bxmoBr4cBKg
Dave Täht CSO, LibreQos
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

[Cake] Fwd: been a while since I did a kernel patch

[Dave Taht via Cake]

I have been meaning to make this patch use UINT_MAX and submit to the
kernel for a long time. Anyone want to give it a spin?

-- Forwarded message -
From: Dave Taht 
Date: Sat, Feb 11, 2023 at 5:59 PM
Subject: been a while since I did a kernel patch
To: Toke Høiland-Jørgensen 


workflow still goes into net-next? You need a signed-off-by, and a tested-by?

(stupid patch attached)

--
This song goes out to all the folk that thought Stadia would work:
https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz
Dave Täht CEO, TekLibre, LLC


-- 
Podcast: https://www.youtube.com/watch?v=bxmoBr4cBKg
Dave Täht CSO, LibreQos
From cad12c8cd0e6031d33ea64209c4308ae10a7dd71 Mon Sep 17 00:00:00 2001
From: Dave Taht 
Date: Sun, 12 Feb 2023 01:53:40 +
Subject: [PATCH] sch_cake: use const invsqrt lookup table

It was silly to actually calculate these at run time, particularly
in an age where 10s of thousands of cake instances exist.

This lookup table is also mildly more accurate.
---
 net/sched/sch_cake.c | 50 ++--
 1 file changed, 16 insertions(+), 34 deletions(-)

diff --git a/net/sched/sch_cake.c b/net/sched/sch_cake.c
index 3ed0c3342189..ead5ea0605a3 100644
--- a/net/sched/sch_cake.c
+++ b/net/sched/sch_cake.c
@@ -360,8 +360,23 @@ static const u8 besteffort[] = {
 static const u8 normal_order[] = {0, 1, 2, 3, 4, 5, 6, 7};
 static const u8 bulk_order[] = {1, 0, 2, 3};
 
+/* There is a big difference in timing between the accurate values placed in
+ * the cache and the approximations given by a single Newton step for small
+ * count values, particularly when stepping from count 1 to 2 or vice versa.
+ * Above 16, a single Newton step gives sufficient accuracy in either
+ * direction, given the precision stored.
+ *
+ * The magnitude of the error when stepping up to count 2 is such as to give
+ * the value that *should* have been produced at count 4.
+ */
+
 #define REC_INV_SQRT_CACHE (16)
-static u32 cobalt_rec_inv_sqrt_cache[REC_INV_SQRT_CACHE] = {0};
+static const u32 inv_sqrt_cache[REC_INV_SQRT_CACHE] = { 
+	~0, 		~0,	3037000500, 2479700525,
+	2147483647, 1920767767, 1753413056, 1623345051,
+	1518500250, 1431655765, 1358187913, 1294981364,
+	1239850263, 1191209601, 1147878294, 1108955788
+};
 
 /* http://en.wikipedia.org/wiki/Methods_of_computing_square_roots
  * new_invsqrt = (invsqrt / 2) * (3 - count * invsqrt^2)
@@ -392,42 +407,9 @@ static void cobalt_invsqrt(struct cobalt_vars *vars)
 		cobalt_newton_step(vars);
 }
 
-/* There is a big difference in timing between the accurate values placed in
- * the cache and the approximations given by a single Newton step for small
- * count values, particularly when stepping from count 1 to 2 or vice versa.
- * Above 16, a single Newton step gives sufficient accuracy in either
- * direction, given the precision stored.
- *
- * The magnitude of the error when stepping up to count 2 is such as to give
- * the value that *should* have been produced at count 4.
- */
-
-static void cobalt_cache_init(void)
-{
-	struct cobalt_vars v;
-
-	memset(, 0, sizeof(v));
-	v.rec_inv_sqrt = ~0U;
-	cobalt_rec_inv_sqrt_cache[0] = v.rec_inv_sqrt;
-
-	for (v.count = 1; v.count < REC_INV_SQRT_CACHE; v.count++) {
-		cobalt_newton_step();
-		cobalt_newton_step();
-		cobalt_newton_step();
-		cobalt_newton_step();
-
-		cobalt_rec_inv_sqrt_cache[v.count] = v.rec_inv_sqrt;
-	}
-}
-
 static void cobalt_vars_init(struct cobalt_vars *vars)
 {
 	memset(vars, 0, sizeof(*vars));
-
-	if (!cobalt_rec_inv_sqrt_cache[0]) {
-		cobalt_cache_init();
-		cobalt_rec_inv_sqrt_cache[0] = ~0;
-	}
 }
 
 /* CoDel control_law is t + interval/sqrt(count)
-- 
2.34.1

___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

[Cake] cakemq

[Dave Taht via Cake]

I don't know if it is possible to multithread cake or not. But I
started writing the ideas up here:

https://docs.google.com/document/d/1tTYBPeaRdCO9AGTGQCpoiuLORQzN_bG3TAkEolJPh28/edit?usp=sharing

Pretty fragmentary, other use cases, other features, other
mis-features, and thoughts requested.

-- 
Podcast: https://www.youtube.com/watch?v=bxmoBr4cBKg
Dave Täht CSO, LibreQos
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

[Cake] mqcake

[Dave Taht via Cake]

I haven't thought about it much for many years, but in order to engage
the shaper,
a memory area could be passed down to subcake qdiscs, as a hidden
qdisc parameter, which would also keep a few other parameters in that
area. A NULL would mean it is a top level qdisc.

Did the lockless fifo project ever succeed?

--
Podcast: 
https://www.linkedin.com/feed/update/urn:li:activity:7058793910227111937/
Dave Täht CSO, LibreQos
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

[Cake] qosify ad - I think

[Dave Taht via Cake]

dynamic qos:

https://www.youtube.com/watch?v=VuFWh1X1-y0

-- 
Podcast: 
https://www.linkedin.com/feed/update/urn:li:activity:7058793910227111937/
Dave Täht CSO, LibreQos
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

[Cake] eevdf cpu scheduler

[Dave Taht via Cake]

is about to land in 6.6. It's interesting.

https://citeseerx.ist.psu.edu/document?repid=rep1=pdf=805acf7726282721504c8f00575d91ebfd750564

-- 
Podcast: 
https://www.linkedin.com/feed/update/urn:li:activity:7058793910227111937/
Dave Täht CSO, LibreQos
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

[Cake] Fwd: [PATCH v2 0/5] Rust abstractions for network device drivers

[Dave Taht via Cake]

I have often thought that the best way to implement a multi-core
capable cake was to bypass bql, qdisc, and ethernet driver entirely,
writing something like the carousel virtualized driver described here:
https://dl.acm.org/doi/abs/10.1145/3098822.3098852

-- Forwarded message -
From: FUJITA Tomonori 
Date: Mon, Jul 10, 2023 at 1:39 AM
Subject: [PATCH v2 0/5] Rust abstractions for network device drivers
To: , 
Cc: , , ,
, 


This patchset adds minimum Rust abstractions for network device
drivers and an example of a Rust network device driver, a simpler
version of drivers/net/dummy.c.

The major change is a way to drop an skb (1/5 patch); a driver needs
to explicitly call a function to drop a skb. The code to let a skb
go out of scope can't be compiled.

I dropped get_stats64 support patch that the current sample driver
doesn't use. Instead I added a patch to update the NETWORKING DRIVERS
entry in MAINTAINERS.

Changes since v1 [1]:
- a driver must explicitly call a function to drop a skb.
- simplify the code (thanks to Benno Lossin).
- update MAINTAINERS file.

[1] 
https://lwn.net/ml/netdev/20230613045326.3938283-1-fujita.tomon...@gmail.com/

FUJITA Tomonori (5):
  rust: core abstractions for network device drivers
  rust: add support for ethernet operations
  rust: add methods for configure net_device
  samples: rust: add dummy network driver
  MAINTAINERS: add Rust network abstractions files to the NETWORKING
DRIVERS entry

 MAINTAINERS |   2 +
 rust/bindings/bindings_helper.h |   3 +
 rust/helpers.c  |  23 ++
 rust/kernel/lib.rs  |   3 +
 rust/kernel/net.rs  |   5 +
 rust/kernel/net/dev.rs  | 598 
 samples/rust/Kconfig|  13 +
 samples/rust/Makefile   |   1 +
 samples/rust/rust_net_dummy.rs  |  75 
 scripts/Makefile.build  |   2 +-
 10 files changed, 724 insertions(+), 1 deletion(-)
 create mode 100644 rust/kernel/net.rs
 create mode 100644 rust/kernel/net/dev.rs
 create mode 100644 samples/rust/rust_net_dummy.rs


base-commit: d2e3115d717197cb2bc020dd1f06b06538474ac3
--
2.34.1




-- 
Podcast: 
https://www.linkedin.com/feed/update/urn:li:activity:7058793910227111937/
Dave Täht CSO, LibreQos
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

[Cake] tag line for cake-autorate wanted

[Dave Taht via Cake]

there has been some fun suggestions over here:
https://github.com/lynxthecat/cake-autorate/issues/162 - I had wanted
to basically get more folk on LTE, 5G, and Starlink aware of this
script and finding a way to have it hit on more queries (SEO) for
optimizing those sorts of connections would be nice.

"Casts bolts of lightning through the excess latency and jitter on
your variable rate connection!" is my favorite so far. But the whole
thread is highly entertaining, and if you need a diversion from todays
mundane tasks, well, saner (and insaner) suggestions deeply desired,
over there.

/me passes the doobie.


-- 
Podcast: 
https://www.linkedin.com/feed/update/urn:li:activity:7058793910227111937/
Dave Täht CSO, LibreQos
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] [Bloat] Two questions re high speed congestion management anddatagram protocols

[Dave Taht via Cake]

https://datatracker.ietf.org/doc/charter-ietf-ccwg/

is a new wg intended to poke into these issues

On Tue, Jun 27, 2023 at 4:49 PM Stephen Hemminger via Cake
 wrote:
>
> On Tue, 27 Jun 2023 12:47:01 -0700 (PDT)
> David Lang  wrote:
>
> > On Mon, 26 Jun 2023, David P. Reed via Bloat wrote:
> >
> > > Sorry for top posting, but ... Bigger question:
> > > Why would DCCP be deprecated by Linux kernel?
> > > Who makes that decision? Who argues against it?
> >
> > Linus or the networking maintaners make the decision.
> >
> > Usually things get pulled from the kernel because there are updates that 
> > need to
> > be made to the code (to match changes elsewhere in the kernel or because of
> > security issues) and there isn't a maintainer who works on the code in a
> > resonable time. This means that the maintainers for the general code area 
> > (in
> > this case networking maintainers) will need to do extra work in an area they
> > aren't that interested in (and, especially in the case of hardware, may not 
> > have
> > the ability to test). They do some of it, especially if it's commonly used, 
> > but
> > eventually either another maintainer steps up, or it goes away
> >
> > David Lang
>
> See 
> https://patchwork.kernel.org/project/netdevbpf/patch/20230614194705.90673-3-kun...@amazon.com/
> ___
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake



-- 
Podcast: 
https://www.linkedin.com/feed/update/urn:li:activity:7058793910227111937/
Dave Täht CSO, LibreQos
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

[Cake] cake in guyana

[Dave Taht via Cake]

https://www.facebook.com/groups/249134358750920?multi_permalinks=2161490917515245_section_header_type=recently_seen

-- 
Podcast: 
https://www.linkedin.com/feed/update/urn:li:activity:7058793910227111937/
Dave Täht CSO, LibreQos
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

[Cake] industrial lte/wifi router with cake

[Dave Taht via Cake]

The hardware from this company looks sturdy, but that is all I know about it.

https://wiki.teltonika-networks.com/view/RUTX11

https://wiki.teltonika-networks.com/view/RUTX11_Traffic_Shaping

-- 
Podcast: 
https://www.linkedin.com/feed/update/urn:li:activity:7058793910227111937/
Dave Täht CSO, LibreQos
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

[Cake] equinix job role in speedy open source packetisation stuff

[Dave Taht via Cake]

I have been very impressed with equinix's infrastructure in the brief
time they have been supporting the libreqos project via their open
source program. (thank you equinix!) so if you know of anyone that
would like in on the inside...

https://equinix.wd1.myworkdayjobs.com/External/job/Remote-Location---United-States-of-America/Principal-Engineer--Product-Software_JR-133989

"You have a strong feeling for the direction of a cloud-native
virtualized compute and networking product, have a deep sense for the
common challenges and pain points experienced by users of services in
that category, and would love to build an amazing product that
addresses that pain and delights its customers.

You believe every packet matters, and as such you are passionate about
OS-based networking technologies, from advanced packet processors like
VPP to eBPF to QAT offloads.  You know that efficiency matters and
that open-source software optimized against the right hardware can
push 50Gbps per core.

You have built significant cloud automation and worked with
distributed systems at large scale.  Running network workload via
software in hundreds of locations makes you excited, not scared.

You are passionate about open-source and have created, or been heavily
involved in, a software community "





-- 
Come Heckle Mar 6-9 at: https://www.understandinglatency.com/
Dave Täht CEO, TekLibre, LLC
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

[Cake] draft-ietf-tsvwg-nqb-15.txt vs the cake AQM

[Dave Taht via Cake]

I have been sitting on the cake related patches for this for years
now, and it is my hope to get support for NQB into the next linux
release, regardless of whether it gets through last call at this time,
unless the selected codepoint number changes. (?)

Cake (please see the man page here:
https://man7.org/linux/man-pages/man8/tc-cake.8.html ) supports
multiple diffserv models.

besteffort is exactly that, besteffort, and will not gain NQB support.

The diffserv3 interpretation is the default, and given that flow
queuing handles most of the NQB-like problems naturally, and  Voice
(CS7, CS6, EF, VA, TOS4) is all that is handled there today, I am
thinking of *not* elevating NQB into that class is the right thing.

NQB fits nicely into the diffserv4 model in the video class, so I will
put it there. since covid we tend to use the diffserv4 model a lot to
manage videoconferencing better.

As for the CS0-CS7 precedence model inc cake, we have declared that
obsolete in the code, and wherever NQB falls into it, great. And the
diffserv8, I don´t know.

Anyway, does that work for everyone?

Part II of this would be a discussion of the various wash modes, but
merely getting the right byte into the right lookup tables after all
this discussion, would be nice.
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

[Cake] big tcp

[Dave Taht via Cake]

does this break cake?

https://lore.kernel.org/netdev/de811bf3-e2d8-f727-72bc-c8a754a9d...@tessares.net/T/

-- 
A pithy note on VOQs vs SQM: https://blog.cerowrt.org/post/juniper/
Dave Täht CEO, TekLibre, LLC
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

[Cake] Fwd: [tsvwg] CONGRESS is about ready to go

[Dave Taht via Cake]

-- Forwarded message -
From: Martin Duke 
Date: Tue, Feb 21, 2023 at 9:25 AM
Subject: [tsvwg] CONGRESS is about ready to go
To: 


Hello transport enthusiasts,

I'm pleased to announce that all the pieces are in place to move
forward with congress, the working group focused on congestion control
and related topics.

(1) If you haven't already done so, and are interested, please
subscribe to the congress mailing list:
https://www.ietf.org/mailman/listinfo/congress. This is the last time
I'll crosspost (Bcc:) to multiple WG lists, and I encourage others to
stop as well.

(2)  Although the proposed charter has no formal standing at this
time, I'm initiating a "last call". Please have a look and file issues
by the end of this week:
https://github.com/martinduke/congestion-control-charter
The only recent additions to the scope are Fair Queueing and rate
pacing. I'd like to hand this to Zahed, our sponsoring AD, to run
through the IESG process next week.


-- 
A pithy note on VOQs vs SQM: https://blog.cerowrt.org/post/juniper/
Dave Täht CEO, TekLibre, LLC
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

[Cake] Fwd: Domos Latency Webinar Series featuring: Apple, Comcast, Vodafone, Nokia, CloudFlare, Ericsson, Ookla, GameBench, Red Hat, Daily, Bufferbloat

[Dave Taht via Cake]

I absolutely could not write a better promotional piece for our upcoming
latency conference march 6-8.

That long, endless throbbing, bass note is the soundtrack of my life! I
could call out a lot of folk doing this, notably Matt Mathis has a keynote,
and Toke is talking about ebpf, and Stuart about "RPM", and the rest of our
"gang", like Jason Livingood & Brennan Smith - but it's the newer folk,
like Varun Singh from Callstats - and Angus Laurie-Pile (of Gamebench)  and
Dave Tuber (from Cloudflare) that I am looking forward to hearing from
most.

I hope that the overall set of speakers and the topic has broad enough
appeal to reach a wider audience than usual. Please sign up at:
understandinglatency.com - or better, pass along to someone that might be
interested?

I will probably burn a slide on starlink, and another on LTE. Is there
anything new y'all would like me to speak to in my talk about "measuring
internet quality"?

-- Forwarded message -
From: Magnus Olden 
Date: Tue, Feb 21, 2023 at 5:09 AM
Subject: Domos Latency Webinar Series featuring: Apple, Comcast, Vodafone,
Nokia, CloudFlare, Ericsson, Ookla, GameBench, Red Hat, Daily, Bufferbloat
To: 


Hi there,
How do you get...

   - A internet legend and ex-Googler
   - A guy with "Wizard" in his job title at Apple
   - A former XR-Specialist at Microsoft
   - Key technologists from Vodafone, Comcast, Ericsson, Cloudflare, Ookla,
   Red Hat, GameBench, Daily, and Aterlo
   - A Bell Labs fellow
   - The ultimate Bufferbloat fighter
   - A WebRTC spec writer
   - And authors of numerous IETF RFCs, ITU and BBF TRs

...to team up for a webinar?

You make it about network latency.

Don't miss out on our knowledge sharing event. Check out our Video Teaser
(sound ON for dramatic effect)

.

Get all the details and register at understandinglatency.com

.

Cheers,
Magnus Olden
CTO, Domos - Latency Management






This email was sent to dave.t...@gmail.com
*why did I get this?*

unsubscribe from this list

update subscription preferences

Domos Labs · Ole Moes Vei 12 · Oslo, 03 1165 · Norway



-- 
A pithy note on VOQs vs SQM: https://blog.cerowrt.org/post/juniper/
Dave Täht CEO, TekLibre, LLC
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

[Cake] flow dissection vs encapsulated traffic?

[Dave Taht via Cake]

In looking how the code has morphed since I last looked at it, I found
myself staring at this bit...

skb_flow_dissect_flow_keys(skb, ,
   FLOW_DISSECTOR_F_STOP_AT_FLOW_LABEL);

// so we have delved deeply into the packet at this point... finding
various encapsulations...

then we get to:

/* Don't use the SKB hash if we change the lookup keys from conntrack */
if (nat_enabled && cake_update_flowkeys(, skb))
use_skbhash = false;

This leverages skb_protocol(), which as best as I can tell just peers
into the *vlan headers*,
not deeper into the packet...

Then we proceed merrily into the update_flowkeys code thinking it is
the outer type
(ipv4), not the inner, then dissect away, using a v4 union...

Am I reading this wrong? Please tell me I am reading this wrong...




-- 
This song goes out to all the folk that thought Stadia would work:
https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz
Dave Täht CEO, TekLibre, LLC
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

[Cake] I think it is increasingly feasible to make cobalt better now against modern transports.

[Dave Taht via Cake]

https://arxiv.org/pdf/2109.11693.pdf


-- 
This song goes out to all the folk that thought Stadia would work:
https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz
Dave Täht CEO, TekLibre, LLC
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

[Cake] so nice to see cake just work for so many on cpe

[Dave Taht via Cake]

https://www.reddit.com/r/mikrotik/comments/10h86fz/experiences_with_cake/
-- 
This song goes out to all the folk that thought Stadia would work:
https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz
Dave Täht CEO, TekLibre, LLC
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] [Bloat] [Rpm] [Starlink] [LibreQoS] the grinch meets cloudflare'schristmas present

[Dave Taht via Cake]

On Thu, Jan 12, 2023 at 7:30 PM Luis A. Cornejo
 wrote:
>
> Well Reddit has many posts talking about noticeable performance increases for 
> Starlink. Here is a primetime run:
>
> waveform:
> https://www.waveform.com/tools/bufferbloat?test-id=333f97c7-7cbd-406c-8d9a-9f850cb5de7d

That is unquestionably the best result I have ever seen for starlink.
Are you in a position to take a packet capture
of the waveform test, or try some flent based tests?

> cloudflare attached
>
>
>
> On Thu, Jan 12, 2023 at 11:43 AM MORTON JR., AL  wrote:
>>
>> Dave and Luis,
>>
>> Do you know if any of these tools are using ~random payloads, to defeat 
>> compression?
>>
>> UDPST has a CLI option:
>> (m)-X   Randomize datagram payload (else zeroes)
>>
>> When I used this option testing shipboard satellite access, download was 
>> about 115kbps.
>>
>> Al
>>
>> > -Original Message-
>> > From: Dave Taht 
>> > Sent: Thursday, January 12, 2023 11:12 AM
>> > To: Luis A. Cornejo 
>> > Cc: Jay Moran ; Cake List ; IETF 
>> > IPPM
>> > WG ; MORTON JR., AL ; Rpm
>> > ; bloat ;
>> > dick...@alum.mit.edu; libreqos 
>> > Subject: Re: [Bloat] [Rpm] [Starlink] [LibreQoS] the grinch meets
>> > cloudflare'schristmas present
>> >
>> > Either starlink has vastly improved, or the test is way off in this case.



-- 
This song goes out to all the folk that thought Stadia would work:
https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz
Dave Täht CEO, TekLibre, LLC
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] [Bloat] [Rpm] [Starlink] [LibreQoS] the grinch meets cloudflare'schristmas present

[Dave Taht via Cake]

Either starlink has vastly improved, or the test is way off in this case.
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

[Cake] firewalla gains cake

[Dave Taht via Cake]

I wish they would publish stats from their line rate fq_codel or cake instance.

https://help.firewalla.com/hc/en-us/articles/10221985597331-Firewalla-Box-Release-1-975-App-Release-1-52#h_01GK00RM5YNBRYJ8K8BVE3WXX1

-- 
This song goes out to all the folk that thought Stadia would work:
https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz
Dave Täht CEO, TekLibre, LLC
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] [Rpm] [Bloat] [Starlink] [LibreQoS] the grinch meets cloudflare'schristmas present

[Dave Taht via Cake]

Dear Luis:

You hit 17 seconds of delay on your test.

I got you beat, today, on my LTE connection, I cracked 182 seconds.

I'd like to thank Verizon for making it possible for me to spew 4000
words on my kvetches about the current speedtest regimes of speedtest,
cloudflare, and so on, by making my network connection so lousy today
that I sat in front of emacs to rant - and y'all for helping tone
down, a little, this blog entry:

https://blog.cerowrt.org/post/speedtests/

On Tue, Jan 10, 2023 at 9:25 AM Luis A. Cornejo via Rpm
 wrote:
>
> Here is my VZ HSI
>
>
> No SQMm on
>
> On Sat, Jan 7, 2023 at 6:38 PM Dick Roy via Bloat 
>  wrote:
>>
>>
>>
>>
>>
>> -Original Message-
>> From: rjmcmahon [mailto:rjmcma...@rjmcmahon.com]
>> Sent: Friday, January 6, 2023 3:45 PM
>> To: dick...@alum.mit.edu
>> Cc: 'MORTON JR., AL'; 'IETF IPPM WG'; 'libreqos'; 'Cake List'; 'Rpm'; 'bloat'
>> Subject: Re: [Starlink] [Rpm] [LibreQoS] the grinch meets 
>> cloudflare'schristmas present
>>
>>
>>
>> yeah, I'd prefer not to output CLT sample groups at all but the
>>
>> histograms aren't really human readable and users constantly ask for
>>
>> them. I thought about providing a distance from the gaussian as output
>>
>> too but so far few would understand it and nobody I found would act upon
>>
>> it.
>>
>> [RR] Understandable until such metrics are “actionable”, and that’s “up to 
>> us to find/define/figure out” it seems to me. Metrics that are not 
>> actionable are write-only memory and good for little but historical recordJ
>>
>> The tool produces the full histograms so no information is really
>>
>> missing except for maybe better time series analysis.
>>
>> [RR] Isn’t that in fact what we are trying to extract from the e2e stats we 
>> collect?  i.e., infer the time evolution of the system from its I/O 
>> behavior? As you point out, it’s really hard to do without probes in the 
>> guts of the system, nd yes, synchronization is important J
>>
>>
>>
>> The open source flows python code also released with iperf 2 does use
>>
>> the komogorov-smirnov distances & distance matrices to cluster when the
>>
>> number of histograms are just too much. We've analyzed 1M runs to fault
>>
>> isolate the "unexpected interruptions" or "bugs" and without statistical
>>
>> support it is just not doable. This does require instrumentation of the
>>
>> full path with mapping to a common clock domain (e.g. GPS) and not just
>>
>> e2e stats. I find an e2e complaint by an end user about "poor speed" as
>>
>> useful as telling a pharmacist I have a fever. Not much diagnostically
>>
>> is going on. Take an aspirin.
>>
>> [RR] That’s AWESOME!! I love that analogy!
>>
>>
>>
>> RR
>>
>>
>>
>> https://en.wikipedia.org/wiki/Kolmogorov%E2%80%93Smirnov_test
>>
>> https://sourceforge.net/p/iperf2/code/ci/master/tree/flows/flows.py
>>
>>
>>
>> Bob
>>
>> > See below …
>>
>> >
>>
>> > -Original Message-
>>
>> > From: Starlink [mailto:starlink-boun...@lists.bufferbloat.net] On
>>
>> > Behalf Of rjmcmahon via Starlink
>>
>> > Sent: Friday, January 6, 2023 12:39 PM
>>
>> > To: MORTON JR., AL
>>
>> > Cc: Dave Taht via Starlink; IETF IPPM WG; libreqos; Cake List; Rpm;
>>
>> > bloat
>>
>> > Subject: Re: [Starlink] [Rpm] [LibreQoS] the grinch meets
>>
>> > cloudflare'schristmas present
>>
>> >
>>
>> > Some thoughts are not to use UDP for testing here. Also, these speed
>>
>> >
>>
>> > tests have little to no information for network engineers about what's
>>
>> >
>>
>> >
>>
>> > going on. Iperf 2 may better assist network engineers but then I'm
>>
>> >
>>
>> > biased ;)
>>
>> >
>>
>> > Running iperf 2 https://sourceforge.net/projects/iperf2/ with
>>
>> >
>>
>> > --trip-times. Though the sampling and central limit theorem averaging
>>
>> > is
>>
>> >
>>
>> > hiding the real distributions (use --histograms to get those)
>>
>> >
>>
>> > _[RR] FWIW (IMNBWM __J)… If the output/final histograms indicate the
>>
>> > PDF is NOT Gaussian, then any application of the CLT is
>>
>> > inappropriate/contra-indicated! The CLT is a "proof under certain
>>
>> > regularity conditions/assumptions of underlying/constituent PDFs, that
>>
>> > the resulting PDF (after all the necessary convolutions are performed
>>
>> > to get to the PDF of the output) will asymptotically approach a
>>
>> > Gaussian with only a mean and a std. dev. left to specify. _
>>
>> >
>>
>> > Below are 4 parallel TCP streams from my home to one of my servers in
>>
>> >
>>
>> > the cloud. First where TCP is limited per CCA. Second is source side
>>
>> >
>>
>> > write rate limiting. Things to note:
>>
>> >
>>
>> > o) connect times for both at 10-15 ms
>>
>> >
>>
>> > o) multiple TCP retries on a few rites - one case is 4 with 5 writes.
>>
>> >
>>
>> > Source side pacing eliminates retries
>>
>> >
>>
>> > o) Fairness with CCA isn't great but quite good with source side write
>>
>> >
>>
>> >
>>
>> > pacing
>>
>> >
>>
>> > o) Queue depth with CCA is about 150 Kbytes about 100K byte with
>>

[Cake] libreqos test of cake and ebpf pping in realtime

[Dave Taht via Cake]

fire off a bandwidth test over here (we do 5 different flent tests in a row)

https://payne.taht.net/

Then pick a "plan", here, 25/3... then show tins...

https://payne.taht.net/circuit_queue?id=2

So nice to see drops and marks in real time, as well as slow start...

-- 
This song goes out to all the folk that thought Stadia would work:
https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz
Dave Täht CEO, TekLibre, LLC
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

[Cake] some comments on cake's documentation

[Dave Taht via Cake]

over here: https://github.com/dtaht/sch_cake/issues/154#issuecomment-1363302993

-- 
This song goes out to all the folk that thought Stadia would work:
https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz
Dave Täht CEO, TekLibre, LLC
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] AVM seems to be shipping cake

[Dave Taht via Cake]

Yay! 260 more countries to go!

On Tue, Dec 20, 2022 at 7:46 AM Sebastian Moeller via Cake
 wrote:
>
> Dear all,
>
> just had a look in a recent firmware archive for AVM's fritzbox 7530, and 
> 'strings dsld' (dsld is AVM's single blob "magic binary dsl deamon" that 
> encapsulates a lot of their value proposition) reveals that they likely are 
> using cake*:
>
> qdisc add dev %s handle 10:0 root cake bandwidth %ukbit besteffort %s %s 
> dual-dsthost ingress
> qdisc add dev %s handle 10:0 root cake bandwidth %ukbit besteffort overhead 
> %d dual-dsthost ingress
>
>
> I failed to find the matching dual-srchost entry so they might use something 
> else for egress. I have no insight whether/how this can be actiated (not 
> using a fb7530 myself), but at least this is making it out to the unwashed 
> masses in Germany... (The FB7530 is the "value" box for the most recent DSL 
> variant deployed in Germany, profile 35b vectoring, sold under the moniker 
> "super-vectoring").
>
>
> *) makes sense some months ago they posted a video promising enhances 
> fairness for internal users, I was puzzled at the time how they would 
> implement that, but it seems that they did not re-invent the wheel here but 
> went for
>
> Regards
> Sebastian
>
> P.S.: To my joy they also seem to diligently set overhead, for their HTB/TBF 
> instances using tc-stab...
> ___
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake



-- 
This song goes out to all the folk that thought Stadia would work:
https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz
Dave Täht CEO, TekLibre, LLC
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

[Cake] firewalla finally playing with cake

[Dave Taht via Cake]

https://help.firewalla.com/hc/en-us/articles/10221985597331-Firewalla-Box-Release-1-975-App-Release-1-52
-- 
This song goes out to all the folk that thought Stadia would work:
https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz
Dave Täht CEO, TekLibre, LLC
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

[Cake] questions: LPM -> irq or queue mapping on the card for cake?

[Dave Taht via Cake]

all:

After a pretty long layoff from kernel development of any sort of
mine... we're pushing the limits again trying to get cake to support
10s of thousands of ISP subscribers, leveraging xdp for reads, and
ebpf "pping" for inline monitoring of TCP rtts, then a ton of htb bins
+ cake for each subscriber.

shameless plugs:

https://github.com/thebracket/cpumap-pping#cpumap-pping # everybody
needs kathie nichols and simon 's pping!!!
https://github.com/LibreQoE

(even more shameless plug - ask your isp to try libreqos.io out -
presently at 10k users, pushing 11gbit/sec, 24% of 16 cores! I'm
really, really amazed by all this, I remember struggling to get cake
to crack 50Mbits on a 600mhz mips box a decade back. Way to go
everyone! - love, rip van winkle)

Anyway... after adopting xdp fully over the past couple months... most
of the CPU time is now spent in htb, and while I see htb has been
successfully offloaded by the mlx5, it's not clear if that can pull
from from cake as an underlying qdisc (?), or only a pfifo, nor how
much buffering offloads like this introduce. ? Are there other cards
with an htb offload now?

Secondly -

The xdp path is marvelous, but in trying to drive this transparent
bridge to 100Gbit, I find myself wanting something old fashioned, and
in my mind, simpler than a match pattern - is there any ethernet card
that lets you do a TCAM mapping of a large (say, 128 thousand) set of
IP addresses to an irq or queue ?

1.2.3.4/29 -> irq 8 (or hw queue 8)
1.2.4.1/32 -> irq 9 (or hw queue 9)
a:b:c:d::/56 -> irq 8 (etc * 10s of thousands of other ip addresses, 1
or more LPM matches per subscriber)

Needn't be big enough to fill a bgp table...

This is different from RPS in that we don't want a rxhash to spread
the load "evenly", but to always direct a set of IP addresses to a
particular core, on a particular queue - which is setup to do all that
htb-ing (32k unique bins per core, e.g. 1.9m bins on 64 cores) and
cake-ing.

Other ideas for steppingstones on the march to 100gbit forwarding
through tons of cake gladly considered. We're going to be fiddling
with the metadata stuff in xdp as well - 3 hw hashes for cake, a rx
timestamp for codel will probably help there too.



-- 
This song goes out to all the folk that thought Stadia would work:
https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz
Dave Täht CEO, TekLibre, LLC
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

[Cake] Fwd: [PATCH net] net/sched: act_mirred: use the backlog for mirred ingress

[Dave Taht via Cake]

mirred must die.

-- Forwarded message -
From: Davide Caratti 
Date: Tue, Oct 4, 2022 at 10:52 AM
Subject: Re: [PATCH net] net/sched: act_mirred: use the backlog for
mirred ingress
To: Cong Wang 
Cc: Jamal Hadi Salim , Jiri Pirko
, Paolo Abeni , Marcelo Ricardo
Leitner , ,



hello Cong, thanks for looking at this!

On Sun, Sep 25, 2022 at 11:08:48AM -0700, Cong Wang wrote:
> On Fri, Sep 23, 2022 at 05:11:12PM +0200, Davide Caratti wrote:
> > William reports kernel soft-lockups on some OVS topologies when TC mirred
> > "egress-to-ingress" action is hit by local TCP traffic. Indeed, using the
> > mirred action in egress-to-ingress can easily produce a dmesg splat like:
> >
> >  
> >  WARNING: possible recursive locking detected

[...]

> >  6.0.0-rc4+ #511 Not tainted
> >  
> >  nc/1037 is trying to acquire lock:
> >  950687843cb0 (slock-AF_INET/1){+.-.}-{2:2}, at: 
> > tcp_v4_rcv+0x1023/0x1160
> >
> >  but task is already holding lock:
> >  950687846cb0 (slock-AF_INET/1){+.-.}-{2:2}, at: 
> > tcp_v4_rcv+0x1023/0x1160

FTR, this is:

2091 sk_incoming_cpu_update(sk);
2092
2093 bh_lock_sock_nested(sk); <--- the lock reported in the splat
2094 tcp_segs_in(tcp_sk(sk), skb);
2095 ret = 0;
2096 if (!sock_owned_by_user(sk)) {

> BTW, have you thought about solving the above lockdep warning in TCP
> layer?

yes, but that doesn't look like a trivial fix at all - and I doubt it's
worth doing it just to make mirred and TCP "friends". Please note:
on current kernel this doesn't just result in a lockdep warning: using
iperf3 on unpatched kernels it's possible to see a real deadlock, like:

WARRNING: possible circular locking dependency detected
 6.0.0-rc4+ #511 Not tainted
 --
 iperf3/1021 is trying to acquire lock:
 976005c5a630 (slock-AF_INET6/1){+...}-{2:2}, at: tcp_v4_rcv+0x1023/0x1160

 but task is already holding lock:
 97607b06e0b0 (slock-AF_INET/1){+.-.}-{2:2}, at: tcp_v4_rcv+0x1023/0x1160

 which lock already depends on the new lock.


 the existing dependency chain (in reverse order) is:

 -> #1 (slock-AF_INET/1){+.-.}-{2:2}:
lock_acquire+0xd5/0x310
_raw_spin_lock_nested+0x39/0x70
tcp_v4_rcv+0x1023/0x1160
ip_protocol_deliver_rcu+0x4d/0x280
ip_local_deliver_finish+0xac/0x160
ip_local_deliver+0x71/0x220
ip_rcv+0x5a/0x200
__netif_receive_skb_one_core+0x89/0xa0
netif_receive_skb+0x1c1/0x400
tcf_mirred_act+0x2a5/0x610 [act_mirred]
tcf_action_exec+0xb3/0x210
fl_classify+0x1f7/0x240 [cls_flower]
tcf_classify+0x7b/0x320
__dev_queue_xmit+0x3a4/0x11b0
ip_finish_output2+0x3b8/0xa10
ip_output+0x7f/0x260
__ip_queue_xmit+0x1ce/0x610
__tcp_transmit_skb+0xabc/0xc80
tcp_rcv_established+0x284/0x810
tcp_v4_do_rcv+0x1f3/0x370
tcp_v4_rcv+0x10bc/0x1160
ip_protocol_deliver_rcu+0x4d/0x280
ip_local_deliver_finish+0xac/0x160
ip_local_deliver+0x71/0x220
ip_rcv+0x5a/0x200
__netif_receive_skb_one_core+0x89/0xa0
netif_receive_skb+0x1c1/0x400
tcf_mirred_act+0x2a5/0x610 [act_mirred]
tcf_action_exec+0xb3/0x210
fl_classify+0x1f7/0x240 [cls_flower]
tcf_classify+0x7b/0x320
__dev_queue_xmit+0x3a4/0x11b0
ip_finish_output2+0x3b8/0xa10
ip_output+0x7f/0x260
__ip_queue_xmit+0x1ce/0x610
__tcp_transmit_skb+0xabc/0xc80
tcp_write_xmit+0x229/0x12c0
__tcp_push_pending_frames+0x32/0xf0
tcp_sendmsg_locked+0x297/0xe10
tcp_sendmsg+0x27/0x40
sock_sendmsg+0x58/0x70
sock_write_iter+0x9a/0x100
vfs_write+0x481/0x4f0
ksys_write+0xc2/0xe0
do_syscall_64+0x3a/0x90
entry_SYSCALL_64_after_hwframe+0x63/0xcd

 -> #0 (slock-AF_INET6/1){+...}-{2:2}:
check_prevs_add+0x185/0xf50
__lock_acquire+0x11eb/0x1620
lock_acquire+0xd5/0x310
_raw_spin_lock_nested+0x39/0x70
tcp_v4_rcv+0x1023/0x1160
ip_protocol_deliver_rcu+0x4d/0x280
ip_local_deliver_finish+0xac/0x160
ip_local_deliver+0x71/0x220
ip_rcv+0x5a/0x200
__netif_receive_skb_one_core+0x89/0xa0
netif_receive_skb+0x1c1/0x400
tcf_mirred_act+0x2a5/0x610 [act_mirred]
tcf_action_exec+0xb3/0x210
fl_classify+0x1f7/0x240 [cls_flower]
tcf_classify+0x7b/0x320
__dev_queue_xmit+0x3a4/0x11b0
ip_finish_output2+0x3b8/0xa10
ip_output+0x7f/0x260
__ip_queue_xmit+0x1ce/0x610
__tcp_transmit_skb+0xabc/0xc80
tcp_rcv_established+0x284/0x810
tcp_v4_do_rcv+0x1f3/0x370
tcp_v4_rcv+0x10bc/0x1160
ip_protocol_deliver_rcu+0x4d/0x280
ip_local_deliver_finish+0xac/0x160

[Cake] Fwd: Yuriy.Sentrium & vyos

[Dave Taht via Cake]

If anyone would like to discuss the state of cake/smart queues with vyos,
they use slack, which I'm kind of allergic to.



-- Forwarded message -
From: Slack 
Date: Mon, Nov 14, 2022 at 2:18 PM
Subject: Yuriy.Sentrium has invited you to work with them in Slack
To: 


Join your team on Slack. *Yuriy.Sentrium* (yu...@sentrium.io) has invited
you to join their workspace, *VyOS Platform*, as a guest.
 ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌  ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌
 ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌  ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌
 ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌  ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌
 ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌  ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌
 ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌  ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌
 ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌  ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌
 ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌  ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌
[image: slack logo]Join your team on Slack

*Yuriy.Sentrium* (yu...@sentrium.io) has invited you to join their
workspace, *VyOS Platform*, as a guest.
Workspace name: VyOS Platform
VyOS Platformvyos.slack.com
Join Now

What is Slack?

Slack is a messaging app for teams, a place you can collaborate on projects
and organize conversations — so you can work together, no matter where you
are. Learn more about Slack

[image: slack logo] 


Our Blog    |   Policies 
   |   Help Center    |   Slack Community


©2022 Slack Technologies, LLC, a Salesforce company.
500 Howard Street, San Francisco, CA 94105 USA

All rights reserved.


-- 
This song goes out to all the folk that thought Stadia would work:
https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz
Dave Täht CEO, TekLibre, LLC
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

[Cake] vyos cake

[Dave Taht via Cake]

anyone here use vyos? Looks like the cake port is back in progress over there.

https://phabricator.vyos.net/T725
--
This song goes out to all the folk that thought Stadia would work:
https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz
Dave Täht CEO, TekLibre, LLC
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

[Cake] Fwd: Our Aaron Swartz Day Celebration Starts Tomorrow!

[Dave Taht via Cake]

I didn't put us in for the hackathon, but showing up would be useful. ALL
the distributed technologies benefit from low bufferbloat, and low latency.

-- Forwarded message -
From: Internet Archive 
Date: Fri, Nov 11, 2022 at 9:08 AM
Subject: Our Aaron Swartz Day Celebration Starts Tomorrow!
To: Dave Taht 


Join us to celebrate the life of Aaron Swartz on Saturday and Sunday,
November 12th and 13th.


*View this email in your browser*


*Aaron Swartz Day and International Hackathon*

Our celebration of the life of Aaron Swartz

begins
TOMORROW! Aaron Swartz was a hacktivist, political organizer, and
passionate advocate for free and open access to knowledge. The annual Aaron
Swartz Day celebration commemorates his life and work, while also
showcasing projects that he inspired. This year's event will feature two
days of speakers, hackathons, and parties, hosted at the Internet Archive
headquarters.

If you'd like to participate in the hackathon, the list of projects is
available here
.
There will also be hackathons going on in Brazil, Ecuador, and Argentina,
for open access supporters living in Latin America.

This year's event will feature presentations from the EFF and the Freedom
of the Press Foundation, as well as Cory Doctorow, Chelsea Manning, and
Brewster Kahle, among many others. The full speaker schedule is available
here

.

Finally, if you aren't able to join us in person, you can watch the
livestream of the event online
!
We hope to see you soon!

REGISTER TO ATTEND


*Dates & Times*
Saturday, November 12, 2022, 10:00 AM
to Sunday, November 13, 2022, 9:00 PM

*Location*
300 Funston Avenue
San Francisco, CA 94118

OR

Online Event



*If you would like to make a tax-deductible donation to the Internet
Archive, we would greatly appreciate your support. You can lend a hand by
visiting archive.org/donate

or
by texting ARCHIVE to 44321. Thank you for helping us provide Universal
Access To All Knowledge. *
DONATE TO THE INTERNET ARCHIVE

[image: Facebook]

[image: Twitter]

[image: Instagram]

[image: Website]

You are receiving this email because of your relationship with the Internet
Archive.

*Our mailing address is:*
Internet Archive
300 Funston Avenue
San Francisco, CA 94118

*Want to change how you receive these emails?*
You can *update your preferences

*to
change what types of notifications you receive,
or switch from HTML format to plain text.
You can also *unsubscribe from this list

*if
you don't want to hear from us again.


-- 
This song goes out to all the folk that thought Stadia would work:
https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz
Dave Täht CEO, TekLibre, LLC
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

[Cake] cambium QoE sure looks like cake

[Dave Taht via Cake]

From:

https://www.cambiumnetworks.com/products/advanced-services/quality-of-experience/

"Cambium QoE platform allows you to enforce bandwidth limitations in a
flexible and economical way, with the most advanced queueing
technology in the market, which will deliver the best possible Quality
of Service (QoS) and Quality of Experience (QoE).

When speed is limited, network packets must wait in queues to be
delivered, which increases network latency and can create packet
losses. As a result, the network Quality of Experience may be severely
degraded, especially for interactive applications, like on-line games
and teleconferences, which are very sensitive to latency and losses.

Our unique multi-queue technology guarantees an independent queue for
each connection, without any sharing (unlike competing solutions).
Multiple independent queues ensure that interactive data do not have
to wait in queues with heavy traffic, like video streaming. Moreover,
interactive queues are prioritized. In this way, interactive
applications will not notice the rate limitation, even in congestion
situations."

I do hope they are keeping track of drop AND mark statistics...

-- 
This song goes out to all the folk that thought Stadia would work:
https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz
Dave Täht CEO, TekLibre, LLC
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

[Cake] QDISC_DROP_REASON project

[Dave Taht via Cake]

There were, at last count, 2600+ places where packets could be dropped
in the linux kernel, and that doesn't account for just dropping
packets at the physical layer and (I don't think) on the rx ring.
DROP_REASON support has been migrating into the kernel, but not yet
for qdiscs, and were it there, it would provide a convenient
tracepoint for why it happened, be it congestive, overflow, or self
defense.

You can pull apart the packets and see where they were going or where
they came from, and so on.

And it's kind of bad to be dropping packets for any other reason,
elsewhere in the system.

Similarly I am seeing a LOT of ecn marking in the field that I am not
sure is correct or not, and there's not a good way to track that
presently.

I had a student lined up for this, but she dropped out. I'd much
rather teach someone how to do this pretty basic job inside the kernel
than do it myself, so if you know anyone with even modest kernel
skills willing to take it on with me, I'd appreciate it.

- https://github.com/rchac/LibreQoS/issues/143

On Fri, Oct 28, 2022 at 1:12 PM Dave Taht  wrote:
>
> There is a ton of grant money going around, and various funds are
> closing at the end of this month or the next. If you know talented
> people that are being laid off, or just want to practice their craft
> in any way to make for a better internet, please pass these links
> along. If you know of any other funding sources, please post? I'd like
> to get a stable floor back under make-wifi-fast in particular, and
> find folk willing to fund or help out (and test) on the libreqos.io
> project.
>
> NLNET is eu only and has two funds focused on privacy and security.
> They are typically good for 30-50k eu and run for a year, a very short
> (3 pages or less) application flies well with them. Closing december 1st:
>
> https://nlnet.nl/assure/
> https://nlnet.nl/entrust/
>
> NLNET has been a huge supporter of bufferbloat.net over the years,
> most recently funding my "cerowrt ii" project, which was a
> constructive failure, in that I lost way too much time to dealing with
> regressions in the stack to make the slightest bit of forward
> progress.
>
> In germany there' s this:
>
> https://forum.openwrt.org/t/germanys-sovereign-tech-fund/141089
>
> And in america, ARDC is very focused on wireless applications.
>
> https://www.ampr.org/grants/
>
> The NSF POSE grants program just closed (we didn't qualify), pouring
> 21m into various open source orgs, or so I hope.
>
> --
> This song goes out to all the folk that thought Stadia would work:
> https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz
> Dave Täht CEO, TekLibre, LLC



-- 
This song goes out to all the folk that thought Stadia would work:
https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz
Dave Täht CEO, TekLibre, LLC
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

[Cake] grant funding avail for various open source projects

[Dave Taht via Cake]

There is a ton of grant money going around, and various funds are
closing at the end of this month or the next. If you know talented
people that are being laid off, or just want to practice their craft
in any way to make for a better internet, please pass these links
along. If you know of any other funding sources, please post? I'd like
to get a stable floor back under make-wifi-fast in particular, and
find folk willing to fund or help out (and test) on the libreqos.io
project.

NLNET is eu only and has two funds focused on privacy and security.
They are typically good for 30-50k eu and run for a year, a very short
(3 pages or less) application flies well with them. Closing december 1st:

https://nlnet.nl/assure/
https://nlnet.nl/entrust/

NLNET has been a huge supporter of bufferbloat.net over the years,
most recently funding my "cerowrt ii" project, which was a
constructive failure, in that I lost way too much time to dealing with
regressions in the stack to make the slightest bit of forward
progress.

In germany there' s this:

https://forum.openwrt.org/t/germanys-sovereign-tech-fund/141089

And in america, ARDC is very focused on wireless applications.

https://www.ampr.org/grants/

The NSF POSE grants program just closed (we didn't qualify), pouring
21m into various open source orgs, or so I hope.

-- 
This song goes out to all the folk that thought Stadia would work:
https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz
Dave Täht CEO, TekLibre, LLC
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] [Rpm] [Make-wifi-fast] The most wonderful video ever about bufferbloat

[Dave Taht via Cake]

I loved paced chirping.

I also loved packet subwindows. I wish we could all agree to get
cracking on working on those two things for cubic and reno rather than
whinging all the time about the stuff we will never agree on.
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] [Rpm] [Make-wifi-fast] The most wonderful video ever about bufferbloat

[Dave Taht via Cake]

On Thu, Oct 20, 2022 at 11:32 AM Stuart Cheshire  wrote:
>
> On 20 Oct 2022, at 02:36, Sebastian Moeller  wrote:
>
> > Hi Stuart,
> >
> > [SM] That seems to be somewhat optimistic. We have been there before, short 
> > of mandating actually-working oracle schedulers on all end-points, 
> > intermediate hops will see queues some more and some less transient. So we 
> > can strive to minimize queue build-up sure, but can not avoid queues and 
> > long queues completely so we need methods to deal with them gracefully.
> > Also not many applications are actually helped all that much by letting 
> > information get stale in their own buffers as compared to an on-path queue. 
> > Think an on-line reaction-time gated game, the need is to distribute 
> > current world state to all participating clients ASAP.
>
> I’m afraid you are wrong about this. If an on-line game wants low delay, the 
> only answer is for it to avoid generating position updates faster than the 
> network carry them. One packet giving the current game player position is 
> better than a backlog of ten previous stale ones waiting to go out. Sending 
> packets faster than the network can carry them does not get them to the 
> destination faster; it gets them there slower. The same applies to frames in 
> a screen sharing application. Sending the current state of the screen *now* 
> is better than having a backlog of ten previous stale frames sitting in 
> buffers somewhere on their way to the destination. Stale data is not 
> inevitable. Applications don’t need to have stale data if they avoid 
> generating stale data in the first place.

The core  of what you describe is that transports and applications are
evolving towards being delay aware, which is the primary outcome you
get from  FQ'd environment, be the FQs are physical (VoQs, LAGs,
multiple channels or subcarriers in wireless technologies) or virtual
(fq-codel, cake, fq-pie), so that the only source of congestion is
self-harm.

Everything from BBR to googles' gcc for videoconferencing, to recent
work on swift ( https://research.google/pubs/pub49448/ ) seems to be
pointing this way.

I'm also loving the work on reliable FQ detection for QUIC.
> Please watch this video, which explains it better than I can in a written 
> email:
>
> 
>
> Stuart Cheshire
>


-- 
This song goes out to all the folk that thought Stadia would work:
https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz
Dave Täht CEO, TekLibre, LLC
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] [Make-wifi-fast] [Rpm] The most wonderful video ever about bufferbloat

[Dave Taht via Cake]

On Thu, Oct 20, 2022 at 12:04 PM Bob McMahon via Make-wifi-fast
 wrote:
>
> Intel has a good analogous video on this with their CPU video here going over 
> branches and failed predictions. And to Stuart's point, the longer pipelines 
> make the forks worse in the amount of in-process bytes that need to be thrown 
> away. Interactivity, in my opinion, suggests shrinking the pipeline because, 
> with networks, there is no quick way to throw away stale data rather every 
> forwarding device continues forward with invalid data. That's bad for the 
> network too, spending resources on something that's no longer valid. We in 
> the test & measurement community never measure this.

One of my all time favorite demos was of stuart's remote desktop
scenario, where he moved the mouse and the window moved with it.

> There have been a few requests that iperf 2 measure the "bytes thrown away" 
> per a fork (user moves a video pointer, etc.) I haven't come up with a good 
> test yet. I'm still trying to get basic awareness about existing latency, OWD 
> and responsiveness metrics. I do think measuring the amount of resources 
> spent on stale data is sorta like food waste, few really pay attention to it.
>
> Bob
>
> FYI, iperf 2 supports TCP_NOTSENT_LOWAT for those interested.
>
> --tcp-write-prefetch n[kmKM]
> Set TCP_NOTSENT_LOWAT on the socket and use event based writes per select() 
> on the socket.
>
>
> On Thu, Oct 20, 2022 at 11:32 AM Stuart Cheshire via Make-wifi-fast 
>  wrote:
>>
>> On 20 Oct 2022, at 02:36, Sebastian Moeller  wrote:
>>
>> > Hi Stuart,
>> >
>> > [SM] That seems to be somewhat optimistic. We have been there before, 
>> > short of mandating actually-working oracle schedulers on all end-points, 
>> > intermediate hops will see queues some more and some less transient. So we 
>> > can strive to minimize queue build-up sure, but can not avoid queues and 
>> > long queues completely so we need methods to deal with them gracefully.
>> > Also not many applications are actually helped all that much by letting 
>> > information get stale in their own buffers as compared to an on-path 
>> > queue. Think an on-line reaction-time gated game, the need is to 
>> > distribute current world state to all participating clients ASAP.
>>
>> I’m afraid you are wrong about this. If an on-line game wants low delay, the 
>> only answer is for it to avoid generating position updates faster than the 
>> network carry them. One packet giving the current game player position is 
>> better than a backlog of ten previous stale ones waiting to go out. Sending 
>> packets faster than the network can carry them does not get them to the 
>> destination faster; it gets them there slower. The same applies to frames in 
>> a screen sharing application. Sending the current state of the screen *now* 
>> is better than having a backlog of ten previous stale frames sitting in 
>> buffers somewhere on their way to the destination. Stale data is not 
>> inevitable. Applications don’t need to have stale data if they avoid 
>> generating stale data in the first place.
>>
>> Please watch this video, which explains it better than I can in a written 
>> email:
>>
>> 
>>
>> Stuart Cheshire
>>
>> ___
>> Make-wifi-fast mailing list
>> make-wifi-f...@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/make-wifi-fast
>
>
> This electronic communication and the information and any files transmitted 
> with it, or attached to it, are confidential and are intended solely for the 
> use of the individual or entity to whom it is addressed and may contain 
> information that is confidential, legally privileged, protected by privacy 
> laws, or otherwise restricted from disclosure to anyone else. If you are not 
> the intended recipient or the person responsible for delivering the e-mail to 
> the intended recipient, you are hereby notified that any use, copying, 
> distributing, dissemination, forwarding, printing, or copying of this e-mail 
> is strictly prohibited. If you received this e-mail in error, please return 
> the e-mail to the sender, delete it from your computer, and destroy any 
> printed copy of it.___
> Make-wifi-fast mailing list
> make-wifi-f...@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast



-- 
This song goes out to all the folk that thought Stadia would work:
https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz
Dave Täht CEO, TekLibre, LLC
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

[Cake] A quick report from the WISPA conference

[Dave Taht via Cake]

On Mon, Oct 17, 2022 at 7:51 PM Sina Khanifar  wrote:
>
> Positive or negative, I can claim a bit of credit for this video :). We've 
> been working with LTT on a few projects and we pitched them on doing 
> something around bufferbloat. We've seen more traffic to our Waveforn test 
> than ever before, which has been fun!

Thank you. Great job with that video! And waveform has become the goto
site for many now.

I can't help but wonder tho... are you collecting any statistics, over
time, as to how much better the problem is getting?

And any chance they could do something similar explaining wifi?

...

I was just at WISPA conference week before last. Preseem's booth
(fq_codel) was always packed. Vilo living had put cake in their wifi 6
product. A
keynote speaker had deployed it and talked about it with waveform
results on the big screen (2k people there). A large wireless vendor
demo'd privately to me their flent results before/after cake on their
next-gen radios... and people dissed tarana without me prompting for
their bad bufferbloat... and the best thing of all that happened to me
was... besides getting a hug from a young lady (megan) who'd salvaged
her schooling in alaska using sqm - I walked up to the paraqum booth
(another large QoE middlebox maker centered more in india) and asked.

"So... do y'all have fq_codel yet?"

And they smiled and said: "No, we have something better... we've got cake."

"Cake? What's that?" - I said, innocently.

They then stepped me through their 200Gbps (!!) product, which uses a
bunch of offloads, and can track rtt down to a ms with the intel
ethernet card they were using. They'd modifed cake to provide 16 (?)
levels of service, and were running under dpdk (I am not sure if cake
was). It was a great, convincing pitch...

... then I told 'em who I was. There's a video of the in-both concert after.

...

The downside to me (and the subject of my talk) was that in nearly
every person I talked to, fq_codel was viewed as a means to better
subscriber bandwidth plan enforcement (which is admittedly the market
that preseem pioneered) and it was not understood that I'd got
involved in this whole thing because I'd wanted an algorithm to deal
with "rain fade", running directly on the radios. People wanted to use
the statistics on the radios to drive the plan enforcement better
(which is an ok approach, I guess), and for 10+ I'd been whinging
about the... physics.

So I ranted about rfc7567 a lot and begged people now putting routerOS
7.2 and later out there (mikrotik is huge in this market), to kill
their fifos and sfqs at the native rates of the interfaces... and
watch their network improve that way also.

I think one more wispa conference will be a clean sweep of everyone in
the fixed wireless market to not only adopt these algorithms for plan
enforcement, but even more directly on the radios and more CPE.

I also picked up enough consulting business to keep me busy the rest
of this year, and possibly more than I can handle (anybody looking?)

I wonder what will happen at a fiber conference?

> On Mon, Oct 17, 2022 at 7:45 PM Dave Taht via Bloat 
>  wrote:
>>
>> On Mon, Oct 17, 2022 at 5:02 PM Stuart Cheshire  wrote:
>> >
>> > On 9 Oct 2022, at 06:14, Dave Taht via Make-wifi-fast 
>> >  wrote:
>> >
>> > > This was so massively well done, I cried. Does anyone know how to get in 
>> > > touch with the ifxit folk?
>> > >
>> > > https://www.youtube.com/watch?v=UICh3ScfNWI
>> >
>> > I’m surprised that you liked this video. It seems to me that it repeats 
>> > all the standard misinformation. The analogy they use is the standard 
>> > terrible example of waiting in a long line at a grocery store, and the 
>> > “solution” is letting certain traffic “jump the line, angering everyone 
>> > behind them”.
>>
>> Accuracy be damned. The analogy to common experience resonates more.
>>
>> >
>> > Some quotes from the video:
>> >
>> > > it would be so much more efficient for them to let you skip the line and 
>> > > just check out, especially since you’re in a hurry, but they’re rudely 
>> > > refusing
>>
>> I think the person with the cheetos pulling out a gun and shooting
>> everyone in front of him (AQM) would not go down well.
>>
>> > > to go back to our grocery store analogy this would be like if a worker 
>> > > saw you standing at the back ... and either let you skip to the front of 
>> > > the line or opens up an express lane just for you
>>
>> Actually that analogy is fairly close to fair queuing. The multiple
>> checker analogy is one of the most common analogies in queue theory
>> itself.
>>
>> >
>> > The video describes the problem of bufferbloat, and then describes the 
>> > same failed solution that hasn’t worked for the last three decades.
>>
>> Hmm? It establishes the scenario, explains the problem *quickly*,
>> disses gamer routers for not getting it right..  *points to an
>> accurate test*, and then to the ideas and products that *actually
>> work* with "smart queueing", with a 

Re: [Cake] [Make-wifi-fast] The most wonderful video ever about bufferbloat

[Dave Taht via Cake]

On Mon, Oct 17, 2022 at 5:02 PM Stuart Cheshire  wrote:
>
> On 9 Oct 2022, at 06:14, Dave Taht via Make-wifi-fast 
>  wrote:
>
> > This was so massively well done, I cried. Does anyone know how to get in 
> > touch with the ifxit folk?
> >
> > https://www.youtube.com/watch?v=UICh3ScfNWI
>
> I’m surprised that you liked this video. It seems to me that it repeats all 
> the standard misinformation. The analogy they use is the standard terrible 
> example of waiting in a long line at a grocery store, and the “solution” is 
> letting certain traffic “jump the line, angering everyone behind them”.

Accuracy be damned. The analogy to common experience resonates more.

>
> Some quotes from the video:
>
> > it would be so much more efficient for them to let you skip the line and 
> > just check out, especially since you’re in a hurry, but they’re rudely 
> > refusing

I think the person with the cheetos pulling out a gun and shooting
everyone in front of him (AQM) would not go down well.

> > to go back to our grocery store analogy this would be like if a worker saw 
> > you standing at the back ... and either let you skip to the front of the 
> > line or opens up an express lane just for you

Actually that analogy is fairly close to fair queuing. The multiple
checker analogy is one of the most common analogies in queue theory
itself.

>
> The video describes the problem of bufferbloat, and then describes the same 
> failed solution that hasn’t worked for the last three decades.

Hmm? It establishes the scenario, explains the problem *quickly*,
disses gamer routers for not getting it right..  *points to an
accurate test*, and then to the ideas and products that *actually
work* with "smart queueing", with a screenshot of the most common
(eero's optimize for gaming and videoconferencing), and fq_codel and
cake *by name*, and points folk at the best known solution available,
openwrt.

Bing, baddabang, boom. Also the comments were revealing. A goodly
percentage already knew the problem, more than a few were inspired to
take the test,
there was a whole bunch of "Aha!" success stories and 360k views,
which is more people than we've ever been able to reach in for
example, a nanog conference.

I loved that folk taking the test actually had quite a few A results,
without having had to do anything. At least some ISPs are getting it
more right now!

At this point I think gamers in particular know what "brands" we've
tried to establish - "Smart queues", "SQM", "OpenWrt", fq_codel and
now "cake" are "good" things to have, and are stimulating demand by
asking for them,   It's certainly working out better and better for
evenroute, firewalla, ubnt and others, and I saw an uptick in
questions about this on various user forums.

I even like that there's a backlash now of people saying "fixing
bufferbloat doesn't solve everything" -

>  Describing the obvious simple-minded (wrong) solution that any normal person 
> would think of based on their personal human experience waiting in grocery 
> stores and airports, is not describing the solution to bufferbloat. The 
> solution to bufferbloat is not that if you are privileged then you get to 
> “skip to the front of the line”. The solution to bufferbloat is that there is 
> no line!

I like the idea of a guru floating above a grocery cart with a better
string of explanations, explaining

   - "no, grasshopper, the solution to bufferbloat is no line... at all".

>
> With grocery stores and airports people’s arrivals are independent and not 
> controlled. There is no way for a grocery store or airport to generate 
> backpressure to tell people to wait at home when a queue begins to form. The 
> key to solving bufferbloat is generating timely backpressure to prevent the 
> queue forming in the first place, not accepting a huge queue and then 
> deciding who deserves special treatment to get better service than all the 
> other peons who still have to wait in a long queue, just like before.

I am not huge on the word "backpressure" here. Needs to signal the
other side to slow down, is more accurate. So might say timely
signalling rather than timely backpressure?

Other feedback I got  was that the video was too smarmy (I agree),
different audiences than gamers need different forms of outreach...

but to me, winning the gamers has always been one of the most
important things, as they make a lot of buying decisions, and they
benefit the most for
fq and packet prioritization as we do today in gamer routers and in
cake + qosify.

maybe that gets in the way of more serious markets. Certainly I would
like another video explaining what goes wrong with videoconferencing.






>
> Stuart Cheshire
>


-- 
This song goes out to all the folk that thought Stadia would work:
https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz
Dave Täht CEO, TekLibre, LLC
___
Cake mailing list
Cake@lists.bufferbloat.net

[Cake] cake anecdote from firewalla

[Dave Taht via Cake]

"My favorite anecdote regarding CAKE is one time I started a B2 backup
from my NAS and removed all device-side upload restrictions (which
would normally render the internet unusable from that point on). Then
I fired up nvidia's game streaming on the Shield to try the Tomb
Raider demo. Long story short, an hour into the gameplay I forgot I
was even running the backup (which was still running full tilt). That
was the moment I knew CAKE was the hill I would die on." -
https://www.reddit.com/r/firewalla/comments/y2257v/cake_for_smart_queues/


-- 
This song goes out to all the folk that thought Stadia would work:
https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz
Dave Täht CEO, TekLibre, LLC
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] [Rpm] [Bloat] [Make-wifi-fast] The most wonderful video ever about bufferbloat

[Dave Taht via Cake]

Well, we've all been yammering for many years, and the message is
getting through. Yes, at this point, changing the message to be more
directed at engineers than users would help, and to this day, I don't
know how to get to anyone in the
C suite, except through the complaints of their kids. Jim got on this
problem because of his kids. The guy that did dslreports, also. "my"
kids are

At the risk of burying the lede, our very own dave reed just did a
podcast on different stuff:
https://twit.tv/shows/floss-weekly/episodes/701?autostart=false

Sometimes my own (shared with most of you) motivations tend to leak
through. I really encourage the independent growth of user created and
owned software, running on their own routers, and I'm very pleased to
see the level of activity on the openwrt forums showing how healthy
that part of our culture is. It would be a very different world if
we'd decided to settle for whatever an ISP was willing to give us, and
for things as they were, and I'm probably difficult to employ because
of my
fervent beliefs in anti-patenting, free and open source, and the right
to repair...

... but I wouldn't have my world any other way. I might die broke, but
I'll die free.

On Tue, Oct 11, 2022 at 11:44 AM Rich Brown via Rpm
 wrote:
>
>
>
>
> On Oct 11, 2022, at 1:05 PM, Bob McMahon  wrote:
>
> I agree that bufferbloat awareness is a good thing. The issue I have is the 
> approach - ask consumers to "detect it" and replace a device with a new one, 
> that may or may not, meet all the needs of the users.
>
>
> Better is that network engineers "design bloat out" from the beginning 
> starting by properly sizing queues to service jitter, and for WiFi, to also 
> enable aggregation techniques that minimize TXOP consumption.
>
>
> The Yes, but... part of my answer emphasizes awareness. How are the network 
> engineers going to know it's worth the (minor) effort of creating 
> properly-sized queues?
>
> There are two fronts to attack:
>
> - Manufacturers - This video is a start on getting their customers to use 
> these responsiveness test tools and call the support lines.
>
> - Hardware (especially router) reviewers - It kills me that there is radio 
> silence whenever I ask a reviewer if they have ever measured 
> latency/responsiveness.  (BTW: Has anyone heard from Ben Moskowitz from 
> Consumer Reports? We had a very encouraging phone call about a year ago, and 
> they were going to get back to us...)
>
> Rich
>
>
> Bob
>
> On Tue, Oct 11, 2022 at 6:57 AM Rich Brown  wrote:
>>
>>
>>
>> On Oct 10, 2022, at 8:05 PM, Bob McMahon via Rpm 
>>  wrote:
>>
>> > I think conflating bufferbloat with latency misses the subtle point in that
>> > bufferbloat is a measurement in memory units more than a measurement in
>> > time units.
>>
>>
>> Yes, but... I am going to praise this video, even as I encourage all the 
>> techies to be sure that they have the units correct.
>>
>> I've been yammering about the evils of latency/excess queueing for 10 years 
>> on my blog, in forums, etc. I have not achieved anywhere near the notoriety 
>> of this video (almost a third of a million views).
>>
>> I am delighted that there's an engaging, mass-market Youtube video that 
>> makes the case that bufferbloat even exists.
>>
>> Rich
>
>
> This electronic communication and the information and any files transmitted 
> with it, or attached to it, are confidential and are intended solely for the 
> use of the individual or entity to whom it is addressed and may contain 
> information that is confidential, legally privileged, protected by privacy 
> laws, or otherwise restricted from disclosure to anyone else. If you are not 
> the intended recipient or the person responsible for delivering the e-mail to 
> the intended recipient, you are hereby notified that any use, copying, 
> distributing, dissemination, forwarding, printing, or copying of this e-mail 
> is strictly prohibited. If you received this e-mail in error, please return 
> the e-mail to the sender, delete it from your computer, and destroy any 
> printed copy of it.
>
>
> ___
> Rpm mailing list
> r...@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/rpm



-- 
This song goes out to all the folk that thought Stadia would work:
https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz
Dave Täht CEO, TekLibre, LLC
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] [Rpm] [Bloat] [Make-wifi-fast] The most wonderful video ever about bufferbloat

[Dave Taht via Cake]

On Tue, Oct 11, 2022 at 9:58 AM Bob McMahon via Rpm
 wrote:
>
> > Saturate a link in both directions simultaneously with multiple greedy 
> > flows while measuring load-dependent latency changes for small isochronous 
> > probe flows.
>
> This functionality is released in iperf 2.1.8 per the bounceback feature but, 
> unfortunately, OpenWRT doesn't maintain iperf 2 as a package anymore and uses 
> 2.0.13

iperf 2.1.8 was pushed into the openwrt mainline and may appear as of
22.03.1. I'll check.

>
> CLIENT SPECIFIC OPTIONS
>
> --bounceback[=n]run a TCP bounceback or rps test with optional number writes 
> in a burst per value of n. The default is ten writes every period and the 
> default period is one second (Note: set size with -l or --len which defaults 
> to 100 bytes)--bounceback-congest[=up|down|bidir][,n]request a concurrent 
> working load or TCP stream(s), defaults to full duplex (or bidir) unless the 
> up or down option is provided. The number of TCP streams defaults to 1 and 
> can be changed via the n value, e.g. --bounceback-congest=down,4 will use 
> four TCP streams from server to the client as the working load. The IP ToS 
> will be BE (0x0) for working load traffic.--bounceback-hold nrequest the 
> server to insert a delay of n milliseconds between its read and write 
> (default is no delay)--bounceback-period[=n]request the client schedule its 
> send(s) every n seconds (default is one second, use zero value for immediate 
> or continuous back to back)--bounceback-no-quickackrequest the server not set 
> the TCP_QUICKACK socket option (disabling TCP ACK delays) during a bounceback 
> test (see NOTES)--bounceback-txdelay nrequest the client to delay n seconds 
> between the start of the working load and the bounceback traffic (default is 
> no delay)
>
> On Tue, Oct 11, 2022 at 12:15 AM Sebastian Moeller  wrote:
>>
>> Hi Bob,
>>
>> On 11 October 2022 02:05:40 CEST, Bob McMahon  
>> wrote:
>> >It's too big because it's oversized so it's in the size domain. It's
>> >basically Little's law's value for the number of items in a queue.
>> >
>> >*Number of items in the system = (the rate items enter and leave the
>> >system) x (the average amount of time items spend in the system)*
>> >
>> >
>> >Which gets driven to the standing queue size when the arrival rate
>> >exceeds the service rate - so the driving factor isn't the service and
>> >arrival rates, but *the queue size *when *any service rate is less than an
>> >arrival rate.*
>>
>> [SM] You could also argue it is the ratio of arrival to service rates, with 
>> the queue size being a measure correlating with how long the system will 
>> tolerate ratios larger than one...
>>
>>
>> >
>> >In other words, one can find and measure bloat regardless of the
>> >enter/leave rates (as long as the leave rate is too slow) and the value of
>> >memory units found will always be the same.
>> >
>> >Things like prioritizations to jump the line are somewhat of hacks at
>> >reducing the service time for a specialized class of packets but nobody
>> >really knows which packets should jump.
>>
>> [SM] Au contraire most everybody 'knows' it is their packets that should 
>> jump ahead of the rest ;) For intermediate hop queues however that endpoint 
>> perception is not really actionable due to lack of robust and reliable 
>> importance identifiers on packets. In side a 'domain' dscps might work if 
>> treated to strict admission control, but that typically will not help 
>> end2end traffic over the internet. This is BTW why I think FQ is a great 
>> concept, as it mostly results in the desirable outcome of not picking 
>> winners and losers (like arbitrarily starving a flow), but I digress.
>>
>> >Also, nobody can define what
>> >working conditions are so that's another problem with this class of tests.
>>
>> [SM] While real working conditions will be different for each link and 
>> probably vary over time, it seems achievable to come up with a set of 
>> pessimistic assumptions how to model a challenging work condition against 
>> which to test potential remedies, assuming that such remedies will also work 
>> well under less challenging conditions, no?
>>
>>
>> >
>> >Better maybe just to shrink the queue and eliminate all unneeded queueing
>> >delays.
>>
>> [SM] The 'unneeded' does a lot of work in that sentence ;). I like Van's? 
>> Description of queues as shock absorbers so queue size will have a lower 
>> acceptable limit assuming users want to achieve 'acceptable' throughput even 
>> with existing bursty senders. (Not all applications are suited for pacing so 
>> some level of burstiness seems unavoidable).
>>
>>
>> > Also, measure the performance per "user conditions" which is going
>> >to be different for almost every environment (and is correlated to time and
>> >space.) So any engineering solution is fundamentally suboptimal.
>>
>> [SM] A matter of definition, if the requirement is to cover many user 
>> conditions the optimality measure simply needs 

Re: [Cake] [Make-wifi-fast] [Rpm] [Bloat] The most wonderful video ever about bufferbloat

[Dave Taht via Cake]

On Tue, Oct 11, 2022 at 6:57 AM Rich Brown via Make-wifi-fast
 wrote:
>
>
>
> On Oct 10, 2022, at 8:05 PM, Bob McMahon via Rpm  
> wrote:
>
> > I think conflating bufferbloat with latency misses the subtle point in that
> > bufferbloat is a measurement in memory units more than a measurement in
> > time units.
>
>
> Yes, but... I am going to praise this video, even as I encourage all the 
> techies to be sure that they have the units correct.
>
> I've been yammering about the evils of latency/excess queueing for 10 years 
> on my blog, in forums, etc. I have not achieved anywhere near the notoriety 
> of this video (almost a third of a million views).
>
> I am delighted that there's an engaging, mass-market Youtube video that makes 
> the case that bufferbloat even exists.
>
> Rich
> ___
> Make-wifi-fast mailing list
> make-wifi-f...@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast

I have to admit my ideal presenter is more of a neal degrasse tyson

https://twitter.com/neiltyson/status/1579165291434897409

but ya know, I ended up thinking about doing a funny script along the
flow of what's wrong with wifi...

-- 
This song goes out to all the folk that thought Stadia would work:
https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz
Dave Täht CEO, TekLibre, LLC
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] [Bloat] The most wonderful video ever about bufferbloat

[Dave Taht via Cake]

I guess my question is, erik, do you sell these routers commercially?
There is a huge latent market in the US that could use upgrades.
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] The most wonderful video ever about bufferbloat

[Dave Taht via Cake]

I saw you there.

I made a bunch of comments this morning. But they all disappeared,
possibly because I provided links to more information.


On Sun, Oct 9, 2022 at 12:57 PM Thomas Croghan via Cake
 wrote:
>
> There seems to be quite a lot of misinformation being spread in the comments. 
> It might be good if some of the people who are pretty familiar with this tech 
> jump in and help to minimize the disinformation spread.
>
> On Sun, Oct 9, 2022, 12:35 Kenneth Porter via Cake 
>  wrote:
>>
>> The video comments are interesting. Some pushback against blindly
>> turning on SQM.
>>
>> For example, using Cake might not be good on an older router with a
>> gutless CPU and FQ-CoDel might be the better choice.
>>
>> It might be useful to accumulate all the objections there and create a
>> wiki page responding to them in an organized way.
>>
>>
>> ___
>> Cake mailing list
>> Cake@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cake
>
> ___
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake



-- 
This song goes out to all the folk that thought Stadia would work:
https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz
Dave Täht CEO, TekLibre, LLC
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

[Cake] The most wonderful video ever about bufferbloat

[Dave Taht via Cake]

This was so massively well done, I cried. Does anyone know how to get
in touch with the ifxit folk?

https://www.youtube.com/watch?v=UICh3ScfNWI

-- 
This song goes out to all the folk that thought Stadia would work:
https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz
Dave Täht CEO, TekLibre, LLC
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

[Cake] Fwd: [PATCH net-next 1/5] tcp: add sysctls for TCP PLB parameters

[Dave Taht via Cake]

I've often thought that utilizing the flow label in the hash would
help. But could be wrong.

-- Forwarded message -
From: Mubashir Adnan Qureshi 
Date: Thu, Sep 29, 2022 at 8:02 AM
Subject: [PATCH net-next 1/5] tcp: add sysctls for TCP PLB parameters
To: David Miller 
Cc: , Mubashir Adnan Qureshi
, Yuchung Cheng , Neal
Cardwell , Eric Dumazet 


From: Mubashir Adnan Qureshi 

PLB (Protective Load Balancing) is a host based mechanism for load
balancing across switch links. It leverages congestion signals(e.g. ECN)
from transport layer to randomly change the path of the connection
experiencing congestion. PLB changes the path of the connection by
changing the outgoing IPv6 flow label for IPv6 connections (implemented
in Linux by calling sk_rethink_txhash()). Because of this implementation
mechanism, PLB can currently only work for IPv6 traffic. For more
information, see the SIGCOMM 2022 paper:
  https://doi.org/10.1145/3544216.3544226

This commit adds new sysctl knobs and sets their default values for
TCP PLB.

Signed-off-by: Mubashir Adnan Qureshi 
Signed-off-by: Yuchung Cheng 
Signed-off-by: Neal Cardwell 
Reviewed-by: Eric Dumazet 
---
 Documentation/networking/ip-sysctl.rst | 75 ++
 include/net/netns/ipv4.h   |  5 ++
 net/ipv4/sysctl_net_ipv4.c | 43 +++
 net/ipv4/tcp_ipv4.c|  8 +++
 4 files changed, 131 insertions(+)

diff --git a/Documentation/networking/ip-sysctl.rst
b/Documentation/networking/ip-sysctl.rst
index e7b3fa7bb3f7..815efc89ad73 100644
--- a/Documentation/networking/ip-sysctl.rst
+++ b/Documentation/networking/ip-sysctl.rst
@@ -1069,6 +1069,81 @@ tcp_child_ehash_entries - INTEGER

Default: 0

+tcp_plb_enabled - BOOLEAN
+   If set and the underlying congestion control (e.g. DCTCP) supports
+   and enables PLB feature, TCP PLB (Protective Load Balancing) is
+   enabled. PLB is described in the following paper:
+   https://doi.org/10.1145/3544216.3544226. Based on PLB parameters,
+   upon sensing sustained congestion, TCP triggers a change in
+   flow label field for outgoing IPv6 packets. A change in flow label
+   field potentially changes the path of outgoing packets for switches
+   that use ECMP/WCMP for routing.
+
+   PLB changes socket txhash which results in a change in IPv6 Flow Label
+   field, and currently no-op for IPv4 headers. It is possible
+   to apply PLB for IPv4 with other network header fields (e.g. TCP
+   or IPv4 options) or using encapsulation where outer header is used
+   by switches to determine next hop. In either case, further host
+   and switch side changes will be needed.
+
+   When set, PLB assumes that congestion signal (e.g. ECN) is made
+   available and used by congestion control module to estimate a
+   congestion measure (e.g. ce_ratio). PLB needs a congestion measure to
+   make repathing decisions.
+
+   Default: FALSE
+
+tcp_plb_idle_rehash_rounds - INTEGER
+   Number of consecutive congested rounds (RTT) seen after which
+   a rehash can be performed, given there are no packets in flight.
+   This is referred to as M in PLB paper:
+   https://doi.org/10.1145/3544216.3544226.
+
+   Possible Values: 0 - 31
+
+   Default: 3
+
+tcp_plb_rehash_rounds - INTEGER
+   Number of consecutive congested rounds (RTT) seen after which
+   a forced rehash can be performed. Be careful when setting this
+   parameter, as a small value increases the risk of retransmissions.
+   This is referred to as N in PLB paper:
+   https://doi.org/10.1145/3544216.3544226.
+
+   Possible Values: 0 - 31
+
+   Default: 12
+
+tcp_plb_suspend_rto_sec - INTEGER
+   Time, in seconds, to suspend PLB in event of an RTO. In order to avoid
+   having PLB repath onto a connectivity "black hole", after an RTO a TCP
+   connection suspends PLB repathing for a random duration between 1x and
+   2x of this parameter. Randomness is added to avoid concurrent rehashing
+   of multiple TCP connections. This should be set corresponding to the
+   amount of time it takes to repair a failed link.
+
+   Possible Values: 0 - 255
+
+   Default: 60
+
+tcp_plb_cong_thresh - INTEGER
+   Fraction of packets marked with congestion over a round (RTT) to
+   tag that round as congested. This is referred to as K in the PLB paper:
+   https://doi.org/10.1145/3544216.3544226.
+
+   The 0-1 fraction range is mapped to 0-256 range to avoid floating
+   point operations. For example, 128 means that if at least 50% of
+   the packets in a round were marked as congested then the round
+   will be tagged as congested.
+
+   Setting threshold to 0 means that PLB repaths every RTT regardless
+   of congestion. This is not intended behavior for PLB and should be
+   used only for experimentation purpose.
+
+   Possible 

[Cake] Oct 2-6 wispa-apalooza conference in las vegas

[Dave Taht via Cake]

I am speaking (talking about rfc7567's demand for fq+aqm on
everything), moderating a panel, and haunting a booth or two, guitar
in hand, at this WISP-oriented conference. A lot of things I(we've)
been working on this past year are coming to a head here, everything
from coping with the broadband maps debacle, the FCC not taking ookla
or samknows latency under load data, and the $60B NTIA broadband fund
programs still not funding ipv6, to the new openwrt and mikrotik
releases, to seeing cake and fq_codel enter more ISP middleboxes via
preseem and libreqos. Anyone here going?

https://wispaevents.org/booth-map/

Rumor has it that at least one new PtMP WISP radio will have fq_codel
in it, in addition to the mikrotik, openwifi and ISPAPP stuff. There
are a bunch of other products there, when I went last time, that were
running "our stuff" (most didn't know it). It's not a hugely technical
conference, but in particular if you want to learn more than you ever
wanted to know about the current state of outdoor fixed wireless,
fiber, and legal stuff, very worth doing. And the food is good.

I like WISP folk a lot, the kind of ornery old-fashioned american
small businessfolk that get s**t done. In my case I'm going to try and
drum up a bit of business for "network tuneups" and custom openwrt
builds, in addition to getting a feel for the state of things in DC.

Bringing funnels.

-- 
FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

[Cake] libreqos consultants wanted

[Dave Taht via Cake]

I have been doing a bit of (yay! paid!) work, here or there, on
libreqos, and I'm really encouraged by how well cake and the xdp stuff
are working at scale. See https://libreqos.io/ or the github:
https://github.com/rchac/LibreQoS

Ideally something like this could be running at a lot of (especially
smaller and outside the first world) ISPs. So if there's anyone out
there that is interested in consulting on it, please let me know your
contact details and we can add you to this page.

https://libreqos.io/consultants/

Long term I can see ideas in this migrating back into openwrt, and
into the commercial stuff like preseem, etc -  and already I've got
some ideas for a new cake feature or two. It seems to be a way to help
a lot of people really fast.

-- 
FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

[Cake] ack-monitor?

[Dave Taht via Cake]

Given the success of ack filtering, and cake in the libreqos system
(now scaling past 10Gbit) and pping and ebpf pping turning out to be
pretty high overhead... I started to muse over here about the idea of
even more detailed stats than
what we get:

https://github.com/rchac/LibreQoS/issues/58

I don't know how the quic "spin bit" is supposed to work, but that too, perhaps.

-- 
FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

[Cake] keenetic uses cake

[Dave Taht via Cake]

https://crast.net/149182/enhanced-gaming-with-keenetic/

But with dscp precedence, oh, my!

-- 
FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] CAKE saves someone's job during the pandemic...

[Dave Taht via Cake]

On Thu, Aug 25, 2022 at 2:39 PM Toke Høiland-Jørgensen via Cake
 wrote:
>
> I figured y'all would find this an uplifting story - I certainly did!
>
> https://forum.openwrt.org/t/nftables-and-qos-in-2021/112013/530

I cried. thx.

> -Toke
> ___
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake



-- 
FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] [PATCH net] sch_cake: Return __NET_XMIT_STOLEN when consuming enqueued skb

[Dave Taht via Cake]

hmm. what did this break above it? just stats? or a mem leak? or?

On Wed, Aug 31, 2022 at 2:25 AM Toke Høiland-Jørgensen via Cake
 wrote:
>
> When the GSO splitting feature of sch_cake is enabled, GSO superpackets
> will be broken up and the resulting segments enqueued in place of the
> original skb. In this case, CAKE calls consume_skb() on the original skb,
> but still returns NET_XMIT_SUCCESS. This can confuse parent qdiscs into
> assuming the original skb still exists, when it really has been freed. Fix
> this by adding the __NET_XMIT_STOLEN flag to the return value in this case.
>
> Fixes: 0c850344d388 ("sch_cake: Conditionally split GSO segments")
> Signed-off-by: Toke Høiland-Jørgensen 
> ---
>  net/sched/sch_cake.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/net/sched/sch_cake.c b/net/sched/sch_cake.c
> index a43a58a73d09..a04928082e4a 100644
> --- a/net/sched/sch_cake.c
> +++ b/net/sched/sch_cake.c
> @@ -1713,6 +1713,7 @@ static s32 cake_enqueue(struct sk_buff *skb, struct 
> Qdisc *sch,
> }
> idx--;
> flow = >flows[idx];
> +   ret = NET_XMIT_SUCCESS;
>
> /* ensure shaper state isn't stale */
> if (!b->tin_backlog) {
> @@ -1771,6 +1772,7 @@ static s32 cake_enqueue(struct sk_buff *skb, struct 
> Qdisc *sch,
>
> qdisc_tree_reduce_backlog(sch, 1-numsegs, len-slen);
> consume_skb(skb);
> +   ret |= __NET_XMIT_STOLEN;
> } else {
> /* not splitting */
> cobalt_set_enqueue_time(skb, now);
> @@ -1904,7 +1906,7 @@ static s32 cake_enqueue(struct sk_buff *skb, struct 
> Qdisc *sch,
> }
> b->drop_overlimit += dropped;
> }
> -   return NET_XMIT_SUCCESS;
> +   return ret;
>  }
>
>  static struct sk_buff *cake_dequeue_one(struct Qdisc *sch)
> --
> 2.37.2
>
> ___
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake



-- 
FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

[Cake] cake across a 2gbit service release

[Dave Taht via Cake]

https://gist.github.com/thestinger/cc10fdebfc0062f4c9e9adce007f2dec

-- 
FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] [Starlink] starlink terminal mod chip

[Dave Taht via Cake]

I apologize for not replying sooner, I was trying to take a vacation
and ended up ploughing
through my backlog of paper instead, and trying to take apart some
interesting data from a real
ISPs pre-wireless-n network.

On Tue, Aug 16, 2022 at 12:29 PM David P. Reed via Starlink
 wrote:
>
>
>
> On Sunday, August 14, 2022 12:00pm, starlink-requ...@lists.bufferbloat.net 
> said:
>
> > Date: Sat, 13 Aug 2022 09:41:54 -0700
> > From: Dave Taht 
> > To: Dave Taht via Starlink 
> > Subject: [Starlink] starlink terminal mod chip
> >
> > It's been my hope that starlink would merely install cake on the
> > uplink themselves... but it's finally possible to get in there and do
> > the work ourselves:
> >
> > https://github.com/KULeuven-COSIC/Starlink-FI
>
>
>
> As a big fan of Cake (and a happy user of it),

thx! :)

> I think it's fair to say that Starlink's capacity sharing method does not 
> have a stable rate, almost certainly.

At which points in the network is that true? I am really vague on how
they might be encoding symbols in general, and what sort of on/off
periods are native to the mac? I have a deep "gut" feel only for how
wifi behaves, and thought that they would be multiplexing terminals
via bursting data over a short period from each. I don't really see
that but the max resolution of the irtt data I have is 3ms. Shooting
for 100us next.

There does not appear to be wifi-like retransmits, either, but I can
hardly imagine mobility working without that.

Do they encode at at different rate at different distance?

> Has starlink published its link-scheduling approach?

Aside from the known 15s interval for potentially rerouting and/or
changing bandwidth, no. Rigorously exploring the analog signalling
up/down relative to attempts to use bandwidth in various ways
may lend insight. An example might be after determining the exact 15s
interval, a syn synack, and then waiting  that interval before
emitting an IW256 burst.

It often seems very much a network designed for speedtest rather than
real traffic.

> Probably it is closer to polled (controlled by the ground station, not the 
> terminal).

There are at least 3 tiers of service on starlink. I don't know if
anyone has pulled the signals off when idle, semi-idle or otherwise.

> Cake assumes that the uplink to the public Internet is, at the link layer, 
> stable and unvarying in its rate, so cake's control theory assumes that. The 
> downlink assumption is similar.

This is overbroad. Cake's shaper assumes that. The codel component,
without that engaged, feeding packets in via local backpressure, even
over fairly large intervals, is fluid. The queue delay target needs to
be greater than the transmit interval.

>
>
> So here's why I would NOT recommend just adding Cake to the starlink terminal 
> - it's the wrong link model.

Heh. My hope was for link backpressure, the hw asking the qdisc to
release packets to be encrypted an transmitted sufficiently enough
usec before the txop arrived.

> Let's assume there is just one satellite that the terminal is using for its 
> packets. The satellite is dealing with dozens of terminals at once. The 
> satellite-to-ground-station link is more like a standard fixed rate link, 
> being multiplexed among use by dozens of terminals.
>
>
>
> This terminal traffic is NOT the way a "home router" uses a cable modem or 
> DSL or fiber modem.
>
>
>
> If you want to get something approaching minimal latency and  fair-queueing 
> (which isn't "fair" because the term "fair" just means starvation free in 
> most queueing theory and networking applications), you need to drop packets 
> or send congestion signals that are based on the *achievable rate* of the 
> link.
>
>
>
> However, the achievable rate of the link is being dynamically managed by the 
> *ground station* needing to balance traffic among all terminals generating 
> flows through the ground station end.
>
>
>
> Most likely this will result in Cake and the ground station getting in a 
> "battle" to achieve good utilization.

yes.

>
>
> The same issue arises if you try to use Cake in each node sharing a WiFi LAN. 
> The WiFi protocols (including the polled mode in 802.11ax, but also the older 
> 802.11 CSMA-CA Aloha style before 11ax) actively "schedule" the shared WLAN 
> air link - either centrally or in a decentralized manner. Putting Cake as a 
> congestion mechanism on a shared air link is problematic because the 
> competing traffic causes the available capacity to vary tremendously, over 
> short time intervals.

yes. I got some interesting data on that exact scenario (using a
libreqos middlebox) which I'm still thinking about.

>
>
>
> The problem here is that the timescale of the scheduling of link bandwidth is 
> incompatible with the end-to-end TCP congestion control loops. This 
> guarantees control theory instability.

While I don't disagree a cite or three would help me. Yes! unstable!
How unstable?

My mental model, originally, was that the terminal 

[Cake] gearbox fpga wfq scheduler

[Dave Taht via Cake]

among other things a normalized fairness metric...

https://www.usenix.org/system/files/nsdi22-paper-gao_peixuan.pdf
-- 
FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

[Cake] paper: Testbed based analysis of Linux queue disciplines over Internet traffic mix

[Dave Taht via Cake]

This paper details the modelling of a mixed traffic testbed designed
in accordance with RFC 7982, and attempts to study the performance of
pie/codel/RED/fq-pie/fq-codel/cake. It's very thorough, but only tests
10Mbit and 100Mbit links. Cake wins on most of the benchmarks, fq-pie
wins on others. Really great MOS for voip traffic for fq-*.

https://www.sciencedirect.com/science/article/abs/pii/S1569190X22000843

If you don't have access via your institution, pls drop me a line privately.

-- 
FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

[Cake] openwrt-22-03-rc6 released

[Dave Taht via Cake]

It's my hope that the last of the major wifi bugs plaguing openwrt
have been quashed. Please test.

https://forum.openwrt.org/t/openwrt-22-03-0-rc6-sixth-release-candidate/133673

Especially if you are using the ath10k, 9k, or mt76 chips. For some
suggested tests see:

https://forum.openwrt.org/t/aql-and-the-ath10k-is-lovely/59002/830

-- 
FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

[Cake] battlemesh conference sept 19-22 in Rome

[Dave Taht via Cake]

I am giving a talk tentatively entitled "the meshy mess". This is a
pretty good technical conference consisting of a lot of core wifi
(openwrt), hackerspace, and community network people, and run on the
cheap, and one of the few routing interop events that exists. Hope to
see some of you in person! (In particular, they really, really want to
find a speaker - not me! - to talk deeply about starlink)

Call for Participation see:
https://www.battlemesh.org/BattleMeshV14/Talk_proposals


Topics:

Wireless Community Networks
Mesh Routing Protocol Development
Free hardware and free software for Community Networks
Community Networks that deploy Fiber-to-the-Home (FTTH) networks
TV white space as a precious network resource (radio spectrum)
How to organize a durable community structure?
How to involve non-technical people? To "digital stewardship" and beyond?
How to disseminate the spirit of community networks, knowledge etc?
Connecting rural areas: challenges and solutions
Public fiber networks: architecture, funding, private actors involved, oversight
Internet of Things (IoT) networks and their impact on society
Local Internet Exchange Points (IXPs) as a common infrastructure



-- 
FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

[Cake] pcq on mikrotik

[Dave Taht via Cake]

at some point I'd like to compare cake vs:

https://wiki.mikrotik.com/wiki/Manual:Queues_-_PCQ

-- 
FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

[Cake] Fwd: [RFC PATCH net-next v3 1/4] flow_dissector: Add PPPoE dissectors

[Dave Taht via Cake]

ppp makes my head hurt. so does mpls. when do we need to dissect it?

-- Forwarded message -
From: Marcin Szycik 
Date: Wed, Jun 29, 2022 at 8:01 AM
Subject: [RFC PATCH net-next v3 1/4] flow_dissector: Add PPPoE dissectors
To: 
Cc: , ,
, ,
, ,
, ,
, , ,
, , ,
, ,
, ,
,
, ,
, ,
, 


From: Wojciech Drewek 

Allow to dissect PPPoE specific fields which are:
- session ID (16 bits)
- ppp protocol (16 bits)

The goal is to make the following TC command possible:

  # tc filter add dev ens6f0 ingress prio 1 protocol ppp_ses \
  flower \
pppoe_sid 12 \
ppp_proto ip \
  action drop

Note that only PPPoE Session is supported.

Signed-off-by: Wojciech Drewek 
---
v3: revert byte order changes in is_ppp_proto_supported from previous
version, add kernel-doc for is_ppp_proto_supported
v2: use ntohs instead of htons in is_ppp_proto_supported

 include/net/flow_dissector.h | 11 
 net/core/flow_dissector.c| 55 
 2 files changed, 60 insertions(+), 6 deletions(-)

diff --git a/include/net/flow_dissector.h b/include/net/flow_dissector.h
index a4c6057c7097..8ff40c7c3f1c 100644
--- a/include/net/flow_dissector.h
+++ b/include/net/flow_dissector.h
@@ -261,6 +261,16 @@ struct flow_dissector_key_num_of_vlans {
u8 num_of_vlans;
 };

+/**
+ * struct flow_dissector_key_pppoe:
+ * @session_id: pppoe session id
+ * @ppp_proto: ppp protocol
+ */
+struct flow_dissector_key_pppoe {
+   u16 session_id;
+   __be16 ppp_proto;
+};
+
 enum flow_dissector_key_id {
FLOW_DISSECTOR_KEY_CONTROL, /* struct flow_dissector_key_control */
FLOW_DISSECTOR_KEY_BASIC, /* struct flow_dissector_key_basic */
@@ -291,6 +301,7 @@ enum flow_dissector_key_id {
FLOW_DISSECTOR_KEY_CT, /* struct flow_dissector_key_ct */
FLOW_DISSECTOR_KEY_HASH, /* struct flow_dissector_key_hash */
FLOW_DISSECTOR_KEY_NUM_OF_VLANS, /* struct
flow_dissector_key_num_of_vlans */
+   FLOW_DISSECTOR_KEY_PPPOE,  /* struct flow_dissector_key_pppoe */

FLOW_DISSECTOR_KEY_MAX,
 };
diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
index 6aee04f75e3e..42393af477a2 100644
--- a/net/core/flow_dissector.c
+++ b/net/core/flow_dissector.c
@@ -895,6 +895,39 @@ bool bpf_flow_dissect(struct bpf_prog *prog,
struct bpf_flow_dissector *ctx,
return result == BPF_OK;
 }

+/**
+ * is_ppp_proto_supported - checks if inner PPP protocol should be dissected
+ * @proto: protocol type (PPP proto field)
+ */
+static bool is_ppp_proto_supported(__be16 proto)
+{
+   switch (proto) {
+   case htons(PPP_AT):
+   case htons(PPP_IPX):
+   case htons(PPP_VJC_COMP):
+   case htons(PPP_VJC_UNCOMP):
+   case htons(PPP_MP):
+   case htons(PPP_COMPFRAG):
+   case htons(PPP_COMP):
+   case htons(PPP_MPLS_UC):
+   case htons(PPP_MPLS_MC):
+   case htons(PPP_IPCP):
+   case htons(PPP_ATCP):
+   case htons(PPP_IPXCP):
+   case htons(PPP_IPV6CP):
+   case htons(PPP_CCPFRAG):
+   case htons(PPP_MPLSCP):
+   case htons(PPP_LCP):
+   case htons(PPP_PAP):
+   case htons(PPP_LQR):
+   case htons(PPP_CHAP):
+   case htons(PPP_CBCP):
+   return true;
+   default:
+   return false;
+   }
+}
+
 /**
  * __skb_flow_dissect - extract the flow_keys struct and return it
  * @net: associated network namespace, derived from @skb if NULL
@@ -1221,19 +1254,29 @@ bool __skb_flow_dissect(const struct net *net,
}

nhoff += PPPOE_SES_HLEN;
-   switch (hdr->proto) {
-   case htons(PPP_IP):
+   if (hdr->proto == htons(PPP_IP)) {
proto = htons(ETH_P_IP);
fdret = FLOW_DISSECT_RET_PROTO_AGAIN;
-   break;
-   case htons(PPP_IPV6):
+   } else if (hdr->proto == htons(PPP_IPV6)) {
proto = htons(ETH_P_IPV6);
fdret = FLOW_DISSECT_RET_PROTO_AGAIN;
-   break;
-   default:
+   } else if (is_ppp_proto_supported(hdr->proto)) {
+   fdret = FLOW_DISSECT_RET_OUT_GOOD;
+   } else {
fdret = FLOW_DISSECT_RET_OUT_BAD;
break;
}
+
+   if (dissector_uses_key(flow_dissector,
+  FLOW_DISSECTOR_KEY_PPPOE)) {
+   struct flow_dissector_key_pppoe *key_pppoe;
+
+   key_pppoe = skb_flow_dissector_target(flow_dissector,
+
FLOW_DISSECTOR_KEY_PPPOE,
+ target_container);
+   key_pppoe->session_id = ntohs(hdr->hdr.sid);
+   key_pppoe->ppp_proto = hdr->proto;
+   }
break;
}
case htons(ETH_P_TIPC): {
--
2.35.1



-- 
FQ World 

Re: [Cake] [Starlink] How to help?

[Dave Taht via Cake]

On Mon, Jun 13, 2022 at 6:42 PM Dave Täht via Starlink
 wrote:
>
> We had a ton of email bounce last week.
>
> On Fri, Jun 10, 2022 at 10:21:55AM -0500, Nick Hall via Starlink wrote:
> > Hello,
> >
> > I've had a Starlink (the round version 1) for around a year and was
> > thinking about bufferbloat yesterday and just found your mailing list. I
> > just started looking at the archives but I'm gathering that you are looking
> > for people to test things and am wondering what I can do to help?
>
> yes.

At the moment...

I am mostly looking to get baseline tests from various vantage points,
w/o sqm. Starlink throughput is varying wildly
from multiple locations. The latency seems to vary as a function of a
fixed length fifo. Increasingly seems to vary at peak hours.
Running tests for 300 sec to be sure to see at least one sat change.

Script:

#!/bin/bash
T=dishy-nick # a unique name for your site, + options like sqm on or off.
# other servers are in ontario, de, atlanta, mumbai,london - if the
lasers go up testing those become interesting
# pick 2 close ones
for S in fremont.starlink.taht.net dallas.starlink.taht.net
do
flent -t $T --step-size=.05 --socket-stats -l 300 -H $S rrul_be
flent -t $T --step-size=.05 --socket-stats -l 300 -H $S rrul
for i in 1 4 16
do
flent -t $T-$i  --step-size=.05 --socket-stats -l 300
--te=upload_streams=$i -H $S  tcp_nup
flent -t $T-$i --step-size=.05 --socket-stats -l 300
--te=download_streams=$i -H $S tcp_ndown
done
done

# there's an interesting rtt_fair test here, keep these for a baseline
worlwide measurement

flent -x --socket-stats --step-size=.05 -H de.starlink.taht.net -H
london.starlink.taht.net -H singapore.starlink.taht.net -H
fremont.starlink.taht.net -t $T rtt_fair4be





> > I have used flent a little before, and only know the basics, but I can run
> > tests if you give me direction for what you need.
> >
> > I am not using the provided Starlink router but instead the dish is
> > connected directly to my EdgeRouter X which is running the 1.10 series
> > EdgeRouter firmware with Cake from
> > https://community.ui.com/questions/Cake-compiled-for-the-EdgeRouter-devices/fc1ff27c-f321-4344-8737-fcc755cae8a2
> >
> > I see a link to running CAKE with adaptive bandwidth:
> > https://forum.openwrt.org/t/cake-w-adaptive-bandwidth/108848
> >
> > But this is running OpenWrt. I know OpenWrt can run on the EdgeRouter X but
> > I can't spend the level of time to flash the router that it would probably
> > need right now. Do you know if that script would be able to run on the
> > version of Cake that I currently have running on the EdgeRouter X? Or have
> > necessary improvements been made to Cake that my version wouldn't have?
>
> So far as I know the edgerouter version of cake is pretty current.
>
> the script requires some things about timings that egerouter
> may not have.
>
> >
> > Thanks,
> >
> > Nick
>
> > ___
> > Starlink mailing list
> > starl...@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/starlink
>
>
> --
> Fixing the Internet on a too-tight budget: https://patreon.com/dtaht
> Dave Taht, Chief bottlewasher, TekLibre
>
> ___
> Starlink mailing list
> starl...@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink



--
FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

[Cake] DMARC policy change fix for lists.bufferbloat.net

[Dave Taht via Cake]

Over the past year or three the DMARC policy change to how mailing
lists were handled have been propagating across the net. I wasn't
paying attention. A lot of people have been auto-unsubscribed over the
last few months. I'm still working on improving the DMARC policy
here... and this is a test message of munging replies differently...

The bloat mailing list, which at its peak was above 550 people, is now
down to around 350, and for all I know the DMARC classifiers have been
tossing all the email that remains into your spam folders. If you've
been missing all the exciting, innovative debloating activity across
so many aspects of our project - the iab workshop last sept for
example, the new speedtest.net app, the improvements to wifi, news on
the latest broadband activities, etc, etc, our mailing list archives,
would be a good place to look to see when these problems really
started.

IF you have been missing emails from this domain, please contact me
privately so I can look over the logs. There's at least 3 different
behaviors happening - rejections, which is what I noticed, but 250
quarantine I had not, until today, and something that I cannot
describe, only curse at, as yet.

-- 
FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake