I have worked with enterprise networks for a long time, and over the past few years one contradiction has become increasingly obvious: WAN technology has evolved much faster than the way carrier services are purchased, measured, and protected by SLAs. Is the traditional WAN SLA becoming obsolete? Is it Time to rethink the Traditional WAN SLA?

In the Private WAN (MPLS) era, the model was relatively straightforward. An enterprise purchased a private WAN from a carrier, defined the required capacities, built redundancy where necessary, and agreed on an availability SLA such as 99.9% or 99.99%, together with repair times. Behind all this was a strong assumption: “Private MPLS provides better quality than the Internet.”

The WAN SLA did not actually prove the assumed quality difference

There were sound technical reasons for this assumption. The carrier controlled its backbone, capacity, routing, and traffic classes. The Internet, by contrast, was a best-effort network whose end-to-end quality was not controlled by any single party. But from the customer’s perspective, there was always one problem: The SLA did not actually prove the assumed quality difference. A typical SLA primarily told you whether the connection was available and how quickly it would be repaired. Packet loss, jitter, and latency were not consistently guaranteed across the customer’s actual end-to-end service path.

Availability is not the same as quality.

A connection with 99.99% availability can still be a poor WAN connection. It may be “green” — up — while performing badly in practice. Ethernet works. IP works. BGP works. The carrier’s monitoring dashboard is green. BUT at the same time, packet loss may be several percent, jitter may be high, or the network may be congested. A Teams call breaks up, SaaS applications become sluggish, and users experience an unstable connection. Yet the carrier’s availability report may still show practically 100%.

In that situation, it is reasonable to ask: Is it time to rethink the traditional WAN SLA?

Traditional vs. modern WAN

This highlights what I believe is one of the fundamental differences between traditional and modern WAN thinking. Availability tells us how long a connection was down. It does not tell us how long the connection should not have been used because of poor quality

Modern WAN technology can see the difference. What if BGP is down while the circuit itself remains up? Even a simple routing failure demonstrates the weakness of availability-centric thinking. The physical fiber may be fine. The carrier’s access service is up. Ethernet works. But the BGP session disappears, and the required routes disappear with it.

Is the service still available? The carrier’s access circuit may still be up, while from the customer’s perspective the connection has virtually no value. So what exactly does availability measure?  The physical link? The CPE? The BGP session? IP reachability? Or whether the user can actually access the business application? The closer we get to the last question, the less useful a single availability percentage becomes in describing reality.

Modern WAN changes the question

In my view, the most important innovation in modern WAN is not AI. The more fundamental change is the shift from availability-based networking → quality-based networking. A modern WAN can continuously monitor packet loss, latency, jitter, and reachability across multiple paths.

If a path no longer meets the requirements for a particular application or traffic class, the network is not required to continue using it. Traffic can be moved to another Internet connection, a mobile connection, or even satellite connectivity. The network no longer has to wait until it can declare: “The connection is dead.”  Instead, an intelligent WAN can say: “The connection still exists, but it is no longer good enough to use.” That is a much bigger change than simply buying a new router.

MPLS quality becomes a measurable claim rather than an assumption

For years, the superior quality of MPLS was treated almost as self-evident. Yet Skype demonstrated something interesting roughly 20 years ago: real-time voice could work over the best-effort Internet between Finland and the United States without carrier-provided end-to-end QoS. The Internet was not perfect. The application simply learned to operate over an imperfect network. Codecs, jitter buffers, packet-loss concealment, and other application-level mechanisms made it possible.

Modern WANs apply a similar principle at the network layer. It assumes that not every path will be perfect all the time, measures the quality of the paths, and selects the most usable path. That makes the old distinction “private = high quality and Internet = best effort and unreliable” far too simplistic today.

Modern WAN can actually test the claim.

What about the assumed latency advantage of MPLS? Today, this too can be measured rather than assumed. In our own practical measurements within Finland, the latency difference between a branch-to-data-center path and a more direct path has been only around 2 ms. That is an interesting result. How much meaningful latency advantage could a private WAN (MPLS) realistically provide beyond that? Fiber propagation delay ultimately sets the physical lower bound, and we are already operating relatively close to it.

