Size matters with TCP

What happened

It has been reported that while testing a gopher client, downloads consistently stalled at about 13 kilobytes — sometimes barely noticeable, sometimes a full-second hang. Annoying, right? The presenter noticed the weird plateau and chased it down to TCP's startup behavior, a small-but-painful quirk that still trips up modern transfers.

Why 13 KB

Here’s the crux: TCP breaks data into packets and uses acknowledgments to pace traffic. On connection start the "slow start" algorithm typically opens the congestion window to roughly 10 packets. In the tester’s trace most packets carried ~1,368 bytes of TCP payload, so 10 packets works out to ~13.2 KB. Why that particular number? Because packet size (MSS/MTU) and the initial window set by TCP implementations do the math for you. Variation along the path — different link types, VLANs, and MTU tweaks — can nudge that number up or down, but the principle is the same.

Why it still matters

TCP’s cautious ramp-up exists for a reason: congestion collapse was a real problem in the 1980s, and congestion control kept the internet from breaking again. But conservative defaults have trade-offs. On high-latency links you may need multiple round trips to exceed that tiny initial quota, so a small transfer can feel sluggish even on gigabit pipes. Retransmissions, duplicate ACK handling, slow-start resets after timeouts — they all interact and can turn a tiny design choice into a visible hiccup.

Takeaway

Size really does matter, even in a world of fat pipes. If you see a recurring ~13 KB stall, don’t assume your wire is busted — it might just be TCP doing its job too politely. Short-term fixes include tuning initial windows or MTU/MSS, and longer-term changes are already under way in protocols like QUIC or TCP variants that boost startup behavior. Little knobs, big user-facing effects.

Sources: maurycyz.com, Lobsters