We used to have this but it was lost during changes to our firewall
rules. We don't have an AAAA record for discuss.grapheneos.org to avoid
IPv6 connections but should also be explicitly blocking it. We're doing
this due to reliance on IP bans for registration to block spammers and
having IPv6 would greatly weaken it even if banning based on /64.
Based on the CAKE statistics during load testing, the latency benefits
of GSO splitting are minimal for our servers and the increased CPU usage
can increase latency.
This is needed for full network card functionality. It worked without it
and wasn't logging an error message previously so we didn't notice until
network bandwidth was being bottlenecked as part of rolling out our port
to Android 16 to our Stable channel.
BBRv1 provides much better throughput in many cases and is particularly
useful for our update servers. The fairness issues based on round trip
time are not a major issue for us. The fairness issues for competing
with traditional loss-based congestion control are relevant to us but it
seems to benefit it more than it hurts us. BBRv3 will fix most of this
while preserving nearly all the benefits and will likely be shipped as a
replacement for BBRv1 in the Linux kernel rather than another option.
The reason we rolled it back last time was seeing cases of the initial
bandwidth estimate being overly low combined with a very bad interaction
with synproxy causing low bandwidth initially. We've partially addressed
the synproxy issue by raising the synproxy threshold based on conntrack
table size which we're now fully scaling based on available memory. If
we decide this is still a significant issue, we can limit using BBRv1 to
our update servers where it has massive benefits and the least downside
due to initial bandwidth not being as important. BBRv3 will help with
this by probing Round Trip Time every 5 seconds instead of 10 seconds
but still has similar issues.