Far more interesting questions are:

– Is there packet loss?
– How much does latency vary?
– How much jitter is present?
– How often does the path fall below the acceptable quality threshold?
– How quickly does the WAN react?
– Does the user ultimately notice the problem?

With a modern WAN architecture, the impact need not be guessed. It can be measured continuously and automatically.

SaaS broke the traditional service boundary

In the old Private WAN (MPLS) world, things were simpler when the carrier connected an office to the enterprise’s own data center. Today, the traffic path often looks more like this: Office → ISP access → ISP core → Internet egress → peering/transit → SaaS provider → application. If a user experiences packet loss when accessing Microsoft 365, Salesforce, ServiceNow, SAP cloud services, or applications running in Azure, AWS, or Google Cloud, where exactly is the problem?

We have encountered a real-world situation in which significant packet loss occurred to a particular global cloud service, even though the carrier’s access connection and backbone appeared normal. This led to a deceptively simple question:

“Can we agree with the carrier on a measurement point for packet loss, jitter, and latency up to which we can verify that the carrier’s service is operating at the agreed quality? Can we jointly define when the quality is no longer sufficient for critical applications?”

In practice, this turns out to be a surprisingly difficult question for many carriers. If the measurement point is within the carrier’s own core network, it primarily indicates that the carrier’s core is functioning. That alone would already be an improvement. If, on the other hand, measurements are made directly to the SaaS service, we get a good picture of the user experience — but we can no longer automatically conclude that any problem belongs to the ISP.

From the customer’s perspective, however, it is still important to establish that at least the ISP’s own network and routing are functioning correctly. On the Internet, the technical service path and the commercial responsibility boundary no longer align neatly. It therefore makes sense to measure several boundaries. A modern WAN could reasonably monitor at least three levels:

1. Customer edge → ISP network
2. Customer edge → ISP Internet egress
3. Customer edge → SaaS service

The first describes the access service. The second provides more detail on the carrier’s backbone and Internet egress. The third tells us what the business ultimately cares about. This does not create a perfect legal division of responsibility, but it allows us to locate problems much more accurately. And from a modern WAN perspective, the first priority is not necessarily determining who is to blame.

The first priority is finding the best working path

One carrier or several?

The traditional approach has been to purchase as much of the network as possible from a single carrier. A European enterprise, for example, might try to keep both access connections and backbone connectivity under one carrier’s control. The advantage is clear: there is a single accountable party, and a larger portion of the end-to-end path can be managed by a single provider.

An alternative is to purchase Internet connections from several ISPs at different sites and allow the modern WAN to continuously evaluate their quality. Something important happens in this model: Carrier quality no longer has to be assumed. It can be measured.

If ISP A experiences packet loss towards a particular SaaS service while ISP B does not, the WAN can use ISP B. After months of collecting telemetry, the enterprise can answer questions such as:

– How often was the connection completely unavailable?
– How often was it up but unusable because of poor quality?
– Which destinations were affected?
– How often did traffic have to be moved away from a carrier’s path?
– Did different ISPs experience problems at the same time?
– How often did users actually notice anything?

That may be far more valuable than an annual report showing “99.99% availability”. However, two ISPs do not necessarily mean two independent paths. Behind two different carrier logos, there may still be the same:

– fiber route in the street
– cable duct
– local wholesale carrier
– backbone node
– transit provider
– Internet Exchange or peering dependency.

The real objective, therefore, is not simply two ISPs. It is “independent failure domains”. Modern WAN telemetry can also help reveal how independent those paths really are. If two supposedly independent connections repeatedly experience exactly the same problems at exactly the same time and towards the same destinations, it is worth asking how independent they actually are. The Baltic Sea cable incidents have made this issue very tangible.

Satellite introduces a genuinely different failure domain

LEO satellite connectivity makes redundancy even more interesting. Satellite is not merely a “third ISP.” From the perspective of the local access network, it can represent an entirely different failure domain. A fiber cut, street cabinet failure, or local carrier access outage does not affect a satellite connection in the same way. Satellite services naturally have their own ground stations, backbone networks, and Internet dependencies. There is no such thing as complete end-to-end independence. But from the perspective of the site’s last mile and core network operations, the difference can be significant.

