When traffic is spread across multiple content delivery networks, knowing the ideal destination is only half the problem. The harder question is how to get there without creating congestion, blowing through contractual limits, or making a routing decision that looks good right now but causes trouble a few minutes later.
In a recent talk at BuffCon 2026, Tom Howe, Principal Product Architect at Hydrolix, laid out an approach to CDN traffic steering that combines real-time telemetry, machine learning forecasting, and decades-old optimization math to move traffic between CDNs more safely and more responsively than a purely reactive system can.
The optimal split is a target, not a route
The basic problem is familiar to anyone who has run large scale internet traffic across more than one provider. An operator might decide that 25% of traffic should go to one CDN and 50% to another. That optimal distribution is a destination, though, not a roadmap for getting there.
“The optimal split is a target,” Howe said. “It doesn’t tell us how to get there.”
Getting there matters because traffic cannot always shift instantaneously. Business agreements can cap how much traffic moves at once. CDNs run into capacity constraints. Costs change at different traffic levels. And moving too much traffic too quickly can simply push a congestion problem from one provider onto another.
Why CDN traffic steering needs to look ahead, not just react
Traditional traffic steering systems largely decide based on what they see at the current moment. If one CDN is cheap and has capacity to spare, a system will naturally send more traffic its way. That works fine until demand starts rising fast.
Consider a major live event such as the World Cup. At the start of a traffic surge, a low cost CDN might look like the obvious place to send additional traffic. But if demand is forecast to climb sharply, routing there based only on current conditions could push that CDN past a safe congestion limit. Video platforms handling this kind of load often spread it across several video streaming CDNs for exactly this reason, and the same forecasting problem shows up regardless of how many providers are in the mix.
A look-ahead system sees that problem coming. Howe described using a “receding horizon” approach, where the system forecasts traffic several steps into the future and then runs a constrained optimization model to work out how traffic should move from its current state toward a safer future state.
The important distinction is that the system doesn’t blindly execute the entire plan. It calculates the full path, then throws away everything except the first step.
“You do the whole optimization and throw away everything except that first timestep,” Howe said.
At the next interval, the system pulls fresh telemetry, updates its forecast, and calculates a new path. The result is a continuously moving control loop instead of a single static routing decision, one that can also account for constraints such as a rule that traffic to an endpoint cannot change by more than 10% in a given time step. Restrictions like that stop the optimizer from making a move that is theoretically optimal but operationally reckless.
60-year-old math, not a new AI model
Despite how much artificial intelligence gets credited in traffic management pitches these days, Howe stressed that the optimization step itself doesn’t need a new AI breakthrough.
“I am not talking about AI,” he said. “I am talking about 60-year-old math.”
That math is linear, constraint-based optimization. Machine learning models handle the forecast of what traffic is likely to look like ahead of time, but the optimizer takes those predictions and works out how to move traffic while still respecting the system’s hard constraints.
The distinction matters. Forecasting answers one question: where is traffic likely to go? Optimization answers a different one: given that forecast, what should the system do right now? The second question can involve competing goals, since an operator may want to minimize congestion and cost at the same time, all while respecting limits on how fast traffic can change and how much capacity each CDN has. The optimizer’s job is to search for a path between the current traffic distribution and the desired future state, and that forecast is never perfect.
“The model is great. But everything you do is only as strong as the quality of that model,” Howe said.
That makes telemetry a critical piece of the system, since poor data can undermine even the most sophisticated forecasting and optimization work sitting on top of it. Howe framed the whole approach as three interconnected layers.
Telemetry, optimization, and a control loop that never stops
The first layer is telemetry. The system needs accurate, timely information about incoming traffic and the state of the infrastructure behind it. Without that foundation, machine learning predictions and optimization decisions built on top have little value. “ML-based prediction is worthless if the data is worthless,” Howe said.
The second layer is optimization. Linear constraint-based programming determines how traffic should move while respecting the limits the system operates under. Howe argued this computation needs to run fast enough to happen at the edge, where routing decisions can react quickly to congestion as it emerges rather than waiting on a round trip to a central system.
The third layer is the control loop itself. The system applies the first step of its calculated plan, gathers new telemetry, forecasts the next period, and runs the optimization again. Then the cycle repeats.
That architecture fixes a real weakness in purely reactive traffic steering. Instead of constantly asking what looks best right now, the system asks what action makes sense given where traffic is expected to be heading, and speed matters here. Traffic conditions can shift fast, and routing decisions made centrally can introduce delay that a live event doesn’t tolerate well. Highly optimized constraint solving running at the edge lets the system respond to congestion without waiting on a slower centralized control process.
Business constraints a simple congestion model misses
The approach also opens the door to more sophisticated business constraints. Howe pointed to pricing models where a customer has a prepaid traffic allowance and faces penalties after exceeding it. A routing system optimizing only second by second could easily miss those longer-term economic consequences. He suggested a “two-time-scale” optimization could address this: one path focused on immediate traffic management, another considering longer-term cost and capacity decisions.
There are real limits to the simplified model, though. The system Howe described uses congestion as a stand-in for quality of experience, and in practice that doesn’t capture everything a viewer actually experiences. Additional data from Common Media Client Data (CMCD), for example, can reveal playback conditions such as buffer levels and rebuffering events. Feeding that into the optimizer could let it make routing decisions based more directly on actual viewer experience rather than infrastructure congestion alone.
Forecasting over longer horizons brings its own complication: uncertainty. A model might predict traffic will hit a particular level several minutes out, but the further the prediction reaches, the less certain it becomes. An optimizer can’t behave as though it has perfect knowledge of what’s coming, and Howe named this as one of the areas that still needs more work.
Roll it out in stages, not all at once
For operators considering a system like this, Howe’s advice was as much about implementation discipline as it was about the optimization math itself. The components should go in sequentially rather than flipping straight to automated traffic steering.
Reliable telemetry comes first. Then the models can run in shadow mode, generating proposed decisions without touching production traffic at all. Operators can review those decisions, tune the models, and build confidence before anything automated goes live.
“You want to make sure each step you have confidence in the step,” Howe said.
That feedback loop matters because the optimization system keeps evolving after launch. Forecasting models need retuning. Constraints change as business terms change. Operators often discover that the objectives they optimized for at the start don’t fully capture what the business or the viewer actually needs.
The end goal, as Howe framed it, isn’t to find the one mathematically optimal CDN split. It’s to build a control system that keeps moving toward that distribution without losing sight of the constraints that make the real world problem hard in the first place. The real innovation here isn’t a new optimization algorithm. It’s combining accurate telemetry, predictive models, and established optimization techniques into a fast feedback loop that keeps asking the same question: given where we are now and where we’re heading, what’s the safest move to make next?
