Copy English

Why

A GPU that waits is the most expensive idle resource in computing, and in a synchronized training or inference step every GPU waits for the slowest message. When compute cycles were seconds long, a millisecond of network jitter was noise. Now that cycles are milliseconds, that same millisecond is the cycle, and one delayed metadata message stalls the whole cluster. The protocols carrying that message, TCP and RDMA over Converged Ethernet, optimise the wrong thing: they move big streams efficiently and treat a short message as just more bytes in the queue. Ousterhout's claim is that this is a design mismatch, not a tuning problem, and that a transport built around messages and receiver control cuts short-message tail latency by an order of magnitude on the same hardware.

How it works

The workload changed underneath the protocol

Training traffic was dominated by gradient exchange (02:25): gigabytes per step, connection setup cost amortised over huge transfers, bandwidth the metric that mattered, and TCP or RoCE good enough (02:39). Inference and agentic workloads flip this (03:16). The traffic is small and frequent: a lookup in a distributed KV cache, a barrier synchronization at the end of a compute step, scheduler and metadata chatter (03:37). None of it needs bandwidth. All of it needs to arrive on time, because the step cannot proceed until the last message lands (04:42). So the metric moves from mean latency to p99 tail latency, and the tail sets the effective throughput of the cluster (04:10).

Where TCP and RDMA lose the tail

The talk names three mechanisms, all structural:

• Incast and queue build-up. Many senders fire at one receiver at once, packets pile up in the egress buffer of the top-of-rack switch (06:29), a short message lands behind that pile and either waits or is dropped and retransmitted (06:43). A retransmission timeout is milliseconds; the whole compute step was milliseconds.
• Sender-driven congestion control. TCP and DCQCN-style RDMA learn about congestion after the fact, through ECN marks or loss, and then slow down. The feedback loop has a control lag, so it never quite converges and the rate oscillates (08:16). The sender is the wrong party to decide: it cannot see the receiver's downlink, which is where the congestion actually is.
• Byte streams and head-of-line blocking. TCP and RDMA carry byte streams with no notion of where one message ends and the next begins (10:11). A transport that cannot see message boundaries cannot prioritise a short message, so it sits behind a long transfer in the same stream.

Homa's three design decisions

Homa was designed from scratch for datacenter traffic (11:16), originally at Stanford (SIGCOMM 2018), and the talk describes three choices:

1. Messages and RPCs, not streams (12:30). Each request and each response is an independent message, and the first packet carries the total length. That lets the network run SRPT, shortest remaining processing time first: a short message can overtake a long one because everyone knows how much of each is left (13:02).
2. Receiver-driven congestion control (13:37). The receiver owns its downlink, the one place congestion happens. A sender may transmit only the first part of a message immediately, the unscheduled packets; the rest, the scheduled packets, go out only as the receiver issues grant packets (14:10). The receiver hands out grants to the messages with the least remaining, so switch buffers never fill in the first place (14:36).
3. Switch priority queues (15:01). Modern switches have several egress queues per port. Homa puts long-message traffic in low-priority queues and short messages in high-priority ones, so a short message is forwarded ahead of bulk traffic it would otherwise queue behind.

Numbers and status

On a mixed workload of 50-byte to 1 MB messages, the p99 latency of short messages fell from over 1 ms on TCP to under 100 µs on Homa, roughly 13 times (16:50); large messages also ran about twice as fast, which the talk credits to Homa's run-to-completion processing model (17:07). Homa exists as an open-source Linux kernel module on GitHub, and Ousterhout is working toward upstreaming it (12:09). His closing advice: if short-message latency is your cluster's bottleneck, try it (17:52).

Where it lands in Jayverse

