AI Performance and Latency: How Infrastructure and Networks Matter

I’ve been thinking about this topic for a few days. I believe it’s a huge issue that spans multiple sectors: infrastructure, server cluster controllers, content delivery networks (CDNs), and even the physical distance between users and AI server farms.

Physical Distance Between AI Infrastructure and Users
We need to understand how we use AI Large Language Models (#LLM) like #ChatGPT or #Grok. Users access the web or a mobile application and input a query into the AI LLM. The AI server farm then processes the query and sends back a response to the user.

In this interaction, how far away is the user from the AI infrastructure? And how much latency does this distance create?

We might think about whether a CDN could help deliver responses (via caching) to users in order to reduce latency. However, replies and generated images are often dynamic content, which typically cannot be cached effectively. Of course, there are techniques like WAN acceleration, byte caching, or session caching that can improve efficiency to some extent.

That said, we all know CDNs still provide important functionality beyond caching, such as DDoS protection and DNS services.

According to reports, the top six AI infrastructure hubs in the world are located in the United States, Canada, Norway and Sweden, Singapore, India, and the United Arab Emirates [https://www.rcrwireless.com/20250501/fundamentals/top-ai-infrastructure]. That said, users generally do not know where the queried LLM model is actually running. To determine this, deeper measurements—such as DNS queries and web interaction analysis—would be required. Regardless, long-distance traffic transmission between regions is still unavoidable.

Internet infrastructure and Edge Computing
If the above assumption is correct, what role can Internet infrastructure and Tier 1 network operators play? Additional network deployment will certainly be required to support the high bandwidth demands of AI usage. However, this is not only a matter of bandwidth — latency is equally important.

In the earlier era of the web and HTTP content delivery, the processing requirements were relatively lightweight. A cache server could be deployed at the “edge” to serve static or semi-dynamic web content for multiple users in a given region. This model works well for traditional CDNs.

For AI, however, the situation is different. While lightweight LLMs might be deployed on edge computing nodes—provided those nodes have sufficient processing capability—large-scale AI infrastructure is far more demanding. Deploying an AI system with thousands of GPUs worldwide is not straightforward. Beyond hardware availability, challenges include massive power consumption and the cooling requirements of such clusters, which vary greatly depending on the region.

It’s an interesting question: how do we bring the scale of AI infrastructure closer to the edge while balancing efficiency, cost, and sustainability?

A CDN provider has already taken action in collaboration with several AI companies. The AI Gateway or MCP Gateway could help address those technical questions. Let’s take a look at the latest update:
[https://blog.cloudflare.com/ai-gateway-aug-2025-refresh/] [https://blog.cloudflare.com/how-cloudflare-runs-more-ai-models-on-fewer-gpus/?utm_campaign=cf_blog&utm_source=linkedin&utm_medium=organic_social&utm_content=20250827/] #20250827

AI Infrastructure, Controllers and Network Nodes
Building on the above points, it’s important to note that most AI infrastructure today is already quite mature. The robust frameworks developed during the Cloud Computing era—such as VXLAN, Kubernetes, and other cluster node controllers and load balancer as well—provide a strong foundation for managing large-scale AI workloads.

Major cloud providers like Google, AWS, and Microsoft have already demonstrated the stability and scalability of these architectures, showing how well-established the underlying infrastructure has become.

Managing a stable cluster node controller capable of handling millions of AI requests is truly an art of operations. It requires careful consideration of latency at every level, including the low-level hardware channels.

When a request is processed, the load balancer sends it to the appropriate nodes through the infrastructure’s network devices and routing protocols. The nodes then process the request, consolidate the results, and send the final response back to the user. Each of these steps is interrelated, and optimizing them is crucial for delivering fast, reliable AI responses.

Some researchers have started studying how to reduce—or determine the necessary speed of—latency in these processes. This spans multiple layers: operating systems, RAM, GPU channels, network connections, network protocols, control and data planes, fiber channels, and more.

If all distributed nodes could be interconnected with specialized high-speed links—such as PCIe, ASIC boards, Scalable Link Interface (SLI), or CrossFire links—what would that mean for latency? It’s an interesting thought experiment worth exploring. In the latest Nvidia blog, the Quantum-X InfiniBand Photonics was introduced as an integrated fiber-optic switch, which reduces the electrical-to-optical conversion between the switch and the fiber at the optical transceiver. [ https://developer.nvidia.com/blog/scaling-ai-factories-with-co-packaged-optics-for-better-power-efficiency/?ncid=so-link-416360&linkId=100000378640319]. I believe that while it may initially be used only in AI infrastructure, one day it could become essential for every Tier 1 network infrastructure.

Open discussion.

Test with ECMP on Linux

I was reading an article about ECMP (Equal Cost Multipath) for traffic load sharing, and it brought back memories of my previous traffic engineering tests. It seems simple at first glance, but it’s actually more complex—especially when it comes to policy-based routing.

The challenge lies in determining traffic redirection and sharing in a session-wise connection, whether with or without NAT, across multiple links or circuits with different latencies. There’s also the complication of firewall interception with asymmetric return traffic. These factors make achieving ideal traffic load sharing quite difficult.

Of course, if tunneling is involved, things get simpler. It essentially blinds both endpoints and allows you to add two routes with the same metric in overlay routing. However, it doesn’t clearly explain why load-sharing performance behaves the way it does.

What about service enhancement? If the primary link becomes congested, should the secondary link pick up some of the traffic? That’s not exactly round-robin behavior—it would require active measurement and monitoring of the links. Maintaining session flow on the primary link while redirecting new flows to the secondary link sounds ideal, but it’s difficult to implement. For MPLS-TE, that’s straightforward—but what if you have two internet links, like one DIA (Direct Internet Access) and one mobile network? How would you handle that?

Well, just for fun, I haven’t done any serious measurements yet. But after setting up load sharing on my node, it seems to be working—though I haven’t really thought through the next steps. Running a Speedtest shows that the flows (by ports) are transmitting separately. Hmm… not ideal, but not bad either. But what about other applications? If they’re using two different IP addresses for outgoing traffic—ahhhh…

Let’s discuss this, bro.


Enable 2 Multipath load sharing
sudo ip route add default scope global \
nexthop via 192.168.X.X dev XXX weight 1 \
nexthop via 192.168.X.X dev XXX weight 1

For multipath routing, disabling connection tracking for locally-generated traffic helps
sudo sysctl -w net.netfilter.nf_conntrack_tcp_loose=0

Enable Layer 4 Hashing
sudo sysctl -w net.ipv4.fib_multipath_hash_policy=1

Enable IP Forwarding
sudo sysctl -w net.ipv4.ip_forward=1

Force More Aggressive Flow-Based Balancing:
Set rp_filter to 0 (disable reverse path filtering) so the kernel won’t drop asymmetric traffic

sudo sysctl -w net.ipv4.conf.all.rp_filter=0

Flush all route cache
sudo ip route flush cache

#ECMP #Linux #Internet #Routing #IP #Firewall #Tunneling #MPLS #trafficEngineering #ChatGPT

How do you troubleshoot a network problem? Cabling? Configuration?

As a Wide Area Network (WAN), the circuit provided by telecom backhaul between two endpoints—whether it’s point-to-point between two sites (EVPL, SDH) or customer site to provider PE (Internet, IPVPN, VPLS, etc.)—should be connected to the provider’s equipment or router devices to deliver the service. If you’re referring to dark fiber in a limited area… um… okay, next.

How do you verify the circuit service? Check your site router configuration? Check your IP routing?

The basic mindset: I believe we should start by checking the cabling. Yes, Layer 1, isn’t it?

If your port is UP and able to send and receive packets, WELL, at least confirm both endpoint IP addresses and perform a ping test. (Yes, a PING test—please don’t tell me you don’t know what PING is.)

PIC from #Google

From past experience, field engineers often argue that the device configuration is incorrect, but guess what? The issue ends up being the WRONG port connected.

Therefore, HOW IMPORTANT IS PHOTO CAPTURE!!!!!!!

What if the ping fails? Yes, it happens—cable quality issues, loose connectors, poor signaling, etc.

Have you ever checked the DUPLEX setting????????????? Confirm both ends have the SAME duplex setting!!

PIC from Cisco Press

Then you’ll mention bandwidth: “Speedtest.com, huh? Why can’t I get full bandwidth?!”

Please understand: we cannot guarantee a test server will allocate all resources for your test. The Internet is unmanaged, and you need to be aware of overhead and your device’s processing power. Do you really think your mobile can hit 2Gbps over Wi-Fi, bro?

For standard testing, running tests between the client site and the ISP backhaul provides a great reference for your service quality—this is typically done during installation.

But anyway… PLEASE confirm the cabling is correct before spending too much time checking the configuration. Start with Layer 1 first!

#circuit #physical #cabling #ISP #provider #Internet #EVPL #IPLC #IPVPN #P2P #IP #testing #ping #bandwidth #speedtest #traffic #packetlost #duplexing #router #WIFI

AI Network Operator – under Deepseek case

We all know how successful Deepseek has been in recent months. It demonstrates that a low-processing-power, CPU-based AI is possible. Adopting this type of AI anywhere, including IoT devices or even routers, could be feasible.

Cisco, Juniper, Arista, and other network device manufacturers already produce hardware with high processing power. Some of these devices run Linux- or Unix-based platforms, allowing libraries and packages to be installed on the system. If that’s the case, can AI run on them?

Based on Deepseek’s case, tests have shown that an ARM Linux-based Raspberry Pi can successfully run AI. Although the response time may not meet business requirements, it still functions.

Running AI on a router (perhaps within the control plane?) could enable AI to control and modify router configurations. (Skynet? Terminator?) But then, would the AI become uncontrollable?

There are several key questions to consider:

  1. What can AI do on routers and firewall devices?
  2. Can AI self-learn the network environment and take further control?
  3. Can AI troubleshoot operational issues?

It seems like an interesting topic for further research. However, before diving deeper, teaching AI about network operations should no longer be a major concern.

Paragraph proofreading by #ChatGPT

AI Picture generated by #CANVA

#AI #Network #internet #networkoperation #operation #IP #Router #RaspberryPI #PI #Cisco #Juniper #Arista #opensource #BGP #routing

Enhance Internet performance by using the right Public DNS servers

If you are thinking of how to enhance your Internet performance, it is great that you can subscribe a higher bandwidth Internet service. But is it the right way?

No really.

Increasing the bandwidth cannot shortern the latency between you and the destination server. But You cannot control our provider’s network path.

Under the current Web server depolyment, using the Content Delivery Network to deliver the content to Internet is a comment way. However, your network provider’s DNS server may not response the optimial server for the request domain. Therefore, you cannot enjoy the lowest latency between you and the request server.

HOW to?

A little measurement you can do, you can try to make a query to several publilc DNS servers, the reponse result may not be the same. For Example, by 8.8.8.8 Google or 1.1.1.1 Cloudflare. Based on the result, a simple ping test you can perform and record the lower latency one. Finally, you can setup a bind server to forware the domain to that DNS server to have a better Internet performance.

Reference what our work. Feel Free to discuss.

https://www.bgptrace.com/DNS/running_result.html

#DNS #Internet #Measurement #Ping #Latency #CloudFlare #Google #1.1.1.1 #8.8.8.8