A Stanford prof wants to retire TCP, the protocol that runs the internet

John Ousterhout wants to retire TCP. The Stanford computer scientist is publicly making the case this month that the protocol at the bottom of nearly every web page, video call, and AI call was built for a traffic mix that no longer exists, and that the public internet needs a new foundation before AI-era traffic patterns harden around a worse one.

TCP, the Transmission Control Protocol, is the rulebook that lets two computers move a stream of bytes reliably across a network, retrying what gets lost and slowing down when the pipe clogs. It was specified in 1974, and most of what runs on the internet still depends on it. Ousterhout's argument, laid out in a recent Register piece and tied to his long-running research, is that the traffic shape TCP was tuned for, which is many small connections flowing one direction at a time, is mismatched to the workload that now dominates data centers: large AI training and inference jobs that need many machines to exchange a constant stream of short messages with very tight tail-latency budgets.

The replacement Ousterhout has spent years refining is Homa, originally published at SIGCOMM 2018 and now maintained as a Linux kernel module. Homa reorganizes transport around a simple inversion: instead of the sender deciding when to push bytes and the receiver acknowledging them, the receiver issues small "GRANT" packets that say "you may now send N more bytes at priority P." A switch-level priority queue then schedules the messages with the fewest bytes remaining first. The protocol synopsis lays out the design: request/response RPCs, receiver-issued grants, and shortest-remaining-bytes-first scheduling across priority queues.

In Ousterhout's own 2021 USENIX paper, a 40-node Homa/Linux benchmark reported lower latency than TCP and DCTCP across message sizes, and 7× to 83× lower 99th-percentile tail latency for short messages. Those are the author's benchmark numbers, on his own implementation, and the same paper flags two limits plainly: software overhead and imperfect load balancing across cores. The paper's claim of a further 5× to 10× potential gain is described as prospective, not achieved. No independent replication of those ratios is in the public record reviewed here.

The question it raises about who runs the next layer is bigger. If the next transport ships as an open standard, the next decade of internet capability stays legible to anyone who wants to build on it: researchers, smaller operators, public clouds, and sovereign stacks. If it ships as a vendor-owned stack, the same handful of companies that already sell the GPUs, NICs, and switches also own the rulebook their competitors and customers have to follow. Public module code, installation documentation, and preliminary gRPC integration are out now, and the README explicitly notes the API differs from TCP sockets. Code availability is not the same as drop-in compatibility, and production adoption is not established.

TCP is not a brittle museum piece; it carries decades of hardening for fairness, congestion control, and middlebox traversal, and replacing it at the bottom of the stack is not the same as fixing the AI-latency problem one layer up. Some of the work RDMA does inside hyperscale data centers is already doing part of what Homa proposes, and not every advocate of faster AI networking agrees the answer is a new public transport. The case for Homa is that the open-internet layer should not be left to vendor stacks, and that the public rulebook should be rewritten while the rewrite is still legible.

Ousterhout is making the argument in public this month, and the repository's recent notes track a working coexistence story with TCP on commodity hardware. Whether that argument lands as a standard or as a footnote will be decided by the operators, NIC vendors, and kernel maintainers who actually own the bottom of the stack.