• Verex: the matching path is a tail-latency problem, not a throughput one. Order placement, cancel and fill notifications are small messages; the user-visible failure is the slowest one, not the average. Measure p99 on the CLOB round trip and on the fill notification, and put it next to the mean in the metrics page.
• Rabbit relayer and devnet RPC: let the receiver pace the sender. The bridge relayer and the Anvil RPC both suffer incast when a burst of requests arrives; a receiver-side queue that serves short requests first (health checks, nonce reads) before long ones (log scans, traces) is Homa's SRPT idea at application level, and it needs no new protocol.
• Auditor: "which percentile" is part of the rule. A latency check that names only a mean is unverifiable in the sense that matters here; every latency rule the Auditor records should state the percentile and the window.
• Theory: SRPT and receiver-driven flow control are scheduling theory. SRPT is optimal for mean response time in a single queue; the item is a live example for the queueing and scheduling entries in Theory, and for the game-theory note on why a sender cannot be trusted to slow itself down.

Verified and unverified

Verified on 2026-09-19: Homa is a real receiver-driven, message-based datacenter transport from Ousterhout's group at Stanford (paper Homa: A Receiver-Driven Low-Latency Transport Protocol Using Network Priorities, SIGCOMM 2018), and an open-source Linux kernel module exists on GitHub under Stanford's PlatformLab; the design points above (SRPT, unscheduled and scheduled packets, grants, priority queues) match the published design. Taken from the talk summary and not independently checked: the 13-times p99 figure and the two-times large-message figure for this particular benchmark, the exact timestamps, and the current state of the upstreaming effort. The talk's date is not given in the summary.

Sources: YouTube — John Ousterhout on Homa and AI cluster networking · Montazeri, Li, Alizadeh, Ousterhout, Homa, SIGCOMM 2018 · PlatformLab/HomaModule on GitHub · related items: Tech #62 (agentic engineering writes the boundaries), Theory scheduling notes.

← All Knowledge Notes · Workspace Index · Top ↑

Copy 한국어

Homa — AI 클러스터의 병목이 짧은 메시지라면, 네트워크는 수신자가 운전해야 한다

스탠퍼드 명예교수이자 Tcl과 *A Philosophy of Software Design*의 저자인 존 오스터하우트(John Ousterhout)가 약 18분의 강연(YouTube)에서 TCP와 RDMA가 왜 AI 클러스터의 병목이 되는지, 그리고 자신의 전송 프로토콜 Homa가 무엇을 다르게 하는지 설명한다. 주장은 한 줄이다. AI 트래픽은 예전에는 대역폭이 중요한 기가바이트 단위 전송 몇 개였고, 지금은 가장 느린 1퍼센트가 중요한 수백만 개의 작은 조정 메시지로 바뀌고 있다. TCP와 RDMA는 첫 번째 세계를 위해 만들어졌다. Homa는 두 번째 세계를 위한 백지 설계다. 바이트 스트림 대신 메시지, 송신자 대신 수신자가 누가 보낼지 결정, 그리고 50바이트 메시지가 1메가바이트 뒤에서 기다리지 않게 하는 스위치 우선순위 큐.

Jayverse에서 이것은 배포할 프로토콜이 아니라, 우리가 가진 모든 지연 문제를 읽는 방법이다. Verex 매칭 경로, Rabbit 릴레이어, 데브넷 RPC. 교훈은 평균은 아무것도 말해 주지 않고 꼬리가 처리량을 결정하며, 해법은 대개 수신자에게 제어권을 주고 짧은 일이 긴 일을 추월하게 하는 것이라는 점이다.

왜

기다리는 GPU는 컴퓨팅에서 가장 비싼 유휴 자원이고, 동기화된 학습·추론 단계에서는 모든 GPU가 가장 느린 메시지를 기다린다. 연산 주기가 초 단위였을 때 네트워크 지터 1밀리초는 잡음이었다. 주기가 밀리초가 된 지금 그 1밀리초가 곧 주기이고, 지연된 메타데이터 메시지 하나가 클러스터 전체를 멈춘다. 그 메시지를 나르는 프로토콜, TCP와 RoCE(RDMA over Converged Ethernet)는 잘못된 것을 최적화한다. 큰 스트림을 효율적으로 옮기고 짧은 메시지를 큐 속의 바이트 몇 개로 취급한다. 오스터하우트의 주장은 이것이 튜닝 문제가 아니라 설계 불일치이며, 메시지와 수신자 제어를 중심으로 만든 전송이 같은 하드웨어에서 짧은 메시지의 꼬리 지연을 한 자릿수 배 줄인다는 것이다.

