Additional TCP Congestion Control Algorithms
-
Currently I am loading the cc_htcp.ko module and manually changing the default net.inet.tcp.cc.algorithm from newreno -> htcp
Can we add additional TCP Congestion Control Algorithms to the pfSense kernel?
I have had no issues using HTCP using 2.3.3 or 2.3.2. Thanks!
Current Kernel:
[2.3.3-DEVELOPMENT][root@pfSense.lan]/root/scripts: sysctl net.inet.tcp.cc.available net.inet.tcp.cc.available: newrenoI have a manual script to make sure /boot/modules/cc_htcp.ko exists after upgrades, etc.
Manually added cc_htcp.ko module:
[2.3.3-DEVELOPMENT][root@pfSense.lan]/root/scripts: sysctl net.inet.tcp.cc.available net.inet.tcp.cc.available: newreno, htcpI have attached some TCP Congestion Kernel Modules from the FreeBSD AMD64 10.3 Release ISO for anyone that would like to manually load these into /boot/modules and load them via /boot/loader.conf.local
-
+1 for this
-
You realize that does nothing in most people's use cases, right? That's only applicable to any traffic initiated by the firewall itself, not to traffic passing through it. Outside of circumstances like squid, that's very little of your traffic.
Still wouldn't hurt to add, maybe someone can get that added.
-
@cmb:
You realize that does nothing in most people's use cases, right? That's only applicable to any traffic initiated by the firewall itself, not to traffic passing through it. Outside of circumstances like squid, that's very little of your traffic.
Still wouldn't hurt to add, maybe someone can get that added.
Agreed…. thanks CMB
-
In other words, TCP algorithms only affect the end-points, not the hops.
-
Would additional TCP algos be useful when using pfSense as a VPN server? Is pfSense not acting as an end-point in that scenerio?
-
Would additional TCP algos be useful when using pfSense as a VPN server? Is pfSense not acting as an end-point in that scenerio?
Only if the VPN itself was using TCP, which it would not be if you cared about performance. Otherwise it's still just passing packets.
