Making Traffic Federation Easier

The idea of relying on a single content delivery network (CDN) probably gives many content providers heartburn. Whether that provider is delivering a game download or streaming video or an e-commerce website, a complete delivery outage can bring a digital business to a standstill…and have far reaching implications for the business. Even worse, consistent, unpredictable degradation to video quality or download speeds can impact subscriptions, in the case of OTT services, game downloads, or purchases. There is a direct correlation between a poor user experience and company profitability.

‍

That's why almost every serious content provider uses more than one CDN. But multi-CDN is a fairly crude way of ensuring redundancy. That's because, unless you have a lot of engineering resources laying around, CDN switching is often done manually. Each CDN has some traffic, to keep the caches warm in the event of a switch over, but the switching often isn't automated. That's because operations engineers (or whoever is in charge of the CDN delivery architecture) need to examine what's happening, escalate to CDN or ISP partners, and figure out why even while moving the traffic from the degrading CDN to a better performing network.

‍

What's really needed is a way to federate traffic between CDNs. That means an automated system, built on rules and leveraging the real-time data analysis of AI, that balances traffic across delivery networks. So rather than just switching, like in a multi-CDN system, traffic is spread across multiple CDNs in real-time.

TL;DR

• Traditional multi-CDN strategies provide redundancy but often rely on manual traffic switching and operational oversight.
• Traffic federation applies load-balancing principles across multiple CDN networks, dynamically routing traffic based on real-time performance, cost, and availability.
• Building and operating a traffic federation system internally is complex due to integration, analytics, automation, and scalability challenges.
• Traffic-Federation-as-a-Service (TFaaS) can abstract this complexity through a single interface, automated decision-making, and policy-driven traffic management.
• Agentic AI can continuously evaluate network conditions and business objectives, automatically optimizing content delivery across multiple CDN providers.

What Is Traffic Federation?

Many content providers are familiar with multi-CDN. That's simply parsing up traffic by percentages and then assigning a percentage to each CDN in the mix. Multi-CDN is a pretty easy way to ensure delivery continuity (i.e., there is always a CDN capable of delivering traffic) but it's kind of a second-rate load balancing. Load balancing is a dynamic network operation. It moves traffic or requests across a pool of resources. The difference is that load balancing is a lower level network function compared to CDN switching carried out in multi-CDN architectures. Load balancing is not just about switching traffic from one route to another, it's about routing traffic to the best resource based upon pre-determined criteria and real-time analysis of the resource in question.

‍

That's traffic federation in a nutshell — the application of network principles to moving traffic between different networks in a heterogeneous content delivery architecture. And it's not new. Cisco really explored this about 20 years ago. The problem back then was two fold. First, the technologies weren't really ready to apply load balancing principles to something like multi-CDN content delivery. Second, there were the business issues. When Cisco was exploring this, it became less about technology and more about how to share revenue between CDN and ISP.

Understanding the Technical Challenges of Traffic Federation

Putting aside the business concerns and assuming that the technology exists today, it's not enough. There are a number of technical challenges that would keep any content operator from exploring, implementing, and benefiting from traffic federation:

• Interface. There isn't a common interface for a content provider to connect with a CDN. Yes, they all usually provide some sort of API, but it's not standardized and requires constant maintenance on the part of the content owner.
• Operationalization. Although many content providers, especially larger companies with more resources, are familiar with building custom software for their own needs, every time they do this, it becomes another operational overhead as the bespoke solution needs to be owned and maintained internally.
• Assessment. Managing moving traffic across several CDNs is hard enough, but assessing how well each CDN is doing (across a host of metrics) and then making decisions based on that assessment is monumentally hard. Even if the proper tools are being used, like Hydrolix, to manage and present the data, it still takes a human time and effort to assess.
• Moving traffic. While manually shifting traffic from one CDN to another isn't that difficult, doing it in real time is hard because those systems have to be built as well. Thankfully, we have better access to such systems, in agentic AI, but that is another system that needs to be built and maintained, adding to the operational overhead.

‍

Only even if these technical challenges are addressed (and they could with enough engineering resources to create a bespoke solution), there is still another to contend with.

Solving For Scale

The problem is that all of those challenges are magnified by scale. As the footprint of delivery capacity expands (through an increasing number of CDNs connected to the system), the complexity of the system expands as well. And this complexity is a factor of the amount of data, rules, and other operational impacts. In fact, it's easy to imagine that managing CDN traffic federation, when expanded beyond even just a couple of CDNs, could become almost all consuming.

Traffic Federation as a Service

When Cisco outlined the idea of traffic federation, they did so within the confines of a conference room filled with network operators, CDNs and ISPs. The idea was to get them to standardize interconnection (leveraging the work done in the IETF on CDNi). But with everybody approaching the solution differently, and mired in the thorniness of distributing revenue from the content provider, there was no way it was going to get implemented in a way that made everyone happy. So what if the answer isn't to build federation from within but to build it on the outside, as a service?