동작 방식

프로토콜 아래에서 워크로드가 바뀌었다

학습 트래픽은 그레이디언트 교환이 지배했다(02:25). 단계마다 기가바이트, 거대한 전송에 분산되는 연결 설정 비용, 중요한 지표는 대역폭, TCP나 RoCE로 충분(02:39). 추론과 에이전트 워크로드는 이것을 뒤집는다(03:16). 트래픽은 작고 빈번하다. 분산 KV 캐시 조회, 연산 단계 끝의 배리어 동기화, 스케줄러와 메타데이터 잡담(03:37). 어느 것도 대역폭이 필요하지 않다. 전부 정시에 도착해야 한다. 마지막 메시지가 도착하기 전까지 단계가 진행될 수 없기 때문이다(04:42). 그래서 지표가 평균 지연에서 p99 꼬리 지연으로 옮겨가고, 꼬리가 클러스터의 실효 처리량을 정한다(04:10).

TCP와 RDMA가 꼬리를 잃는 곳

강연은 세 가지 메커니즘을 꼽고, 모두 구조적이다.

• 인캐스트와 큐 적체. 여러 송신자가 한 수신자에게 동시에 쏘면 ToR(top-of-rack) 스위치의 이그레스 버퍼에 패킷이 쌓이고(06:29), 짧은 메시지가 그 더미 뒤에 떨어져 기다리거나 유실 후 재전송된다(06:43). 재전송 타임아웃은 밀리초 단위인데 연산 단계 전체가 밀리초였다.
• 송신자 주도 혼잡 제어. TCP와 DCQCN 계열 RDMA는 ECN 표시나 손실을 통해 혼잡을 사후에 알고 나서 속도를 줄인다. 피드백 루프에 제어 시차가 있어 결코 완전히 수렴하지 못하고 속도가 진동한다(08:16). 송신자는 결정할 당사자로서 틀렸다. 혼잡이 실제로 있는 곳인 수신자의 다운링크를 볼 수 없다.
• 바이트 스트림과 HOL(head-of-line) 블로킹. TCP와 RDMA는 한 메시지가 어디서 끝나고 다음이 어디서 시작하는지 모르는 바이트 스트림을 나른다(10:11). 메시지 경계를 볼 수 없는 전송은 짧은 메시지를 우선할 수 없으니, 같은 스트림의 긴 전송 뒤에 앉아 있게 된다.

Homa의 세 가지 설계 결정

Homa는 데이터센터 트래픽을 위해 처음부터 설계되었고(11:16), 원래 스탠퍼드에서 나왔다(SIGCOMM 2018). 강연은 세 가지 선택을 설명한다.

1. 스트림이 아닌 메시지와 RPC(12:30). 각 요청과 각 응답은 독립된 메시지이고 첫 패킷이 전체 길이를 나른다. 그래서 네트워크가 SRPT, 잔여 처리 시간이 가장 짧은 것 먼저를 돌릴 수 있다. 각 메시지가 얼마나 남았는지 모두 알기 때문에 짧은 메시지가 긴 것을 추월한다(13:02).
2. 수신자 주도 혼잡 제어(13:37). 수신자가 혼잡이 일어나는 단 하나의 장소인 자기 다운링크를 소유한다. 송신자는 메시지 앞부분, unscheduled 패킷만 즉시 보낼 수 있고, 나머지 scheduled 패킷은 수신자가 grant 패킷을 발행할 때만 나간다(14:10). 수신자는 잔여량이 가장 적은 메시지에 grant를 주므로 스위치 버퍼가 처음부터 차지 않는다(14:36).
3. 스위치 우선순위 큐(15:01). 현대 스위치는 포트마다 이그레스 큐가 여러 개다. Homa는 긴 메시지 트래픽을 낮은 우선순위 큐에, 짧은 메시지를 높은 우선순위 큐에 넣어, 짧은 메시지가 원래는 뒤에 줄 서야 했을 대량 트래픽보다 먼저 전달되게 한다.

