Why AI is forcing Ethernet to evolve

For years, networking has had a pretty good run. 

With Ethernet as the foundational protocol, we built faster switches, bigger fabrics, drove more bandwidth and more paths. And for the most part, the formula worked. If a packet flow of data landed on one path instead of another, nobody lost sleep over it. The network did its job and applications were happy. 

Then AI came along and changed the paradigm. Suddenly, assumptions that had served us well for decades did not work. When thousands of GPUs in a cluster need to be synchronized to train a model, the network stops being just a transportation system: it becomes part of the computer itself. 

In a cluster, every GPU is repeatedly waiting to receive memory exchanges from every other GPU. Every training step depends on synchronized communication. And in this world, previous approaches will not work. 

I sometimes compare it to an orchestra. You can have ninety-nine musicians playing perfectly, but if one section falls behind, everyone notices. AI infrastructure works the same way. One delayed flow. One congested path. One moment of imbalance. And suddenly thousands of GPUs are waiting instead of working. This not only has an impact on performance but more importantly has a severe economic impact due to the cost of power, cooling, and GPUs themselves. 

That is why AI networking has become one of the most interesting challenges in our industry. Not because Ethernet failed, but because AI is asking networks to do something, they were never originally designed to do.

AI didn't break Ethernet. It raised the bar

One of the biggest misconceptions in AI networking is that the challenge is bandwidth. Modern AI fabrics already deliver enormous bandwidth. In many deployments, there is more raw capacity available than ever before. Traditional load balancing was designed around probability. Spread traffic across multiple paths and trust the math. Statistically, that works beautifully. 

With AI, the real challenge is consistency and distribution. The problem is that AI clusters do not behave like traditional traffic. AI traffic is synchronized, more bursty with higher peaks, and highly sensitivity to latency and jitter. On top of all this, all of the GPUs are dependent on one another, so they all have to finish before they can start again. Thousands of GPUs often communicate with each other at the same moment, creating traffic patterns (i.e. elephant flows) that look very different from traditional cloud or enterprise applications. 

If the traditional methods are used, a single flow landing on an already congested path can slow an entire AI collective operation. A temporary hotspot can ripple across thousands of GPUs. At AI scale, tiny inefficiencies can quickly become million-dollar problems. That is exactly why Nokia sees Multipath Reliable Connection (MRC) as an important evolution in Ethernet transport.

Why MRC matters

At its core, MRC embraces a deceptively simple idea. AI traffic needs to be deterministically smoothed out more broadly across the network to increase the utilization of the network links. This can be done by deploying the following techniques: 

• Instead of using traditional per-flow load balancing use per-packet load balancing 
• Balance the traffic across a larger number of links by creating virtual data planes (i.e. multiplanes) 
• Program the network to be more deterministic in terms of where traffic goes so there is less variability and surprise. 

On paper, that sounds like a small adjustment. In practice, it can have a meaningful impact. MRC improves path utilization, helps smooth the impact of transient congestion since no single flow can overwhelm a small subset of the paths. If this is further enhanced by enabling faster congestion feedback to the source, then you have a system that is more closely aligned with the synchronized communication patterns of modern AI training and inferencing systems. 

In many ways, MRC feels like the next chapter in Ethernet's evolution. MRC, developed within the Open Compute Project (OCP),  is an evolution of RoCEv2, and can be implemented as a network upgrade to currently deployed network operating systems (NOSs) that already run RoCEv2. 

For decades, the industry has focused on building faster networks. AI is teaching us that speed alone is not enough. We also need traffic control and distribution mechanisms that help networks behave more efficiently under highly synchronized workloads. 

When AI training crosses physical boundaries

The story of AI training does not stop at a single location. 

In many larger AI deployments, AI training clusters that once lived inside a single server or rack have grown into scale-out leaf-spine fabrics connecting thousands of GPUs. Recently, scale-across architectures have emerged to address locations that have run out of space or power. In these cases, the AI cluster must be extended across different physical locations. However, the same GPU synchronization requirements remain the same, even if GPUs are now located across different locations. 

This is where the problem changes shape. 

For a GPU cluster contained in the same location, the focus is on efficiency and behavior under load. Technologies such as MRC help improve how traffic is distributed, making better use of available path diversity, and improving performance under highly synchronized AI workloads. 

But as soon as you distribute clusters across two or more locations, the challenge is no longer just optimization. It becomes coordination. 

At that point, the network must do more than move traffic efficiently. It must maintain consistency across locations, preserve visibility, and continue to ensure predictable behavior as infrastructure spans wider geographic and operational boundaries.  

This is where capabilities such as traffic engineering, network automation, and optical transport become essential. Combined with the SRv6-based architecture underpinning MRC, network intelligence is extended beyond the boundaries of a single location.

With its advanced AI-aware routing capabilities, MRC unifies the intelligence of the two locations to preserve the integrity of the GPU cluster despite it spanning multiple locations.

There is no single operating model for AI

One of the clearest lessons from early AI deployments is that there is no single way to build these systems and no single way to operate the underlying network elements or switches. 

Some organizations prefer Software for Open Networking in the Cloud (SONiC) for its openness and ecosystem flexibility. Others choose Nokia SR Linux for its operational consistency, integrated automation, and model-driven approach. Both approaches are being deployed at scale, and both are valid depending on operational philosophy and organizational requirements. 

At Nokia, we believe that customers should not be forced into a single operating model. Whether an AI fabric is built on SONiC or SR Linux, the goal is the same: provide a high-performance, resilient network that can scale efficiently to meet the growing demands of AI workloads.

Looking ahead

Every generation of computing forces networks to evolve. Cloud computing pushed us toward a massive scale. Virtualization transformed automation. The economics of compute extended networks to the edge. 

AI may be the biggest shift yet. For the first time, the network is not simply connecting applications. It is becoming an active participant in a distributed computing system where thousands of GPUs must operate as a coordinated whole. 

That changes the requirements. This is why MRC is attracting so much attention. It brings a fresh approach to how AI traffic is distributed across the fabric, helping improve path utilization, respond more effectively to transient congestion, and make better use of the path diversity already built into modern Ethernet networks.
 
From Nokia's perspective, that future is already taking shape. Many of the foundational capabilities required to support MRC-based architectures, including advanced load balancing, congestion management, streaming telemetry, SR Linux, SONiC-based deployments, SRv6 networking, and AI-ready switching platforms, are available today across the Nokia portfolio. 

In my next blog, I will describe the key features of MRC and how they work together to ensure that AI networking will never be the bottleneck, and AI will achieve its promise.