Related projects and prior art¶
The idea of moving public TCP ownership away from an OpenVZ provider kernel predates linux-tcp-cc.
The closest prior art is the LKL + HAProxy family. linux-tcp-cc should therefore not be described as the first userspace BBR solution for OpenVZ.
LKL / OpenVZ lineage¶
tcp-nanqinlang/lkl-haproxy¶
tcp-nanqinlang/lkl-haproxy is an early OpenVZ-oriented LKL/HAProxy implementation and is now archived.
mzz2017/lkl-haproxy¶
mzz2017/lkl-haproxy packaged the LKL + HAProxy approach for common VPS distributions and BBRPlus.
nivrrex/lkl-bbr¶
nivrrex/lkl-bbr continues the OpenVZ/LKL direction with newer LKL and BBRPlus work. Its documented runtime uses liblkl-hijack.so, LD_PRELOAD, an LKL hijack configuration, TAP/iptables, and a proxy process.
nivrrex/lkl-proxy¶
nivrrex/lkl-proxy provides a small Rust Layer-4 proxy for that syscall-hijack environment and documents practical compatibility constraints around the hijacked runtime.
How linux-tcp-cc differs¶
The common observation is the same:
Congestion control belongs to the stack that owns the public TCP socket.
The operator/runtime boundary differs:
| Dimension | LKL hijack/proxy family | linux-tcp-cc |
|---|---|---|
| Public TCP owner | LKL stack used through syscall hijacking | hosted upstream Linux listener |
| Backend application | proxy/application participates in hijacked runtime | ordinary loopback application |
| LD_PRELOAD required for backend | typically part of the model | no |
| Packet boundary | commonly TAP/LKL setup | one nonpersistent L3 TUN |
| Service ownership | proxy + LKL integration | standalone native tcpcc supervisor |
| User mapping | proxy + LKL/network config | --forward LISTEN=BACKEND or TOML |
| Main semantic goal | depends on LKL/patch stack | preserve pinned upstream Linux TCP behavior |
This is not a claim that LKL is wrong. It is a different product boundary.
Other userspace TCP stacks¶
Projects that implement TCP themselves in userspace are also related, but solve a different problem.
For example, rustp2p/tcp_ip implements its own userspace TCP/IP stack and uses packetdrill for protocol qualification.
The maintainer's own tcp-shift uses lwIP and focuses on a much smaller endpoint with explicit RFC-oriented transport qualification.
linux-tcp-cc deliberately chooses hosted Linux instead because its main feature is preserving upstream Linux TCP ownership.
See Why upstream Linux.
Accurate project positioning¶
A concise description is:
linux-tcp-cc is a standalone TUN/DNAT front end that moves public TCP ownership into a hosted upstream Linux stack, allowing an ordinary loopback application to use Linux BBR/CUBIC even when the surrounding host kernel cannot provide or select that algorithm.
Avoid claims such as “first BBR on OpenVZ” or “identical to bare-metal Linux.”
The stronger claim is the combination of:
- upstream Linux TCP fidelity;
- a standalone native supervisor;
- an ordinary, non-hijacked backend application;
- versioned CLI/TOML configuration;
- IPv4/IPv6 and multi-listener support;
- memory/CPU/lifecycle qualification.
The canonical prior-art document is
docs/prior-art.md.