It’s time now to look at how a maturing AI agent deployment model would impact traffic flows. Assessing the impact that AI would have, and more significantly the impact of “horizontalizing” applications, with or without AI, would have on networks isn’t a simple topic. In fact, while 221 enterprises have offered comments on this in the last year, there’s a pretty wide variation in the way the comments cluster around the factors that influence that question. This week, we’re going to look at them all, but we need to start by organizing things a bit.
Generally speaking, data center networking is driven by an increase in vertical (application to user) traffic, horizontal (inter-component) traffic, or both. The nature of the traffic flows depends on where all the participating elements are located as well as the volume. Vertical traffic, in the data center network, is largely focused on getting in and out of the data center from the WAN, which might be the Internet, the cloud, the company VPN, etc. Horizontal traffic might be within a cluster of servers, within a data center, across data centers, and perhaps even to distributed computing elements outside the data center. All of this impacts what specific issues are important in the data center.
In the WAN, the big network question is “how to the users connect?” There are three broad possibilities; they connect via an MPLS VPN or private network of some sort, they connect via the Internet (including SD-WAN), or they connect via the cloud. All these mechanisms involve a different requirement for the enterprise network, and any or all of them might be used by a given enterprise, in any mix.
Only a bit over ten percent of enterprises who comment actually had any significant AI hosting, and all of them had deployed AI in centralized clusters. However almost a third had some “local” AI models running, often within facilities but sometimes in the data center. All 221 said they had experienced growth in both vertical and horizontal traffic, but all but 9 said that their horizontal traffic growth was the real driver of change to their network needs. Over 80% had made some changes in their networks to accommodate things like cloud networking, SD-WAN VPNs, and similar things, but these were tactical justifications, not what they considered strategic moves.
There are three forces driving things, say enterprises. One of them is the increased drive to integrate business processes, something that arguably started in the 2000s with the “Enterprise Service Bus” and Service-Oriented Architecture. This integration tends to create a transaction cascade as a “primary” transaction triggers related business processes independently, rather than having workers bridge the activity that crosses application boundaries. Think of this as a shift from double-entry bookkeeping to having a single action trigger both entries. This, the enterprises say, is the historical driver of horizontal traffic growth, and for most (a bit over three-quarters) it’s still the dominant one. It is also, as we’ll see, a driver that’s arguably behind the other two drivers.
The second force is componentization, a close second in terms of current growth. Here I’ll ask you to recall that enterprises see most AI applications as being components of a broader business toolkit, so they tend to see AI as contributing to growth here, but in two ways, and the one you probably think of as primary isn’t primary at all. Direct AI traffic, meaning access to AI tools, is a minimal issue. According to enterprises, the most successful AI agents are applied to enhancement of business analytics, and these tend to expand the way analysis draws on data repositories. “Without AI, it’s complicated to construct a big cross-all-data sort of analysis,” one enterprise told me. “With AI, we’re doing bigger and more complex analysis, involving more data and more data access.” AI agents are components, and components that spread data access breadth.
The third force is real-time services, the smallest of all the drivers at present but the one enterprises think has the greatest potential for long-term growth. The reason is, according to one IT planner, “We see a shift from integrated production to meshed production.” Today, transactions tend to link multiple stages of a business even if, within some at least, there’s real-time process control. This makes real-time systems an encapsulated element in those cascade transaction flows of our first driver. In the future, say about a third of the enterprises, the goal will be to create one enormous world model for the whole of the production process, and even perhaps for some of the related administrative and financial functions.
That’s not all, though. Real-time applications create and use more data, and have an exceptionally low tolerance for faults or even significant shifts in performance that impact application QoE. Thus, to the extent that AI is likely to drive real-time application growth, it’s also more likely to require (even though it’s an indirect influence) improvements in both latency and availability of network resources.
Now for the WAN. Enterprises do not, so far, see AI influencing WAN requirements, owing to the fact that the user-to-AI connection is confined to exchanging prompts for results, and thus isn’t much more data-intensive than traditional searches or typical enterprise applications. This, of course, presumes that the WAN carries only the prompts and responses, which may not always be the case.
There are three possible sources of WAN traffic beyond the prompt/response exchange; distribution of AI into a model hierarchy, remote model database access, and additional data collection to support AI agents in application missions not previously served. Each of these requires some exploration.
Distributed AI models seems to enterprises most likely to come about as a result of the creation of a world model that’s fed by individual process models. This sort of thing is most likely to arise in process control (real-time) applications, but in theory it could also be applied if a “local” AI agent could call on the capabilities of a larger, deeper model. AI models could in theory be tightly coupled to act as one, or be event-coupled, with the former creating the greatest network impact.
Model access to databases (RAG or similar techniques) might involve WAN access if the model were separated from the databases it relies on, or perhaps during training. The latter situation is not considered by enterprises as creating a likely network change, since training is a transitory activity, and the great majority of the enterprises who commented on AI agents’ use of data said they would not be likely to host a model so far from its data resources that WAN access would be required. This could change, but there’s no sign of it so far.
The additional data collection driver of incremental WAN traffic is the most difficult to assess because enterprises so far have very little exposure to it, even in the planning stages. Yes, it is possible that AI would open new application areas requiring new data absorption, but the current enterprise focus on AI agents is in area where a workflow, and thus data exchange, is already established. Again, real-time process control is the area where change is most likely.
OK, that’s our summary of traffic impacts, so in our last blog of this series, we’ll look at where those impacts might take networks.
