Meta published MetaRoCE on Monday, August twenty fourth, 2026, a clean sheet RDMA transport for AI clusters running on ordinary Ethernet, and presented it the next day at its @Scale Networking conference. The design inverts the assumption every RoCEv2 deployment rests on. Instead of asking the fabric to be lossless with priority flow control, MetaRoCE treats the fabric as lossy, sprays packets across every available path out of order, and moves multipathing, loss recovery and congestion control into the NIC. Meta reports around 86 percent of throughput retained at 1 percent packet loss, and useful bandwidth still flowing at 10 percent. The specification goes to the Open Compute Project in October.
The short answer
Meta published MetaRoCE on August 24, 2026 and presented it at its @Scale Networking conference the following day. It is a multipath, out of order, receiver driven RDMA transport that pushes multipathing, loss recovery and congestion control into the NIC and removes the dependency on priority flow control. Meta reports about 86 percent of throughput at 1 percent loss and useful bandwidth at 10 percent, linear scaling across 4 plane and 8 plane topologies, and validation up to 4,000 concurrent connections on 64 node AMD GPU clusters. The specification, a DPDK reference implementation and a compliance framework go to the Open Compute Project in October 2026.
Anyone who has run RoCEv2 in anger has a priority flow control story. Usually it involves a pause storm, a fabric that went quiet in a region with no local fault, and a week spent tuning watchdogs. Meta's answer, published this week, is to stop asking Ethernet to be lossless at all.
The contract RoCEv2 asks the network to sign
RDMA over Converged Ethernet works by moving InfiniBand style semantics onto Ethernet, and it inherits an expectation along the way: frames arrive, and they arrive in order. Ethernet guarantees neither, so the industry bolted on priority flow control to fake losslessness. When a switch buffer fills, it sends a pause frame upstream and the sender stops.
That works. It also means congestion is contagious. A pause propagates backward through the fabric, so a hot spot in one place becomes head of line blocking somewhere unrelated, and in bad cases a pause storm or a credit deadlock removes a whole region from service. Operators end up with a lossless fabric that is fragile in a new and less obvious way.
The ordering requirement carries its own cost. To keep frames in sequence, a queue pair gets pinned to a single path. One large flow therefore gets one link, no matter how much parallel capacity the fabric has, and utilisation ends up hostage to hash collisions.
What Meta changed
MetaRoCE removes both assumptions at once, and the two removals depend on each other.
Every packet carries its own destination information, so a write can be placed correctly regardless of arrival order. Once that is true, ordering stops being something the network has to provide, and the sender can spray packets across every available path. Meta's own summary of the philosophy is that the fabric sees packets while the NIC sees intent.
With ordering gone, losslessness follows it out the door. Meta states that MetaRoCE treats the Ethernet fabric as lossy and does not ask it to be otherwise, no PFC and no pause frames. Loss is handled where transports have always handled it, at the endpoint. Congestion control becomes receiver driven, which is to say the side that can actually observe congestion is the side that meters the sender.
There is a latency dividend hiding in this. A transport that requires in order delivery needs a reorder buffer, and a reorder buffer is a place where packets wait. Removing the ordering requirement removes that wait, on top of removing the delay that PFC introduces.
The numbers, and what they mean operationally
Two figures do most of the work. MetaRoCE retains roughly 86 percent of throughput at 1 percent packet loss, and continues to deliver useful bandwidth at loss rates as high as 10 percent.
Read those against current practice. On a conventional RoCEv2 fabric, sustained loss well below 1 percent is an incident that people get paged for, because throughput falls off a cliff rather than degrading. Moving to a curve that bends gently instead of breaking changes what a marginal optic or a flapping link costs you. A degraded fabric becomes slower rather than broken, which for a training job measured in weeks is the difference between a bad afternoon and a restart.
The scaling claims are more conventional but still worth noting. Meta reports linear throughput scaling with plane count, validated on both 4 plane and 8 plane topologies, and multiplane testing with up to 4,000 concurrent connections. The protocol has been run on 64 node AMD GPU clusters using AMD programmable NICs, which matters because it shows the design is implementable on silicon Meta does not control. The stated target is million GPU scale, which is aspiration rather than measurement, though Meta already operates clusters of hundreds of thousands of GPUs spread across multiple data centres.
Why it is going to OCP, and why that part is the interesting bit
Meta plans to release three things at the Open Compute Project Global Summit in October 2026: the MetaRoCE specification, a DPDK optimised software reference implementation named libsoftmetaroce, and a production compliance framework built with Keysight.
The third item is the one that decides whether this becomes an industry protocol or a Meta internal detail with a blog post attached. RDMA interoperability has historically been where good specifications go to die, because two conforming implementations that have never been tested against each other tend not to interoperate. A conformance suite that runs from software reference through hardware emulation to production silicon is an unglamorous deliverable and the one that actually moves vendors.
It also lands in a busy year for AI fabric standards. AMD has been pushing 95 patches to get UALink into the Linux kernel, and switch silicon keeps climbing, with Spectrum 6 reaching 102.4 terabits per second. MetaRoCE aims at a different layer than either, but the direction is the same one: the fabric is no longer a commodity underneath the accelerators, it is part of the accelerator.
What to take from this if you are not Meta
Most readers will not deploy MetaRoCE. The transferable lesson is about where you put reliability.
RoCEv2 asks the network to be perfect and puts the endpoint at the mercy of that assumption. MetaRoCE assumes the network is imperfect and makes the endpoint responsible for coping. That is the same argument TCP won decades ago, arriving late to a corner of the data centre that had been allowed to skip it because InfiniBand semantics came with InfiniBand expectations.
The practical question to ask about your own fabric is simple. If a link starts dropping half a percent of frames tomorrow, does your RDMA traffic degrade or does it stop? If the honest answer is that it stops, the fragility is in the contract, not in the cable.
Sources and further reading
- MetaRoCE: A New RDMA Transport Built for AI Scale Ethernet, Engineering at Meta, August 24, 2026
- @Scale: Networking 2026 event programme, At Scale Conferences, August 25, 2026
- Meta's custom transport protocol embraces packet chaos to boost AI throughput, SDxCentral, August 2026
- Meta Designs MetaRoCE for Million GPU Ethernet AI Fabrics, Converge Digest, August 2026
Frequently asked questions
Why would anyone deliberately send packets out of order?
Because ordering is what forces RDMA traffic onto a single path, and a single path is what wastes a fabric. Classic RoCEv2 pins a queue pair to one route so frames arrive in sequence. That is comfortable for the NIC and terrible for utilisation: one elephant flow gets one link, hot spots form, and the rest of the cross sectional bandwidth sits idle. MetaRoCE removes the constraint by making every packet self describing, so each write carries its own destination. A packet that arrives third can still be placed correctly if it was sent first. Once ordering stops mattering, the sender is free to spray across every plane in the fabric, and utilisation stops depending on how lucky your hashing was.
What actually breaks when you remove priority flow control?
Nothing, if the transport was designed without it. Priority flow control exists to make Ethernet lossless by pausing upstream senders, and it is the single most operationally painful part of running RoCEv2 at scale. Pause frames propagate, so congestion in one corner becomes head of line blocking somewhere else, and in the worst case a pause storm or a deadlock takes out a region of the fabric that had no local problem. Tuning it is a specialist job that never really finishes. MetaRoCE says plainly that it treats the Ethernet fabric as lossy and does not ask it to be otherwise, no PFC and no pause frames, and instead handles loss the way transports normally do, with retransmission at the endpoint.
How much loss can it actually absorb?
Meta reports roughly 86 percent of throughput retained at 1 percent packet loss, and says the transport keeps delivering useful bandwidth at loss rates as high as 10 percent. Those are the numbers worth remembering, because they describe a completely different operating envelope from RoCEv2, where a fraction of a percent of loss is already a serious incident. It also changes what a fabric fault looks like. A degraded link stops being an outage and becomes a throughput reduction, which is a far easier thing to survive during a training run measured in weeks.
Can I use this today, or is it a Meta only protocol?
Not today, but the release plan is concrete rather than vague. At the Open Compute Project Global Summit in October 2026, Meta plans to publish the MetaRoCE specification, a DPDK optimised software reference implementation called libsoftmetaroce, and a production compliance framework built with Keysight that validates an implementation from software reference through hardware emulation to production silicon. Meta has already demonstrated the protocol on AMD programmable NICs and says other NIC implementations are underway. The compliance suite is the part to watch: a specification without a conformance test is a suggestion, and multi vendor RDMA has historically failed on exactly that gap.
What does this mean if I run a small or mid sized cluster?
Directly, not much yet. Indirectly, quite a lot, because the pressure that produced MetaRoCE is the same pressure shaping every AI fabric product you will be sold in the next two years. The concrete takeaway is architectural: if your RDMA deployment depends on PFC being tuned correctly, you are carrying an operational liability that the industry is actively trying to design away. Knowing why the largest operators decided losslessness was the wrong contract is useful the next time a vendor explains that their fabric just needs the right PFC watchdog settings.