MRC (Multipath Reliable Connection)

Training a frontier model splits the work across tens or hundreds of thousands of GPUs that must exchange gradients in short, tightly synchronized bursts. In that setting the slowest link sets the pace: one congested path, or one cable that briefly drops (a "link flap"), can stall an entire training step and leave the whole cluster's GPUs idle. MRC — Multipath Reliable Connection — is a transport protocol designed to make that failure mode rare.

Conventional RDMA-over-Ethernet (RoCE) pins a connection to a single path and recovers from a lost path slowly, at connection granularity. MRC instead sprays the packets of one transfer across many paths at once. If a path congests or a link fails, the packets already in flight keep arriving over the other paths and the flow shifts away from the bad path in microseconds, without tearing down or restarting the connection. The receiving network card puts the packets back in order and still guarantees reliable, in-order delivery to the application.

MRC was published in May 2026 by OpenAI together with AMD, Broadcom, Intel, Microsoft, and NVIDIA, and contributed as an open specification through the Open Compute Project. It builds on RoCE and on work from the Ultra Ethernet Consortium, and adds SRv6 (IPv6 segment routing) so a sender can steer packets down chosen paths. It needs new 800 Gb/s-class network cards that implement it in hardware, but it runs over standard Ethernet switching rather than a proprietary interconnect.

You won't configure MRC as an agent developer — it lives in the datacenter fabric, several layers below anything an agent or an AGENTS.md file touches. It appears in this glossary because it is part of why 2026-era frontier models, and the coding and automation agents built on them, can be trained at all: cluster networking has become one of the main limits on model scale, and MRC is the most visible industry response.

How it works

A single logical connection is fanned out over a large set of equal-cost paths through the network. The sender assigns packets across those paths — "packet spraying" — rather than hashing the whole flow onto one. Because packets from one message now arrive out of order and from different directions, the endpoint NIC carries the reordering, loss detection, and retransmission logic that a single-path transport could otherwise leave to simpler in-order assumptions.

Path health is tracked continuously, and SRv6 source routing lets the sender express "use these hops," so a degraded link can be avoided immediately instead of waiting for the routing control plane to reconverge. The net effect is that congestion and link failures degrade throughput gradually and locally, instead of stalling a synchronized collective across the whole job.

Example

A training run on a 100,000-GPU cluster is midway through when a transceiver on one switch-to-switch link starts erroring and the link drops. Under single-path RoCE, every flow pinned to that link stalls, the GPUs waiting on those gradients sit idle, and the step time for the whole job spikes until routing recovers. Under MRC, the packets that were traversing that link are already being carried by the other paths of the same connection; the sender stops using the dead path within microseconds; step time barely moves and no job restarts.

How it differs

Common misconceptions

FAQ