OCP Global Summit 2026 | OpenAI, Broadcom | Guohan Lu, Eric Spada | Multipath Reliable Connection (MRC)

4 days ago

7 min read

1. Why OpenAI and Broadcom Took the Stage Together

Classic RDMA RC (Reliable Connection) was designed for a world where the network rarely breaks. AI training clusters are the opposite: they are so large that something fails every day, and synchronous training runs at the speed of its slowest connection.

MRC started in early 2024, when the Ultra Ethernet Consortium (UEC) and several vendors were already studying multipath and packet spraying. OpenAI and Microsoft then approached vendors for an AI-specific multipath, multiplane transport that could survive link and fabric failures, with a design direction of 10⁶ nodes. The final members are AMD, Broadcom, Intel, Microsoft, NVIDIA and OpenAI; the specification is published as OCP MRC 1.0 and the API is on GitHub.

The division of labor was clear. Broadcom Distinguished Engineer Eric Spada, who describes himself as one of the principal authors of the OCP contribution, covered the protocol; OpenAI Member of Technical Staff Guohan Lu covered "the imperfect network we deal with every day." One brought the spec, the other brought the evidence.

2. Three Problems with RC: Pinned, Replay, Wait

The slides compress RC's limits at AI scale into three words:

Pinned: a QP hashes through 5-tuple ECMP onto a single path, leaving the other plane idle.
Replay: one lost packet triggers go-back-N, retransmitting everything already delivered behind it.
Wait: failure recovery depends on timeouts and routing convergence.

▲ Three limits of classic RC: one QP takes only one ECMP path, packet loss triggers go-back-N, and failures wait on timeouts and routing convergence (Image source: OpenAI, Broadcom | 2026 OCP Global Summit presentation)

Spada's addition is the key point: the larger the bandwidth-delay product, the more data in flight, and the more go-back-N wastes. As lane rates move from 400G to 800G and 1.6T, this problem only grows.

3. Inside MRC: Same Contract Above, New Machinery Below

MRC's design rule is "preserve above, rebuild below." Applications and collective libraries still see reliable delivery, ordered completions and the familiar QP/CQ model, and the API reuses libibverbs; all disorder stays below the API.

The machinery comes down to five verbs:

Spray: one QP attaches to two ports and two planes, and each packet picks its own entropy value (EV) to take a different path.
Bound: the responder advertises a maximum PSN range (MPR) that caps both sender and receiver state, so NIC memory does not blow up.
Recover: SACK tells the sender "only packet 12 is missing," so one packet is retransmitted instead of 12 through 15.
Control: congestion control and load balancing are decided at the sender.
Avoid: failed paths are simply removed.

Path selection comes in three forms: conventional ECMP hashing, a structured EV that encodes the route in packet fields, and SRv6 uSID, which encodes the whole path as IPv6 micro-segments. One line on the slides nails it: source routing does not make the routing protocol faster; it removes the endpoint's dependency on it. When a path degrades, the NIC just identifies, excludes and reselects, without waiting for network-wide convergence.

▲ MRC covers ECMP, structured EV and SRv6 uSID with a single entropy abstraction; when a path degrades the endpoint drops it and picks another without waiting for routing convergence (Image source: OpenAI, Broadcom | 2026 OCP Global Summit presentation)

A practical limit surfaced in Q&A: SRv6 encoded in a single IPv6 address tops out at six hops. The speaker said current deployments stay within six hops, and the protocol itself does not prevent future expansion. Two-tier networks fit easily, but going deeper would need a format change.

4. The Production Data: A T1 Switch Fails Silently

This is the most valuable part of the talk. Guohan Lu called it "a small job": 75,000 GPUs on a two-tier network. A T1 switch stopped forwarding, in the hardest form to handle, a gray failure: no error, no link down, just silently black-holing packets.

The slide numbers are below (the last three are STT readings of the page-13 chart):

Metric	Value
GPUs in the production job	75K
QPs affected	~25%
Packets dropped	~580K
Throughput baseline	~12.5 Pb/s (chart reading)
Sample at the failure minute	~10.5 Pb/s (chart reading)
Switch reboot	~12 min after failure (chart reading; speaker said ~10 min)

▲ One T1 switch fails: about 25% of QPs affected and about 580,000 packets lost, yet throughput dips at only one per-minute sample, and the job is still running when the switch reboots about 12 minutes later (Image source: Simple Tech Trend original; data from OpenAI, Broadcom 2026 OCP Global Summit presentation)

Two things matter when reading this chart. First, the ~16% dip is an artifact of minute-level sampling (STT estimate from the chart: 12.5 to 10.5 Pb/s); Guohan Lu said the real dip lasted milliseconds and the chart simply plots points per minute. Second, the real comparison is not how much throughput was lost but what the speaker said: without this transport, the job would stop and go back to a checkpoint. For a 75,000-GPU job, every return to a checkpoint means the whole cluster reruns together.

