A reliable transport protocol for satellite-grade links — high RTT, real loss, asymmetric bandwidth — written in raw C on Linux, benchmarked against TCP and QUIC under emulated GEO and LEO conditions.
On a recent trip to SF I watched Project Hail Mary and Interstellar back-to-back, and between all the startup and AI talk floating around that city I caught myself wondering: huh — what does the AI x space tech landscape actually look like?
So I looked. And the honest answer is that the interesting part isn't the AI. The interesting part is that space is the one environment where you can't negotiate with the network. A GEO round trip is ~600 ms because of the speed of light, not because someone misconfigured a load balancer. LEO links drop mid-flow because the satellite you were talking to went over the horizon. Bandwidth is asymmetric because the downlink antenna is bigger than yours. Every assumption baked into TCP's congestion control — loss means congestion, RTT is stable, the path is persistent — is false here, by physics.
That makes satellite links the perfect adversarial testbed for transport
design: the failure modes are real, well-documented, and reproducible on a
laptop with two network namespaces and tc netem. No hardware, no hand-waving.
This project is me taking that testbed seriously — designing a wire protocol
for those conditions, implementing it close to the metal, and measuring
everything.
- A wire protocol designed for high bandwidth-delay product, non-congestive loss, and link handover: selective ACKs, pacing instead of loss-backoff, optional Reed–Solomon FEC, explicit session survival across path changes.
- A C implementation that treats the memory system as part of the design:
arena allocators for packet buffers, zero allocation on the hot path,
lock-free SPSC rings between the network and application threads,
sendmmsg/recvmmsgbatching. - A measurement harness: emulated GEO and LEO link profiles via
tc netemin paired network namespaces, with TCP CUBIC, BBR, and QUIC as baselines. Throughput, goodput under loss, and HDR-histogram tail latency, all pre-registered per phase before the numbers come in.
Following the same discipline as my previous measurement projects: each phase commits its methodology and expected axes before results, and results land in the repo whether they flatter the design or not.
| Phase | Question | Deliverable |
|---|---|---|
| 0 | Can I build a trustworthy link emulator? | netns + netem harness, validated RTT/loss/asymmetry profiles for GEO and LEO |
| 1 | How bad is the status quo, exactly? | TCP CUBIC / BBR / QUIC baselines across all link profiles |
| 2 | What does naive UDP buy you? | Unreliable UDP throughput ceiling — the upper bound to chase |
| 3 | Core protocol | SACK + pacing transport; goodput vs. Phase 1 under loss |
| 4 | FEC tradeoff | Reed–Solomon coding rate vs. retransmission under GEO RTT |
| 5 | Handover | Session survival across simulated LEO path switches |
- No actual satellites. The link profiles are the point, not the vehicles.
- No kernel bypass (DPDK/AF_XDP) until the syscall path is measurably the bottleneck. Claims of "zero-copy" require a flamegraph in evidence.
- No AI. That question got answered in the first paragraph.
Linux-only (netns, netem, sendmmsg). Developed on macOS via a Lima VM; the
harness sets up both namespaces and the emulated link with one script, so the
whole testbed is self-contained on one machine.
Phase 0: not started.