Simon Sundberg

Johan Garcia, Simon Sundberg, Anna Brunstrom

In all networking systems, queuing is important to ensure appropriate resource utilization in the presence of bursty traffic and varying traffic demands. The Starlink access network is additionally also dynamic in terms of the capacity it can provide, and thus queuing plays an even greater role to ensure appropriate communication performance for the end-users while maintaining high resource utilization. However, for Starlink most system design details, along with the setup of the internal queuing, is private information and not publicly available. To address this we have developed a high-precision, burst-pattern controlled, traffic generation approach allowing us to precisely measure the one-way delay for Starlink. By analyzing the delay and loss in conjunction with a queue simulator we find that Starlink does not employ per-flow fair queuing or drop-tail buffers, but it does use drop-front buffer management. While drop-front reduces delay, it may also interfere with the assumptions made by loss-based congestion controls, potentially contributing to throughput degradation.

Simon Sundberg, Anna Brunstrom, Simone Ferlin-Reiter et al.

With networking moving into the sub-millisecond latency domain, latency in the end host itself can become a significant barrier to achieving consistently low application latency. Both the physical interconnect between the network card and the CPU, the kernel network stack, and the scheduling of applications themselves can be considerable sources of latency. Previous work has studied host latency at various levels, yet there remains a lack of methods and tools to continuously monitor host latency in production. To remedy this, we present netstacklat, a monitoring tool that captures latency at several points in the host network, from the early parts of the Linux kernel network stack all the way until the application reads the data. We evaluate netstacklat in a testbed, demonstrating its ability to capture host latency across 144 variations of HTTP workloads for Nginx and Apache, while also showing how the low monitoring overhead does not inflate tail latency by more than 6%, where previous monitoring solutions increase it by over 100%. Furthermore, we share our initial findings from deploying netstacklat in Cloudflare's global CDN network.