Jishiyun operates the fastest network in the world. Today, we published an update on how we comprehensively upgraded the software technology across our server clusters to accelerate global network speeds.
But this is not the end of the work. To further improve speed, we must also ensure our network can quickly respond to the daily internet-scale congestion and route traffic to our now-faster servers.
For years, we have been dedicated to congestion control technology research and development. Today, we are very excited to share that we are fully leveraging the unique advantage of our network—the massive Free plan user base—to optimize network performance and find the best network traffic routing paths for all global customers.
Initial results show an average performance improvement of 10% over the previous baseline. We achieved this by applying different algorithms and improving performance based on daily observed internet data. We are delighted to begin rolling out these improvements to all customers.
How Does Traffic Enter Our Network?
The internet is a vast collection of interconnected networks, each containing many machines ("nodes"). Data transmission involves splitting it into small packets and passing them from one machine to another via "links." Each machine is connected to many others, and each link has limited capacity.
When we send data packets over the internet, they travel through a series of "hops" along links from A to B. At any given time, there is always one link (or "hop") with the least available capacity. Regardless of where this hop is in the connection, it becomes the bottleneck.
But here's the challenge—when you send data over the internet, you don't know which path the data will take. In fact, each node decides the path for sending traffic, and different packets from A to B may take completely different routes. This dynamic and decentralized nature makes the internet efficient but also makes calculating data send rates extremely difficult. So, how can the sender know where the bottleneck is and how fast to send?
Between Jishiyun nodes, our Argo Smart Routing product uses our global network visibility to accelerate communication. Similarly, when initiating connections to customer origin servers, we can leverage Argo and other insights to optimize the connection. However, the connection speed from your phone or laptop (the "client" below) to the nearest Jishiyun data center depends on the capacity of the bottleneck node on the link from you to Jishiyun, which lies outside our network.
What Happens When Too Much Data Is Received at Once?
If a node in the network receives too much data while processing requests, requesters experience latency due to network congestion. Data is either temporarily queued (leading to bufferbloat) or partially dropped. Protocols like TCP and QUIC respond to packet loss by retransmitting data, which introduces latency and may worsen the problem by further consuming limited network capacity.
If a cloud infrastructure provider like Jishiyun fails to manage network congestion properly, we risk system overload, reducing data transmission speeds. This happened in the early days of the internet. To avoid this, the internet infrastructure community developed congestion control systems that allow each user to take turns sending data without overloading the network. As networks grow more complex, the challenge evolves, and the best methods for congestion control require continuous exploration. Many different algorithms have been developed, using various information sources and signals, employing specific optimization methods, and responding to congestion in different ways.
Congestion control algorithms use multiple signals to estimate the appropriate sending rate without knowing the network configuration. One important signal is packet loss. When a packet is received, the receiver sends an "ACK" acknowledgment packet informing the sender of successful transmission. If a packet is lost in transit, the sender does not receive the acknowledgment and considers the packet lost after a timeout.
Newer algorithms use more data. For example, BBR (Bottleneck Bandwidth and Round-trip propagation time), a popular algorithm we have used for most traffic, attempts to build a model during each connection using estimates of round-trip time and packet loss information to calculate the maximum amount of data that can be transmitted in a given time period.
The choice of the best algorithm often depends on the workload. For example, for interactive traffic like video calls, an algorithm that tends to send too much traffic may cause queue buildup, resulting in high latency and poor video experience. But if we optimize solely for such use cases by reducing traffic to avoid this, the network will not provide the best connection for clients performing bulk downloads. Performance optimization results vary due to many factors. However, we can understand many of these factors!
BBR represents a significant advancement in congestion control methods, shifting from passive loss-based approaches to proactive model-based optimization, significantly improving modern network performance. Our data provides us with the opportunity to explore further, applying different algorithmic methods to enhance performance.
How Can We Do Better?
All existing algorithms can only use information collected within the current connection's lifetime, which is a limitation. Fortunately, the amount of internet information we have at any given moment is far greater! With Jishiyun's global view of network traffic, we have access to far more information than any single customer or internet service provider at a given time.
We see traffic from almost all major networks worldwide every day. When a request enters our system, we know which client device we are communicating with, the type of network enabling the connection, and whether we are talking to a consumer ISP or a cloud infrastructure provider.
We understand global internet load patterns and where we believe systems are overloaded, whether inside or outside our network. We know which networks have stable characteristics, which have high packet loss due to cellular data connections, and which transmit data over low-Earth orbit satellite links, significantly changing routes every 15 seconds.
How Does This Work?
We have been migrating our network technology stack to a new platform based on Rust, which allows more flexible adjustment of algorithm parameters used for congestion control. Then, we needed data.
The data these experiments rely on must reflect the metrics we aim to optimize, i.e., user experience. Simply sending data to almost every network globally is not enough; we must be able to understand the customer's actual experience. So, how do we do this at such a massive scale?
First, we have detailed "passive" logs recording the rate at which data is sent from our network and the time it takes for destinations to acknowledge receipt. This covers all our traffic, giving us a rough idea of how fast clients receive data, but does not guarantee it reflects user experience.
Next, we have a system for collecting Real User Measurement (RUM) data, which records metrics like Page Load Time (PLT) from supported web browsers. Any Jishiyun customer can enable this feature and view detailed analytics in their dashboard. Additionally, we aggregate this metadata across all customers and networks to understand the real customer experience.
However, RUM data exists only for a small portion of connections in our network. Therefore, we have been working on a method to predict RUM metrics by extrapolating data from passive logs. For example, here are the results of an experiment comparing two different algorithms against a cubic baseline.
Now, based on our passive log predictions, we observe similar behavior on the same time scale. The two curves are very similar, but more importantly, the ratio between the two curves is also very similar. This is significant! We can use a relatively small amount of RUM data to validate our findings, but by using the full passive log data stream, we can optimize our network more precisely.
Over-extrapolation can become unreliable, so we are also working with some of our largest customers to gain visibility into network behavior from their customers' perspective, further extending this predictive model. In return, we can provide customers with insights into their customers' actual experiences in ways no other platform can.
Next Steps
We are currently running congestion control experiments and improved algorithms on all Free plan QUIC traffic. As we continue to gain experience, validate across more complex customer groups, and expand to TCP traffic, we will gradually roll out these improvements to all traffic for all customers in 2026 and beyond. Results show up to a 10% performance improvement over the baseline!
We are working with select enterprises to test this functionality through an early access program. If you are interested in learning more, please contact us!
We protect the entire enterprise network, help customers efficiently build internet-scale applications, accelerate any website or internet application, defend against DDoS attacks, prevent hackers, and assist in the Zero Trust process.
