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 _______________________________________________ LibreQoS mailing list LibreQoS@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/libreqos
