I posted this response in a different thread in hopes to catch the people following that one.
I know this is an old thread but I'd like to pick it back up. I work for a satellite operator and we suffer from long RTTs over the air. These RTT are more than 600ms most of the time and this had a severe impact on TCP flows and the "standard" CCAs like CUBIC. We have tested with BBR, and while it certainly performs better than CUBIC It still requires many TCP flows to fill a high capacity long latency sat link. We have tested with Hybla using a sat sim in the lab and have found that Hybla not only starts up quickly;y and achieves a large window but it also plays well with other competing flows. BBR has a tendency to become "lopsided".
Hybla is a module that comes with almost all Linux distros as Torvalds included it in 2004. I simply modprobed and added a few sysctl configurations and I was off to the races quite literally.
I saw a patch contributed some time ago but the contrubtor left a very vague message. I wish I would have picked up on that because I would have provided a lot of color. There are many whitepapers and studies to suppor the advantage of Hybla on sat networks.
I am not looking to replace the default CCA I just want the option to use Hybla. We have TCP PEPs in our network but they are built into the sat equipment. As soon as a VPN or any type of ecapsulation is introduced, the PEP is bypassed thus losing the advantage. Since we are terminating VPNs on a OpenWrt device we'd like to build the Proxy there.
We have the Proxy software that works in conjunction with iptables. We can build a LuCi app and uci configs for all of the proxy but none of it works without the proper TCP CCA.
Who do I need to convince this is worth the effort?
Yep 100%, we would like to have hybla congestion implemented, I have created a main Linux server with switch, Installed haproxy with shadowsocks and shadowvpn and used hybla, also you can use multiple congestions with " ip route", then used my server as gateway in my router. I tried ddwrt which has all congestion implemented but still network performance is terrible . hope it's implemented
We have built a similar setup using a Linux Server with FBF on a Juniper switch. We used PEPsal and iptables to achieve a transparent proxy that was passing 300Mbits per second with a single flow. We wouldn't expect to see these figures on a OpenWrt device, however, I ran a Linux variant on a RPi 3 with Hybla in the wee hours of the morning. I was able to achieve 200Mbits per second with an IPSec tunnel. This is double what my requirement is. We have even tossed around the idea of building a Hybla based proxy in the core and having an asymmetric CCA strategy but this only works in most residential applications. Work from home situations requirement a symmetric solution with VPN.
I'd like to keep the development going and build this into the main branch of OpenWrt. We have built a lot of automation tools and centralized management platforms for OpenWrt so using something different would be costly and painful.
Please add my response to your patchwork thread. Given that the entire planet will be covered by Geosynchronous satellite beams, It would be extremely beneficial to people to be able to build a TCP Proxy using OpenWrt. We certainly don't want to cut out the 3 billion people who could end up using satellite for Internet services.
