Hi,
It's posible to implement TCP Hybla in OpenWRT 18.06.2 without building an own version?
I am using AR150 gl inet router. I am using bbr congestion control but I want to use Hybla if it is possible.
Thanks,
Just to make this clear for other's stumbling over this thread; in TCP congestion control is exercised by the end-points, so unless one terminates traffic on the router by either running services (like a web-server or a proxy) on the router or by terminating a VPN tunnel using TCP (see *) the congestion control algorithm used by the router will have very little influence on the performance.
*) Using TCP connections to operate VPNs on is not ideal, as the outer layers retransmission logic can cause terrible latency in the tunneled connections, so if possible UDP seems a better "carrier".
2 Likes
Hybla, as I understand it, is intended to resolve some specific issues with satellite links.
Also, for others in search of the next magic solution, at least when they tested in in 2012, Cloudflare didn't find much value
While other Congestion Control Algorithms may seem like performance wins on connections experiencing high amounts of loss (>.1%) (e.g., TCP Westwood+ or Hybla), unfortunately these algorithms don't include HyStart. The net effect is that, in our tests, they underperform CUBIC for general network performance. Unless a majority of your clients are on lossy connections, I recommend staying with CUBIC.
Edit
https://www.vultr.com/docs/how-to-setup-tcp-optimization-on-linux may have some clues. I haven't checked for the presence of a pre-built module, as I'm guessing you've already checked for your platform.
1 Like
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?
1 Like
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.