This provides more redundancy for both services through having 2
instances in each region. The network services have much higher
bandwidth usage and load so this will also delay us needing to obtain
new servers by making better use of the ones we have.
These servers originally only had the 1Gbps base bandwidth and shaping
it with CAKE worked well to make the most of it during traffic spikes
for the web servers. It has little value for the nameservers since the
only potentially high throughput service is non-interactive SSH.
These servers now have 10Gbps burst available but are heavily limited by
their single virtual core and unable to use all of it in practice. CAKE
can only provide significant value when it's the bottleneck which isn't
the case when the workload is CPU limited. We don't want to keep around
the artificially low 1Gbps limit and it can't do much more.
Unlike OVH, the practical bottleneck is the CPU and FQ has the lowest
CPU usage in practice due to being very performance-oriented with a FIFO
fast path and offloading TCP pacing from the TCP stack to itself. On the
DNS servers, the fast path is always used in practice. Our OVH servers
have a much lower enforced bandwidth limit and the way they implement it
ruins fairness across flows. We definitely want to stick with CAKE for
our VPS instances on OVH but it doesn't make sense on BuyVM anymore.
This avoids setting outbound DSCP for echo-reply, TCP RST for TCP
sockets in the Time-Wait state and potentially other cases. We don't
want it to be possible for inbound packets to determine our outbound
traffic classification even to a small extent.
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.
