OpenVZ and constrained containers¶
OpenVZ-style VPS environments are the primary motivating deployment class for tcpcc.
The constraint¶
A tenant may be root inside the container and still share a provider-controlled kernel. Common consequences include an inability to:
- replace the provider kernel;
- load
tcp_bbr; - select the host's global TCP congestion-control algorithm;
- access some TCP-related sysctls.
At the same time, the container may still provide enough authority for TUN, netfilter, and forwarding. That is the gap tcpcc targets.
What must still be available¶
tcpcc cannot bypass every provider restriction. The deployment still needs:
/dev/net/tun;- appropriate network authority, normally including
CAP_NET_ADMIN; - a usable nftables/iptables path;
- IP forwarding for the public address family.
A provider that exposes TUN but permanently disables the relevant forwarding path is not compatible with the current TUN + DNAT design.
Published 128 MiB field observation¶
A real OpenVZ deployment from 2026-09-11 used:
| Property | Observation |
|---|---|
| vCPU | 1 |
| RAM | 128 MiB |
| Swap | none |
| Public path | IPv6 |
| Approximate RTT | 270 ms |
| Hosted RSS idle | ~6.1 MiB |
| Observed hosted RSS peak | ~17.6 MiB |
| Hosted RSS after flow | ~6.2 MiB |
| Supervisor RSS | ~2 MiB |
One complete BBR run reached 57.6 Mbit/s, but the public WAN later produced severe native and tcpcc outliers. It is therefore published as a field observation, not as a controlled speedup benchmark.
Canonical snapshot: