TCP has been around for so long that it is easy to forget just how much of the Internet depends on it. Web traffic, cloud applications, file transfers, databases and countless other services have relied on TCP for decades because it does a very good job of delivering data reliably and in the correct order. But there is a problem: the networks TCP was designed for are not necessarily the networks we are building today.
That is particularly true inside modern data centers. AI clusters can contain thousands of GPUs that need to exchange enormous amounts of data while simultaneously handling thousands of much smaller messages. A few milliseconds of additional latency might not sound like much when you are downloading a file, but when an expensive GPU is sitting idle waiting for another piece of information, those milliseconds can become very expensive. Stanford professor emeritus John Ousterhout is arguing that this is where a different transport protocol, called **Homa**, deserves a serious look.
TCP Was Designed Around a Different Problem
One of TCP's greatest strengths is also one of its limitations for some modern workloads: TCP presents data to applications as a continuous **byte stream**. The protocol is responsible for sequencing packets, retransmitting lost data, managing flow control and responding to network congestion.
That model works extremely well for many traditional applications. However, consider a busy AI data center where a server might simultaneously receive a huge model-data transfer and a tiny request containing information needed immediately by another GPU. TCP does not inherently understand that one piece of data may be much more urgent than another. The data is essentially part of the same stream.
This can contribute to latency problems. A short message can end up waiting behind larger transfers, particularly when the network is heavily utilized. TCP's congestion control also relies heavily on information coming back from the network, meaning the sender is making decisions based on what it can infer about congestion rather than having a complete picture of everything arriving at the receiver. Ousterhout's argument is that modern data centers need a transport protocol designed around these workloads rather than continually modifying TCP to make it do something it wasn't originally designed to do.
Enter Homa
Homa takes a very different approach. Instead of treating network traffic primarily as a byte stream, Homa is **message-based** and is designed around RPC-style communications. That distinction is important because the receiver knows the size of an incoming message and can therefore make more intelligent decisions about which traffic should be delivered first.
Homa also moves much of the congestion-control decision making to the **receiver**. Rather than having every sender independently attempt to determine how much traffic it should transmit, the receiver can effectively tell senders how much data they are allowed to send. Network priorities can then be used to favor shorter messages.
The basic idea is remarkably simple: if you have a 10 MB transfer and a 10 KB message competing for network resources, don't necessarily make the 10 KB message wait behind the 10 MB transfer. Get the small message through quickly and then continue processing the large transfer. In a heavily loaded AI cluster, that difference can be significant.
The Numbers Get Interesting
This isn't simply an academic argument about packet headers and protocol design. Homa has been implemented and tested in Linux.
In a 2021 USENIX evaluation using a 40-node cluster, Homa produced lower latency than both TCP and DCTCP across the tested message sizes. For short messages, the reported 99th-percentile tail latency was between **7 and 83 times lower** than TCP and DCTCP, depending on the workload.
More recent comparisons highlighted by Ousterhout are even more interesting. Under an example 100 Gbps network running at 80 percent utilization, Homa's reported 99th-percentile latency for short messages was approximately **92 microseconds**, compared with about **1.2 milliseconds for TCP**. That works out to roughly a 13-fold improvement in that particular test scenario. Homa also showed an advantage for longer messages.
Of course, benchmark numbers always need context. Network hardware, NICs, switch configuration, workloads, CPU overhead and software implementation can all affect the results. This is not a claim that installing Homa on a random office network is going to make your Internet connection 13 times faster.
So Is Homa the Next TCP?
Not exactly.
The important thing to understand is that Homa is aimed primarily at **data-center communications**, especially RPC-oriented workloads where latency matters. The current Homa specification explicitly says it is designed for environments with extremely low round-trip times and is not intended for high-latency WAN environments.
That distinction matters enormously.
Your home Internet connection, a connection between two offices across the country, or a web server communicating with customers around the world still has very different requirements from two servers sitting a few microseconds apart inside the same data center.
There are also already alternatives attacking individual TCP limitations. QUIC, for example, provides the foundation for HTTP/3 and addresses some problems associated with TCP's stream behavior. RDMA is widely used for specialized high-performance data-center workloads. DPDK can bypass portions of the traditional networking stack, while technologies such as DCTCP attempt to make TCP behave better under data-center congestion.
Homa is therefore better viewed as a **clean-sheet transport design for a particular class of networking problems**, rather than "TCP 2.0" for the entire Internet.
The Interesting Part: You Don't Have to Throw TCP Away
Perhaps the most practical aspect of Homa is that it does not require an organization to rip TCP out of its infrastructure overnight.
Homa can operate alongside TCP, allowing applications to be migrated incrementally. A Linux implementation exists as a kernel module, and Ousterhout is also working on getting Homa further integrated into Linux and developing an IETF standardization document.
That could be important if Homa eventually gains traction. Replacing TCP globally would be an almost unimaginable undertaking because TCP is embedded into operating systems, applications, network equipment and decades of infrastructure. Replacing it selectively inside environments where latency is extremely valuable is a much more realistic proposition.
And this is where the AI boom may give Homa its opportunity. AI data centers are pushing networking hardware harder than many traditional applications ever did. GPUs are incredibly expensive pieces of silicon, and having them sit around waiting for data is not exactly an efficient use of the electricity bill.
TCP has served the networking world extraordinarily well. The question isn't whether TCP is "bad." It isn't. The question is whether one transport protocol designed decades ago should continue to be the best answer for every networking problem. Homa's argument is that inside tomorrow's AI-heavy data centers, the answer may increasingly be **no**.
And if that happens, we may eventually look back at TCP the same way we look at 10BASE-T hubs today: an incredibly important technology that got us where we needed to go, but not necessarily the technology we want for the next generation of networks.
References
- The Register — Stanford prof is beating the drum for a new protocol to replace TCP — the article that prompted this discussion and includes the recent performance comparisons. The Register article
- USENIX — A Linux Kernel Implementation of the Homa Transport Protocol — excellent technical reference for the actual Linux implementation and 40-node testing. USENIX Homa/Linux technical paper
- Stanford/John Ousterhout — Homa publications and research — includes the original Homa research and Ousterhout's work on replacing TCP in data centers. John Ousterhout's Stanford publications
