Can Homa and TCP Get Along?#
Netdev 0x1A (Rome, 13-16 July 2026) digest Program Core pick Rome · 13–16 July 2026
John Ousterhout
Why: Coexistence is the actual adoption blocker for any new datacenter transport. Nobody gets a greenfield fabric, so "what happens when it shares a NIC with TCP" decides whether Homa is deployable at all.
What: Measurements of TCP and Homa running concurrently, plus homa_qdisc, a new queuing discipline that fixes the resulting unfairness — and, notably, improves plain TCP too.
How: Baseline finding: running together, TCP gets slightly better (Homa reduces buffer utilization) while Homa degrades badly (TCP still overloads buffers). homa_qdisc paces output for both protocols to prevent NIC queue buildup, implements Homa's SRPT policy plus a limited SRPT for TCP, and balances output between the two under congestion. With it, Homa suffers only slight degradation alongside TCP, TCP latency improves over the no-qdisc case, and TCP-only short-message tail latency improves by nearly 2x versus fq_codel. (From abstract only.)
Where applicable: General Linux hosts — this is a qdisc, not a fabric requirement. Homa itself still wants switch priority queues; the fq_codel tail-latency result is interesting independently of whether you ever run Homa.