▲ A T1 switch fails completely during training and then reboots; throughput shows only a brief dip, with peak packet loss of about 0.00014% (STT reading of the chart) (Image source: OpenAI, Broadcom | 2026 OCP Global Summit presentation)

Another way to see it: 12.5 Pb/s divided by 75,000 GPUs is about 167 Gb/s of actual network throughput per GPU on average (STT estimate, based on the 12.5 Pb/s chart reading, not line rate). At this scale the network cannot "never break"; it can only "break without stopping."

5. Where the Intelligence Lives: MRC Bets on the NIC and Asks Little of the Switch

Spada stressed that MRC has very few hard requirements on switches, and ECN marking is one of them. ECN serves two purposes: adjusting the aggregate rate and correcting load-balancing bias. Packet trimming is optional: when a switch is about to drop a packet under congestion, it forwards only the header to the receiver, which immediately returns a NACK instead of waiting for a timeout, and lets the switch run with much smaller buffers.

▲ MRC puts spraying, pruning, selective retransmission, congestion control and path eviction in the NIC; the core switch requirement is ECN, with trimming and SRv6 optional (Image source: Simple Tech Trend original; data from OpenAI, Broadcom 2026 OCP Global Summit presentation)

There is a notable detail in congestion control. Spada said verbally that NSCC (Network Signaled Congestion Control) is the algorithm specified in the spec; the slide instead says "MRC standardizes interoperability signals, not one mandatory congestion-control algorithm," with NSCC "used in this implementation." The spec locks down the signal format carried in SACK, and leaves NIC vendors room to differentiate on how they react.

This contrasts with MetaRoCE, which Meta presented at the same summit: MetaRoCE asks switches only for ECN and ECMP, and its slides explicitly say no trimming. Both put the intelligence in the NIC; the difference is that MRC keeps two switch-assisted options, trimming and SRv6. The Ethernet camp's split in scale-out has narrowed from "multipath or not" to "how much the switch should cooperate." We covered Broadcom's Ethernet strategy in OCP APAC Summit 2026: Ethernet Starts Eating Scale-Up; MRC is the same logic applied to scale-out.

6. Risks and Counterarguments

No direct answer on whether trimming is on in production. When asked, Guohan Lu only said features are being rolled out to production gradually. The small-buffer benefit Spada cited comes from UEC data, not MRC production data.
The evidence rests on one event. The slides show a single T1 failure; data on plane-level failures, multiple simultaneous failures or mass optical flaps will have to come from OpenAI's published paper.
Source routing needs topology knowledge. MRC runs without a controller, but endpoints must hold the set of known-good paths; topology discovery and monitoring were left to another OpenAI talk.
It only solves scale-out network failures. MRC routes around path and plane failures; if the NIC itself dies, MRC cannot route around it (STT judgment, not discussed in the talk). Whether scale-up optics can tolerate link flaps is a separate question: Broadcom's OCP APAC Summit 2026: Broadcom's Third-Generation CPO Report Card offered component-level reliability data, but there is no matching protocol answer at the system level yet.
Six members do not mean six implementations. A public spec does not mean AMD, Intel and NVIDIA NICs already ship with MRC support, and the talk said nothing about interoperability testing.

7. What It Means for Taiwan's Supply Chain

The NIC gains strategic weight, which favors advanced process nodes. MRC puts path selection, retransmission and congestion control into the NIC. AMD, Broadcom, Intel and NVIDIA among the members are all NIC or switch-silicon suppliers, and Broadcom, NVIDIA and AMD networking chips are mainly manufactured by TSMC. The more complex the protocol, the more logic and SRAM the NIC needs.
Lighter switch requirements favor white-box switches. MRC asks little of the switch, and SRv6 spread through the open-source SONiC stack. Taiwanese networking ODMs focused on SONiC white-box switches face a lower bar; but the talk named no manufacturer, so nothing here says who wins OpenAI's orders.
Multiplane means more ports and optical modules, but looser fault-tolerance demands per link. One QP spans two planes with many paths in each, so the network can survive the loss of an entire T1. STT judgment: for scale-out optical modules, competition may tilt further toward cost and volume rather than extreme per-unit reliability; this logic does not apply to scale-up optics, and the talk itself did not discuss optical modules.

8. Conclusion

MRC's value lies in no single new mechanism; SACK, packet spraying and ECN congestion control are not new ideas. Its value is folding these mechanisms into one open specification co-signed by six companies, and showing with 75,000-GPU production data that "break without stopping" works.

Keep the timelines separate: spec 1.0 and the API are public, and OpenAI says it uses MRC daily; optional features such as trimming are still being phased in and are not confirmed on in production; there is no public data on deployments beyond OpenAI. Three things to watch over the next 12 months: trimming switched on in production and its results, production data from deployments beyond OpenAI, and interoperable implementations from at least three NICs. If all three land, MRC becomes the default transport for multiplane scale-out networks; if only the first does, it remains an internal practice of a few hyperscalers.

Networks will always break. MRC's bet is that teaching the NIC to route around failures is far cheaper than making switches that never fail.

This article is for technology and industry trend analysis only and does not constitute investment advice.