Tailscale, a connectivity platform that links devices into private networks called tailnets, is working on changes aimed at the parts of its system that move or prepare traffic. In a September 22 post, the company said the work covers Linux and Android packet handling, multi-queue processing for subnet routers, app connectors, and exit nodes, plus broader startup improvements through netmap caching.
The first change addresses small packets. Tailscale says most network packets are around 1 KiB, but Linux’s Generic Receive Offload (GRO), a throughput feature that handles larger batches of traffic, expects buffers that can hold 64 KiB. The older path copied each small packet into its own large buffer. On Linux and Android, Tailscale now leaves packets in the larger read and tracks where each one begins and ends, so many small packets can share one allocation. The company reports that this alone produced about a 5% speed-up in many network configurations.
Placed after the explanation of Linux and Android packet handling, where packets remain in a larger read buffer instead of being copied into separate 64 KiB buffers.
The multi-queue work targets nodes that forward traffic for many connections. Subnet routers are gateways between a tailnet and physical subnets, letting devices that cannot run Tailscale join the network; exit nodes route outbound internet traffic through another device. Tailscale says these roles previously processed independent streams in one ordered, single-thread pipeline, partly because a receiving application must not see its own packets arrive out of order. The new design assigns each stream to a lane and runs lanes in parallel across CPU cores, scaling the number of lanes to the machine rather than to the number of peers. The post says app connectors also benefit, but defines them only as Tailscale nodes serving many users with short-lived connections.
Placed after the discussion of subnet routers, exit nodes, and app connectors moving from one ordered pipeline to parallel lanes across CPU cores.
Startup is the other major target. A device normally contacts Tailscale’s control plane, authenticates, and receives a network map, or netmap, describing which devices it can reach and how. That can take about 100 milliseconds on a typical network, but poor airplane Wi-Fi, filtered hotel networks, or other weak connections can delay or block it. With netmap caching, a device that has connected before stores a copy on persistent disk and can begin establishing direct device-to-device connections before it reaches the control plane. Tailscale says warm-cache starts were one to two orders of magnitude faster than cold starts in tailnets with poor control-plane reachability.
The trade-offs are specific. Caching requires a prior successful connection and disk space; very large tailnets may create substantial cache-update traffic, and slow or wear-sensitive storage such as SD cards may be poor candidates. Availability is also staggered: buffer changes are expected in v1.104 for Linux and Android, multi-queue support is planned after v1.104, and netmap caching is currently behind a feature flag before a tested default rollout. The Linux/Android focus is therefore a stated deployment boundary, not proof that the same techniques are impossible elsewhere.