A modern WAN can therefore combine, for example, Fiber ISP A + Fiber ISP B + 5G + LEO satellite and select the transport based on actual measured quality. The question is no longer how perfect an individual connection is. The question becomes: “How likely is it that all independent paths fail at the same time?”

A managed backbone is a third alternative

A SASE solution with its own or managed global backbone introduces another option. The difference is not the “last mile”, but the “middle mile. The architecture may look like this: Site → local ISP → nearest PoP → managed backbone → egress close to SaaS. The last mile remains the responsibility of the local ISP, but a large part of the long-distance Internet path is controlled by a single provider. In some ways, this resembles the old private WAN philosophy: bring as much of the path as possible under one provider’s control.

Today, however, this question no longer needs to be resolved ideologically. We can compare the actual quality of different architectures using data, where a strict SLA on one expensive connection is no longer necessarily the most important factor. And this leads to what I think is the most interesting question of all. The traditional WAN assumption was that the connection itself had to be extremely reliable because when it failed, the user’s service failed with it.

Modern WAN can break that assumption.

When the quality of the primary path deteriorates, traffic can quickly move to another path. Depending on the implementation, existing sessions may even be preserved so that the user does not notice the event. For some use cases, critical traffic can also be protected by transmitting the same data over multiple paths and eliminating duplicates at the receiving end.

  • Traditional thinking: Make the individual connection as reliable as possible.
  • Modern thinking: Assume individual connections will sometimes fail and make sure the user does not notice.

If that works, we need to ask whether it always makes sense to pay a significant premium for an extremely strict SLA on a single circuit. In some environments, absolutely. In others, investing in two or three genuinely independent transports may be economically more sensible than trying to make one connection nearly perfect.

 The SLA does not disappear

If the primary connection fails and is not repaired for a week, the enterprise operates without redundancy for an extended period. Repair time therefore remains important. But the role of the SLA may change. The SLA may no longer guarantee continuity of the user’s service. The WAN architecture does that. The SLA increasingly describes the quality and responsibility of an individual underlay service and how quickly the provider must restore redundancy. This is also where the traditional ticketing process begins to look outdated.

A modern WAN may detect:

– 10:03:17 – packet loss exceeds the acceptable threshold
– 10:03:18 – the path is removed from service
– 10:03:19 – traffic continues over another path

Yet the carrier’s SLA clock may not start until 10:47 – the customer opened a trouble ticket. But the ticket is an administrative event. It is not the moment when network quality failed. If a quality degradation can be verified using a pre-agreed metric and timestamped telemetry, it would seem natural that future SLAs could use the same information. Perhaps we need three different metrics.

I would distinguish at least these three:

  • Circuit availability – What percentage of time was the individual connection technically up?
  • Quality-qualified availability – What percentage of time did the path meet the defined packet loss, latency, and jitter criteria well enough for the WAN to consider it usable?
  • End-user service availability – What percentage of time did the user’s actual service work?

Is an SLA ultimately a guarantee of quality?

Not automatically. An SLA guarantees what is defined in the contract at the measurement points, using the agreed calculation method and thresholds. 99.99% availability does not mean 99.99% high-quality WAN service. It may simply mean that, according to the contractual definition, the connection was rarely classified as completely down.

Modern WANs make this distinction explicit. And perhaps this is the most important change of all. In the MPLS era, network quality was partly purchased as a promise and an architecture. With modern WANs, it can be measured continuously on a path-by-path basis. That also changes the significance of a carrier’s 99.99% availability SLA. The most important question may no longer be how many nines the circuit’s SLA contains. It may instead be: What happens to the user or the OT process when this path becomes poor or disappears completely? If the answer is “not much,” we are already a long way from the world for which the traditional WAN SLA was originally designed.

It is time to rethink the Traditional WAN SLA

 

Hannu Rokka, Senior Advisor

5Feet Networks Oy