Waiting at the front door: Continuous monitoring of latency in the host network stack#

Authors: Simon Sundberg, Anna Brunstrom (Karlstad University), Simone Ferlin-Reiter (Red Hat and Karlstad University), Jesper Dangaard Brouer (Cloudflare), Toke Høiland-Jørgensen (Red Hat)

• Why: Once network paths drop into sub-millisecond territory — RDMA-era fabrics, co-located services — the host itself (NIC–CPU interconnect, kernel network stack, scheduling) becomes a first-order latency source. This is the paper at the intersection of your Linux datapath-internals interest and production reality, with authors from Red Hat and Cloudflare. Promoted from Adjacent: kernel-stack latency instrumentation in a production CDN is squarely core.
• What: netstacklat, a monitoring tool that continuously captures latency at multiple points in the host network path, from the earliest parts of the Linux kernel network stack through to the application's read. Evaluated across 144 HTTP workload variations (Nginx and Apache), with monitoring overhead inflating tail latency by no more than ~6%, versus >100% for previous monitoring solutions. Includes initial findings from deployment in Cloudflare's global CDN. (from abstract only)
• How: Lightweight instrumentation at several points along the host network path, designed for continuous production use rather than one-off tracing; testbed evaluation for overhead characterization plus real deployment experience.
• Where applicable: Linux hosts running latency-sensitive services. The deployment context is Cloudflare's CDN, but the technique is general Linux tooling — applicable to any production fleet where you need to attribute latency between NIC, kernel, and application.