숫자와 현황

50바이트에서 1MB까지 섞인 워크로드에서 짧은 메시지의 p99 지연이 TCP의 1ms 이상에서 Homa의 100µs 미만으로, 약 13배 줄었다(16:50). 큰 메시지도 약 2배 빨랐고, 강연은 이를 Homa의 run-to-completion 처리 모델 덕으로 돌린다(17:07). Homa는 GitHub에 오픈소스 리눅스 커널 모듈로 존재하고, 오스터하우트는 업스트림 병합을 진행 중이다(12:09). 마무리 조언: 짧은 메시지 지연이 클러스터의 병목이라면 써 보라(17:52).

Jayverse에서의 위치

• Verex: 매칭 경로는 처리량이 아니라 꼬리 지연 문제다. 주문 제출, 취소, 체결 알림은 작은 메시지이고, 사용자가 보는 실패는 평균이 아니라 가장 느린 하나다. CLOB 왕복과 체결 알림의 p99를 측정해 메트릭 페이지에서 평균 옆에 두라.
• Rabbit 릴레이어와 데브넷 RPC: 수신자가 송신자의 속도를 정하게 하라. 브리지 릴레이어와 Anvil RPC는 요청이 몰릴 때 인캐스트를 겪는다. 짧은 요청(헬스체크, nonce 읽기)을 긴 요청(로그 스캔, 트레이스)보다 먼저 처리하는 수신자 측 큐는 애플리케이션 수준의 Homa SRPT이고, 새 프로토콜이 필요 없다.
• Auditor: "어느 백분위수인지"가 규칙의 일부다. 평균만 말하는 지연 검사는 여기서 중요한 의미로 검증 불가능하다. Auditor가 기록하는 모든 지연 규칙은 백분위수와 창을 명시해야 한다.
• Theory: SRPT와 수신자 주도 흐름 제어는 스케줄링 이론이다. SRPT는 단일 큐에서 평균 응답 시간에 최적이다. 이 항목은 Theory의 큐잉·스케줄링 항목과, 송신자가 스스로 속도를 줄이리라 믿을 수 없는 이유를 다루는 게임이론 노트의 살아 있는 예다.

확인된 것과 미확인

2026-09-19 확인: Homa는 오스터하우트 그룹(스탠퍼드)의 실제 수신자 주도·메시지 기반 데이터센터 전송이고(논문 Homa: A Receiver-Driven Low-Latency Transport Protocol Using Network Priorities, SIGCOMM 2018), 스탠퍼드 PlatformLab의 GitHub에 오픈소스 리눅스 커널 모듈이 있으며, 위의 설계 요점(SRPT, unscheduled·scheduled 패킷, grant, 우선순위 큐)은 발표된 설계와 일치한다. 강연 요약에서 가져왔고 독립 확인하지 않은 것: 이 벤치마크의 13배 p99 수치와 큰 메시지 2배 수치, 정확한 타임스탬프, 업스트림 작업의 현재 상태. 강연 날짜는 요약에 없다.

출처: YouTube — 존 오스터하우트, Homa와 AI 클러스터 네트워킹 · Montazeri, Li, Alizadeh, Ousterhout, Homa, SIGCOMM 2018 · GitHub PlatformLab/HomaModule · 관련 항목: Tech #62(에이전틱 엔지니어링은 경계를 쓴다), Theory 스케줄링 노트.

← 전체 기술 노트 · 워크스페이스 인덱스 · 맨 위 ↑