[LibreQoS] libreqos vs a vs paraqum

[Dave Taht]

Paraqum was kind enough to put up a video of me playing "It GPLs me"
in their booth from WISPA, and I had a great talk with the CEO, who
I'm cc-ing on this.

https://www.linkedin.com/feed/update/urn:li:activity:6994997472536248320/

I was very impressed with their demo. They've already cracked 100Gbit!
I looked over their feature set this morning.

I (personally) have zero interest in dpdk and vpp. I don't want to
give up all the other nifty things a linux box can do by using it, so
I followed along on the xdp work - but I concede that these
technologies are probably always going to be faster than xdp, and
there are a ton of products deployed using it. I'd hoped someone would
fund open sourcing a fq_codel or cake implementation for it. (Same
goes for freebsd and pfsense which could use a native BQL + fq_codel
implementation. The BSD packet buffering scheme is really alien to
me). DPDK and vpp were born of the recognition that with conventional
processors, the bottleneck is more on the read side than the write
side, once you crack 10gbit.

I'm also not huge on tcp proxies, in part because they are tricky, and
in part because they mask the kinds of performance you actually get
out of newer protocols like QUIC. Even ack-suppression I'm of two
minds about.

Same goes for DPI, in general. But there are obviously folk that dig
this kind of feature too.

Not presently planning on doing DPI or TCP proxies in libreqos. (we
are however looking for suggestions for key features in the v1.4
release cycle:

https://github.com/LibreQoE/LibreQoS/discussions/133 # integrations
https://github.com/LibreQoE/LibreQoS/discussions/152 # Oses

I made a feature request while visiting paraqum. They have a nifty
feature of being able to track retransmits (I have no idea how), but
they aren't tracking ecn marks, which is a really amazing, latent
feature of cake and fq_codel we're seeing more and more of. I really
want all cake and fq_codel users to be tracking ecn marks!!

And overall, it's a huge market worldwide for various combinations of
shaping technologies and I wish them all the best, particularly in
APAC (I remember vividly supporting someone using our "arlan wireless
howto" in Sri Lanka back in 1999, not that I can remember who it was,
and kind of hope we helped spark the internet there, and also my
favorite vegetarian restaurant in santa cruz is sri lankan)

So in meandering through this pre-coffee email, I really really really
want to find ways so we can co-operate on standards like diffserv4,
work together with all the makers entering this field to improve
transports, ensure independent implementations of cake and fq_codel
are correct, improve benchmarking and graphing methods, and view the
common enemy, as the packet FIFO, not each other. It's a really huge
(set of) markets, and we're all in this bloat together.

Preseem, also, is a real pioneer in this market, they also do good
research, and if there is some way we can position libreqos, with our
"upstream first" philosophy, so that we continue doing good things all
across the stack, for everyone - and not go broke - for us to have a
natural niche in the evolving and expanding "lower latency internet"
ecosystem, I'd be really happy with that, too. I personally want to
keep working on making wifi fast, wifi6 and wifi7 need tons of love
that cannot be fully handled by a middlebox.

I think, but am unsure, Cambium's new QoE product smells like cake also.

I haven't had much communications with mikrotik, ever.

I think tarana is finally aware they have the bufferbloat problem (in spades).

ubnt has long had fq_codel in a ton of products (and even backports of
cake) but seem asleep at the switch. Some of their products are dpdk
(one otherwise excellent 802.11ad product that I know of), others,
don't know.



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