‍

Traffic-Federation-as-a-Service would be similar, in concept, to how some services are approaching multi-CDN or content steering as a service. Here's how that service might look:

• Single interface. The TFaaS offering would provide the content provider a single interface. They would no longer have to manage multiple APIs or a bespoke, in-house solution to utilize a heterogeneous delivery network.
• Real-time Action. One of the complexities of having multiple CDN vendors is tracking and then acting on KPIs like performance, RTT, cost, etc. In a TFaaS platform, the operator abstracts the complexity of real-time metric analysis and action into a set of business rules set by the content provider in the TFaaS portal. These rules may be weighted, such as "I am more concerned with performance in region XYZ than cost" or threshold-based such as, "when RTT drops below X seconds, switch to a provider that has a better RTT time." In that way, traffic can be shifted constantly, moving to the network that, in real-time, has the best metrics for a given evaluation vector. In this way, the basis upon which to shift traffic is abstracted into a set of natural language rules and the complexity of acting on those rules is hidden.
• Automation. Load balancing needs computation structure to happen. For load balancing devices, this is built into the design. But for virtualized services, like an overlay control plane to manage traffic federation across multiple CDNs, there needs to be a logic and computational layer to carry out the complex tasks of traffic analysis (both historic and predictive) and act against it. That's just another system that needs to be built and managed by the content provider. But in this model, the TFaaS operator builds that logic. The content provider, by interfacing with the TFaaS platform and specifying a set of business rules (such as weighting factors by which the automation determines when to shift traffic), can just rely on the system to switch traffic as it sees fit.

‍

It's not hard to see how a system like this can start to take shape, offering content providers (especially those chained to a single CDN because of the complexity of managing multiple network interfaces) a way to take advantage of redundancy, reliability, and, most importantly, delivery continuity by using multiple CDNs without any of the operational overhead.

Expanding Capacity Without Cost

Perhaps one of the biggest advantages of using a TFaaS platform is how capacity can be expanded without spending any money. This works in two ways. First, from the platform perspective, the TFaaS operator can increase available capacity overnight simply by adding more network operators. Second, from the content provider's perspective, this means being able to access additional capacity for spikes or for improving delivery to hard-to-reach users (such as those connected to smaller ISPs in rural areas). Most individual CDNs today charge a premium for higher bitrate/throughput, when the amount of provisioned capacity is exceeded because of unforeseen circumstances (i.e., an exciting few minutes in a live sporting event). But what if, instead of pushing the additional traffic to a CDN that is already maxed out, that overage traffic can just be moved off to another provider. In today's world, that would mean the content provider would have to keep that secondary CDN warmed in the event of a spike. But if the spike never happens, it's just wasted money. In the TFaaS model, the spike is simply absorbed within the load balancing function of the system and spread to capacity that already exists.

The Role of Agentic AI in Traffic Federation

The power of this system, over a traditional multi-CDN switcher, is that traffic is continually evaluated and the best route (i.e., the best CDN to use) selected based on that evaluation. That kind of automation benefits greatly from agentic AI. Imagine that instead of a business logic layer, there are a number of agents acting under the umbrella of a central orchestrator. Those agents are highly specialized in specific areas within the load balancing framework. So one agent is trained deeply in network performance analytics. Another is trained specifically to handle congestion and capacity evaluation. You get the picture. By stringing these agents together in their own federation, a single orchestrator, interfacing with each content provider's business rules for traffic delivery (i.e., don't ever use CDN X in region A), can shift traffic around in real-time, maximizing not only for cost but also for performance, availability, and even reliability (i.e., historical data on the CDN's performance over time).

Introducing Blockcast CDN+

Blockcast has been building a CDN solution that differentiates from traditional delivery. By using a DePIN approach, its CDN can be expanded without the capital investment that traditional CDNs need to expand their capacity footprint. But in doing so, in the vein of expanding the concept of CDN to mean more than a megalithic network operator controlling traffic delivery, Blockcast also looked at how they could point their CDN innovation to the complexity of multi-CDN architectures. CDN+ was born.

‍

The Blockcast CDN+ offering is exactly the TFaaS system described previously. It's a single interface to multiple CDNs with everything about the load balancing of traffic across those CDNs abstracted from the content provider. All the content provider sees is how much traffic was delivered using traditional CDN logs and metrics. But behind the curtain, Blockcast's automated system, powered by agentic AI, is moving traffic between networks seamlessly. Content providers tell us, through a simple interface, a set of business rules and requirements, and CDN+ uses it, in conjunction with data received from the CDN networks and other probes, to route traffic in the most effective way in real-time.

‍

Interested in offloading the complexity of your multi-CDN architecture? Want to explore using more than one CDN without having to take on the difficulty of CDN switching? Head on over to the CDN+ webpage and then drop us a line to try it out!