Like mentioned here already Way to have turris.omnia run like stock LEDE? I am hoping that when kernel 4.9+ arrives (TOS 4?) that it will feature support for TCP BBR
/etc/sysctl.conf
net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbrIt’s planned to use 4.14 kernel in Turris OS 4.0.
1 Like
Keep in mind that TCP BBR is made for servers not for routers so your mileage may vary with it while using it on a router.
1 Like
It is made for networks and not particularly for servers, nevermind that the router is a server anyway
Let me chime in, BBR will only affect TCP connections that terminate at the machine using BBR as its congestion avoidance algorithm, so if your Turris serves a lot of data BBR might make a difference for those flows, but if it mainly routes packets for machines connected to the Turris, BBR will not do anything for you. You will need to use BBR on all machines that serve content, so installing it on the Turris will not solve this for all internal machines. This is different from AQM which works nicely on intermediary nodes like a router; TCP is controlled from the endpoints, so all configuration also needs to happen at the endpoints.
It is made to help to alleviate users on busy, congested pipes. So unless your LAN is congested it won’t help you that much. Like I said, your mileage may vary 
Side-rant: a router is not a a server. It is a (small) device that transmits & receives information from network in a controlled manner. A server is a (large) storage device connected in network which delivers & receives user requests. Due to increased cpu power and the like, the two are converging, but were not there yet imo.
@moeller0 Then I am not understanding how google claims that TCP BBR is impoving throughput on their switches. Traffic is unlikely to terminate at switches.
Google’s B4 network is a high-speed WAN (wide-area network) built using commodity switches. Losses on these shallow-buffered switches result mostly from coincident arrivals of small traffic bursts. In 2015 Google started switching B4 production traffic from CUBIC to BBR. No issues or regressions were experienced, and since 2016 all B4 TCP traffic uses BBR. Figure 7 shows one reason for switching: BBR’s throughput is consistently 2 to 25 times greater than CUBIC’s
I read this to mean that google switched the TCP congestion control algorithm of those servers that are connected to their clients by the B4 network to use BBR on their traffic. As you state switches do not terminate traffic, so they can not directly run BBR…
I hope this clarifies things.
1 Like
Sure does. So basically any such congestion algo in the router is useless and only sqm (as available for TOS) makes sense. Is there a difference between aqm and sqm?
In essence yes, in reality it is bit more complex, as BBR on the router will still make traffic terminating on/from the router better behaved, so if you use your turris for serving data over TCP setting the congestion control algorithm might make sense, but for most users this will be rather insignificant as compared to the traffic through the router.
AQM is a generic akronym that decodes into advanced queue management (denoting something more refined than a simple fifo that will drop on ingress if overextended); sqm expands to smart queue management and this is marketing mostly 
sqm is just an aqm at heart (or rather a collection of those as sqm-scripts were designed to make changing the underlaying aqm easy)
1 Like