A Stanford professor says TCP is done for AI clusters. The industry's real money is betting on something else.

At the AI Engineer conference, John Ousterhout, the Stanford professor emeritus who created RAMCloud and says he semi-retired specifically to work on this full time, argued that TCP is structurally wrong for modern AI clusters. AI workloads, he said, are shifting from a few huge data transfers toward a flood of small, latency-sensitive messages: inference calls, agentic coordination, cache lookups, barrier synchronization. TCP's byte-stream design has no concept of a message boundary, so it cannot prioritize a short, urgent message over a long one already in flight. His answer is Homa, a transport protocol he co-created that is message-aware by design. The architecture claim is real and well-supported. Two things the talk does not do are equally worth knowing: its specific benchmark numbers do not trace to any published source, and the industry's actual big-money response to this exact problem is coming from elsewhere entirely.

#What Homa actually is, and what holds up

Homa is not a talk-only concept. It is a real, peer-reviewed transport protocol from a 2018 SIGCOMM paper, "Homa: A Receiver-Driven Low-Latency Transport Protocol Using Network Priorities," with Ousterhout and three coauthors including Behnam Montazeri, whose dissertation the talk credits as the protocol's origin. That paper's own headline figure, measured on a 10 Gbps network at 80 percent load, was a 99th-percentile round-trip time under 15 microseconds for short messages, described at the time as almost 100 times lower than the best published comparable results.

The 2026 momentum is also real and independently checkable. A homa_qdisc queuing fix landed in January 2026 specifically to improve how Homa behaves when it has to coexist with TCP traffic. Homa was backported to Red Hat Enterprise Linux 8 and 9.5 in March 2026. It received an official IANA IP protocol number in October 2024, and mainline Linux kernel upstreaming began the same month, a process the project's own documentation describes honestly as incomplete and not yet performant in its earliest stages. This is a protocol still being actively built, not a finished product being marketed as one.

The genuinely non-obvious part, which the talk itself does not spell out this way, is the mechanism. Shortest-remaining-processing-time scheduling is decades-old queueing theory, provably optimal for minimizing average response time in a single-server queue, and almost never usable in real systems for one specific reason: a system usually cannot know how much work a job has left until it finishes. A message-based transport is one of the rare places where that precondition is actually met, because the full length of a message is known the instant its first packet arrives. TCP cannot supply this at all, because its byte-stream model has no message boundaries to measure in the first place. That is the real insight underneath Homa: not that message prioritization is a good idea, but that messages are one of the few real-world jobs where the theory's own hardest requirement is already satisfied for free.

#Where the talk's own numbers do not check out

The talk cites a specific chart claiming Homa's P99 tail latency for short messages is roughly 13 times faster than TCP, and nearly twice as good even on the longest messages. Neither figure could be matched to any published source. It is not the same number as the 2018 paper's own headline result, and it does not match the only other specific multiplier this research found, a 4x figure in the project's GitHub README describing how much Homa's own performance degrades when it has to share a network with TCP traffic without the January 2026 fix, a completely different comparison. The most likely explanation is that the talk is showing a newer, unpublished benchmark run on different hardware than the 2018 paper measured. That is plausible. It is also not verifiable from anything public this research could find, and a reader should treat the 13x and 2x figures as an unconfirmed conference-slide claim, not a citable result.

A related caution applies to Homa's own limitations. The project's public wiki does disclose real gaps: its own simulator assumes infinite buffer space and does not model packet drops or timeouts, and two third-party papers argue against it directly, one claiming Homa's buffer requirements exceed what modern switches can actually provide, another reporting its own transport beats Homa's tail latency by 99 percent in its own tests. What the wiki does not say, despite being an easy claim to reach for, is that Homa is unsuited to wide-area networks or fundamentally cannot coexist with TCP. Those specific claims are not on the page. They may turn out to be true elsewhere in Homa's documentation, but they are not confirmed anywhere this research found, and repeating them as settled would be citing a source for something it does not actually contain.

#What the talk never mentions

This is the part that changes the practical picture. Homa is not the industry's response to this problem. It is one lab's response, competing for attention against three much larger efforts, none of which the talk names.

Meta announced MetaRoCE in August 2026, its own clean-sheet RDMA transport built with AMD on Pensando NICs, aimed at million-GPU-scale clusters and released through the Open Compute Project for the rest of the industry to adopt. Meta's earlier engineering post already describe RoCEv2 handling the majority of its AI capacity at up to 129,000-GPU scale. The company running some of the largest AI infrastructure on Earth is evolving RDMA, not replacing it with a message-based clean-slate protocol.

At the same time, a nine-company standards consortium, the Ultra Ethernet Consortium, including AMD, Arista, Broadcom, Cisco, Eviden, HPE, Intel, Meta, and Microsoft, has shipped a UEC 1.0 specification and is building congestion-management standards specifically for AI and HPC networking through 2026. Google and NVIDIA separately co-engineered Falcon, a hardware-assisted low-latency transport presented at SIGCOMM 2025. Neither effort appears anywhere in the talk.

Zoom out one more layer and the market's actual attention is somewhere else again. Ethernet switches took roughly two-thirds of AI-cluster data-center switch sales in the first quarter of 2026, more than doubling year over year, up from InfiniBand's roughly 80 percent share of the AI back-end market in 2023. Homa does not appear in any market-share analysis found in this research. The live competitive battle, measured in actual dollars, is Ethernet against InfiniBand at the physical and vendor level, not one transport protocol against another.

#What an operator does with this

The architectural claim underneath the talk is correct and worth internalizing on its own terms: industry reporting consistently describes AI workloads producing more small, latency-sensitive traffic, though no single measurement study settles it, and a transport that can see message boundaries has a real structural advantage over one that cannot. Homa is a working, peer-reviewed proof that this problem is solvable, and its 2026 engineering progress, an IANA protocol number, an RHEL backport, active kernel upstreaming, is genuine, not vaporware.

But "a real solution exists" and "this is what you should build on" are different claims, and the talk does not distinguish them. If you are making an infrastructure bet based on this kind of talk, the honest picture is that the field's largest players are putting their money behind evolving what they already run (Meta's MetaRoCE) a multi-vendor Ethernet standard (Ultra Ethernet), or their own in-house hardware transports (Google and NVIDIA's Falcon), not toward adopting an academic kernel module that is, by its own maintainers' description, still mid-way through kernel upstreaming. Homa is evidence the direction is right. It is not yet evidence about which specific implementation the industry will actually run on at scale, and a talk that presents one lab's answer as the fix for an industry-wide problem, without naming the industry's own much larger competing bets, is not dishonest, but it is missing the half of the picture that would actually inform a decision.