- SPEAR Lab builds real systems and conducts measurements to address performance gaps in edge computing and modern internet protocols.
- LEO satellite networks suffer from poor content delivery when lacking local ground infrastructure and integrated DNS/CDN coordination.
- Internet measurements reveal that real-world deployment of protocols like Multipath TCP remains limited due to middlebox incompatibility.
As edge computing and satellite connectivity reshape the Internet, researchers like Dr Nitinder Mohan are rethinking how networks perform in the real world. Dr Mohan is an Assistant Professor in the Department of Electrical Engineering, Mathematics and Computer Science at Delft University of Technology. He leads the Systems and Protocols for Edge-Enabled Internet (SPEAR) lab, where his research focuses on edge computing, next-generation network protocols, Internet-wide measurements, and the deployment and management of critical applications. With a background in both academic and applied systems research, Dr Mohan’s work bridges the gap between academic research and the operational realities of today’s and tomorrow’s Internet.
Q1. As you lead the SPEAR lab, could you briefly introduce its core focus areas, particularly in edge computing? What would you say is the biggest challenge right now?
Mohan: I lead the Systems and Protocols for Edge-Enabled Internet lab, or SPEAR lab. Although the lab itself is relatively new, the research behind it has been ongoing since I completed my PhD. Our work sits at the intersection of edge computing systems and large-scale internet measurements.
The core motivation behind the lab is to understand and address how traditional cloud computing and internet technologies are beginning to converge. While this convergence is happening in concept, we still observe a clear divide between the communities working on cloud systems and those focused on the internet infrastructure. This gap becomes more apparent as we see computing resources moving closer to end users. In recent years, compute servers are no longer just located in distant data centres. Increasingly, they are being deployed within ISP networks, right at the edge.
At the same time, the internet itself is evolving. It is no longer simply a tool for connecting users to remote servers. It now includes intermediate elements, such as middleboxes, that can perform computations while data is still in transit. This evolution becomes especially important when we think about new applications like cloud gaming, augmented reality and virtual reality. These applications require extremely low latency and can no longer rely on traditional models where all processing happens at a central location. Instead, they demand that computation happens much closer to the user, possibly even along the network path itself.
This shift creates a clear challenge. There is a growing mismatch between the demands of modern applications and the capabilities of the current network infrastructure. At SPEAR lab, we address this by building real systems that support edge computing, with a particular focus on orchestration. Alongside this, we conduct internet-wide measurements to better understand how the network behaves in practice. We study transport protocol performance, ISP performance and application performance at scale.
It’s essentially a cycle — we build systems, measure their performance, and then improve those systems based on what we learn.
Dr Nitinder Mohan, Assistant Professor at Delft University of Technology
We use the findings from these measurements to improve the systems we design. It is a continuous cycle. We build systems, observe how they perform across the internet, and use those insights to make them more effective in real-world environments.
Also Read: Edge computing vs. cloud computing: What’s the difference?
Also Read: Deutsche Telekom sets up sovereign cloud unit
Q2. You mentioned that traditional protocols like TCP are struggling in modern environments. In the context of LEO satellite networks, what would you say are the most critical performance gaps?
Mohan: Before getting into the challenges with Transmission Control Protocol (TCP), it’s helpful to first explain how LEO satellite internet actually works. There is a common perception that these networks operate entirely in space, offering better connectivity simply by bypassing traditional ground-based infrastructure. The idea is that once the satellites are deployed and orbiting the Earth, users no longer depend on local base stations or government-funded infrastructure. If the satellite coverage is dense enough, people assume they should be able to get internet access anywhere.
However, our measurements and deeper analysis show that this assumption is not accurate. In reality, LEO satellite networks are still very much ground-dependent. The satellites essentially function as mobile base stations. Instead of connecting to a traditional tower, your device connects to a satellite, which then passes the data back down to Earth through ground stations. From there, the traffic travels to a Point of Presence before reaching the wider internet.
This architecture means that if a satellite operator does not have enough ground stations or well-distributed Points of Presence, the overall network performance will be poor. We observed this in the early stages of Starlink’s expansion. Even though they had launched a large number of satellites, users in regions like Africa and Asia still experienced poor connectivity. The main reason was the lack of local ground infrastructure. To improve this, Starlink had to invest significantly in obtaining licences, deploying new ground stations, and building peering arrangements in those regions to reduce latency and improve overall performance.
Also Read: Starlink receives warning from Australian watchdog
Now we are seeing more LEO operators entering the space. Companies like OneWeb and Kuiper are preparing to launch many satellites as well. As they grow, we expect to see a wide range of different approaches and performance results. While terrestrial networks continue to support mobile and fibre-based connectivity, satellite networks are being positioned as a more accessible or resilient option in remote or underserved areas. Behind the scenes, though, both systems rely on similar backhaul infrastructure.
The way they operate, however, is quite different. Satellite links have their own characteristics. They involve more frequent handovers, variable latency, and different throughput patterns compared to traditional networks. This variability makes it difficult for protocols like TCP to perform well, because TCP was originally designed for stable, predictable connections.
For example, if you look at Starlink’s performance in regions like the United States or Europe, you might see latency in the range of 30 to 40 milliseconds. But in regions where ground infrastructure is still being developed, such as parts of Africa, the latency can be much more inconsistent. This is largely due to limited ground station capacity and the need to frequently switch between satellites during transmission.
Existing transport and routing protocols simply don’t work well in LEO satellite networks.
Dr Nitinder Mohan, Assistant Professor at Delft University of Technology
Traditional transport and routing protocols do not adapt well to these conditions. As a result, performance suffers. To overcome this, we need better methods of integrating terrestrial and satellite networks. Only by enabling these systems to cooperate more effectively can we build a network that delivers consistent performance across different regions and use cases.
Also Read: Skynopy raises $16M for satellite ground station network
Q3. What are some early findings or promising directions from your research on integrating LEO satellite networks with existing Internet operations?
Mohan: One thing we’ve observed is that there is a disconnect between how LEO satellite operators present their network performance and how it actually affects end-to-end user experience. Most operators tend to showcase latency figures only up to the nearest Point of Presence. For instance, on the Starlink website, you’ll see nicely illustrated maps showing latencies of around 30 milliseconds in various countries. On the surface, it looks like the network is performing well.
However, those numbers only reflect the time it takes to reach the Point of Presence, not the actual destination of the user’s traffic. In practice, the full path to the application server can be much longer and more complex. This is something we study closely at the SPEAR lab, where we are interested in understanding how to optimise end-to-end application performance, not just the first hop.
Take content delivery as an example. Imagine a user in Nigeria using a LEO satellite connection. If the operator has not invested in ground infrastructure in that region, the user’s traffic may be routed through inter-satellite links to the nearest available ground station, which might be in Europe. From there, it exits the satellite network in a city like Frankfurt. But if the content being requested is locally hosted in Nigeria, the traffic then travels back across terrestrial networks to reach the local server. Once the content is fetched, it travels the same inefficient route in reverse—back to Frankfurt, and then through the satellite link to the user.
This process adds unnecessary delays and creates a poor user experience. It also highlights a deeper issue. Our current internet infrastructure is based on assumptions about geographical proximity and routing that no longer apply in satellite-based contexts. Systems like DNS resolution and content delivery networks are built for terrestrial environments, where it is relatively straightforward to determine where a user is located and serve content accordingly.
LEO networks disrupt this model. A user’s traffic might appear to originate from a completely different region, depending on where the satellite connects to the ground. This makes it difficult to deliver content efficiently or to place compute services appropriately.
As user location grows less predictable, delivering consistent performance requires closer integration between space and ground infrastructure.
Dr Nitinder Mohan, Assistant Professor at Delft University of Technology
To address this, we need better integration between satellite and terrestrial systems. That includes exposing more of the terrestrial infrastructure—like CDN nodes and edge computing resources—to LEO satellite operators. With better coordination, we can create more accurate mappings between users, content, and compute services, which will help deliver faster and more consistent experiences across different geographies.
Also Read: Intelsat sees future in satellite-terrestrial integration
Q4. You also work on large-scale Internet measurements. Have your results ever contradicted common assumptions about how the Internet or its protocols behave in practice?
Mohan: Yes, and that’s one of the key motivations behind our measurement work. A lot of assumptions exist about how internet protocols or technologies should behave, but when we test these assumptions at scale, the reality often turns out to be quite different.
One clear example came from our early work on edge computing, which was eventually published at HotNets 2020. At the time, there was a lot of talk about how edge computing would reduce latency. Many believed that placing compute closer to the user would automatically lead to much faster response times. To test that, we conducted large-scale measurements across seven major cloud providers. We mapped user connections from around the world, across cellular, Wi-Fi, and fibre networks, to their nearest data centres. The idea was to see what kind of latency users were experiencing, and whether putting compute closer would make a significant difference.
What we found was that most of the latency came from the access network, such as the user’s cellular or Wi-Fi connection. Once the traffic reached the backhaul, the latency to cloud data centres was already quite low. In places like Europe and the United States, cloud providers peer directly with large ISPs, so there is not much room for improvement. If your goal with edge computing is only to reduce latency, it is probably not the right reason. Instead, edge computing is better suited for improving application performance or building distributed systems. That understanding has become more widely accepted now.
Another example is our work on Multipath TCP, a protocol that lets devices use Wi-Fi and mobile data at the same time. It was standardised in 2020, but we found that its adoption was very limited. Many middleboxes on the internet do not recognise the protocol headers and either block the connections or respond incorrectly. Some even send fake acknowledgements, which can create security risks. In practice, only a small number of providers were using it, and most of the deployment came from Apple. Since Apple moved away from it, usage has declined. We open-sourced all our measurement data at mptcp.io so people can see how adoption has changed. This shows that standardisation is not enough. A protocol also needs compatibility across the internet to be usable in practice.
