Network architecture design is not just about capacity planning or selecting technologies. At times, you need to go deeper — literally a few feet below the surface. This thinking is also where the name 5Feet Networks comes from.
This depth becomes critical in two phases of change:
a) before network changes (identifying the real problem)
b) after changes (verifying the impact)
Without this level of visibility, there is a real risk of solving the wrong problem — or worse, investing in capacity that does not improve user experience.
In this article, we examine a common phenomenon in modern networks: TCP retransmissions — and why they don’t always mean what we assume.
Observation: retransmissions are increasing, but capacity is not the issue
Analytics showed a significant number of TCP retransmissions. This means the sender does not receive an acknowledgment (ACK) as expected and retransmits the data.
The natural first reaction is to suspect:
- lack of capacity
- core network bottlenecks or MTU issues
- packet drops in routers or firewalls
However, deeper analysis showed:
- no significant packet loss at the infrastructure level
- traffic volumes were moderate
- no signs of saturation
It is important to note that even if infrastructure counters appear clean, micro-loss can still occur — especially in wireless environments or due to buffer behavior — without being visible as IP-level drops.
In other words: the network was not “full.”
TCP behavior has changed
The key explanation lies at the protocol level.
In traditional TCP, retransmissions were triggered mainly by:
- timeout (RTO)
- multiple duplicate ACKs
This made TCP conservative — retransmissions only occurred when packet loss was likely.
Modern implementations (RACK, TLP) and QUIC behave differently:
- loss is inferred based on timing (RTT)
- retransmissions are triggered proactively
- reactions are more aggressive
As a result, retransmissions can occur without actual packet loss.
These are known as spurious retransmissions. However, it is important to recognize that not all retransmissions are spurious — especially in WLAN environments, many are fully justified.
What would traditional TCP have done?
- waited longer before retransmitting
- tolerated small delay variations better
- reacted more slowly
Result:
- fewer retransmissions
- but potentially significantly higher latency
Modern protocols do the opposite:
they optimize user experience — but expose network quality issues much more quickly.
The real root cause: quality, not capacity
Once infrastructure was ruled out, the focus shifted closer to the user — endpoints and the wireless network.
The analysis revealed significant retransmissions already at the WLAN level (WiFi retries), which cause:
- jitter (delay variation)
- packet delay
- packet reordering
Modern TCP and QUIC algorithms easily interpret these conditions as packet loss — and respond with retransmissions.
The network traffic profile has changed
This is not an isolated case — it reflects a broader, permanent shift:
- traffic is increasingly directed to cloud services and CDNs
- applications use aggressive transport protocols
- the role of endpoints and WLAN has increased
At the same time, traffic is:
- bursty
- latency-sensitive
- distributed
In this environment, overall network quality matters more than raw capacity.
The same network may work perfectly for low-latency connections (e.g., local data center), yet still cause issues with cloud traffic.
Short latency hides problems — long latency exposes them.
Why adding capacity doesn’t help
Increasing capacity only helps if the problem is throughput.
In this case, the issue originates:
- before the core network
- in the radio layer
- in delay variation
Additional bandwidth may even mask symptoms temporarily, but it does not:
- remove jitter
- reduce WLAN retries (frame retransmissions at Layer 1)
- prevent packet reordering
What should be done?
The correct approach is not a single technical fix — but understanding the system as a whole.
The first step is identifying where the issue originates, not where it appears. This requires visibility from endpoints to the application layer.
The second step is ensuring consistent quality in the local network. In modern environments, WLAN plays a critical role, and even small disturbances can directly impact user experience.
Only after this can traffic management or other optimization methods be properly evaluated.
Without identifying the root cause, organizations risk:
- making incorrect investment decisions
- increasing costs without benefit
- leaving user experience issues unresolved
A properly targeted analysis, on the other hand:
- identifies the true root cause
- guides investments correctly
- directly improves end-user experience
Summary
TCP retransmissions are not the problem — they are a symptom.
In this case, they were primarily caused by:
- WLAN quality airtime contention
- jitter because incorrect path selection in network
- behavior of modern TCP/QUIC algorithms
What about situations where the network cannot be fixed?
It is important to recognize that in all environments, network quality cannot always be directly improved (or is not under the customer’s control). Such situations include satellite connections, mobile networks (LTE/5G), high-latency WAN links, or environments where only a single unstable link is available.
In these cases, the root cause of the problem — latency, jitter, or packet loss — is not directly controllable by the organization.
An alternative approach is to optimize the behavior of the transport protocol itself. This can be achieved through TCP optimization or proxy-based solutions, where the connection is split (so-called split TCP) and retransmissions and acknowledgements are handled closer to the user.
However, it is essential to understand that these solutions do not eliminate the underlying network quality issue — they compensate for it.
If the network appears to work — but users experience issues — it’s time to look below the surface.
Hannu Rokka
Senior Network Advisor
5Feet Networks Oy