I have now done a deeper packet-level analysis with a 2-hour PCAP captured on the LAN side of the SSR, using a SPAN of the EX4000 uplink toward the SSR.
The result changes my original interpretation.
The TCP retransmissions are real, but in the analyzed streams they are not caused by packet loss on the WAN or by SSR forwarding.
In one representative TCP stream, the client generated a long Dup ACK / SACK sequence and the server responded with multiple Fast Retransmissions. However, the original TCP segments that the client later reported as missing were all already visible in the PCAP on the SSR–EX4000 uplink before the retransmissions occurred.
This means that, at least for the analyzed case, the loss or excessive delay occurs after the SSR/LAN capture point, not on the WAN side.
The affected endpoint is a WLAN client, and Mist Wireless Analytics also shows unusually high 802.11 retry levels on several APs. Coverage is good, client counts are low, and RSSI/SNR are healthy, so this now looks much more like a WLAN-layer issue than an SSR/Premium Analytics metric problem.
A possible chain is: 802.11 retries / delayed or failed frame delivery → TCP sequence gap at the client → Dup ACK/SACK → Fast Retransmission.
So my current conclusion is that Mist Premium Analytics is probably reporting genuine TCP retransmissions correctly. The misleading part was assuming that the retransmissions implied WAN packet loss.
The remaining question is now on the WLAN side: why are 802.11 retry rates so high in a new Mist deployment with good RF conditions and low client density? We are looking at AP firmware, 6 GHz behavior, client rate adaptation, Block ACK/A-MPDU handling and possible driver/telemetry issues.
So for this case, SSR / WAN does not currently look like the root cause; WLAN is the primary suspect.
------------------------------
Hannu Rokka
Senior Advisor (DataCom)
------------------------------
Original Message:
Sent: 08-24-2026 01:34
From: Hannu
Subject: SSR / Mist Premium Analytics: TCP Retransmissions scaling with traffic – Architectural metric misinterpretation?
Thanks. Disabling SACK is not really practical in our production environment, as the endpoints are mainly Windows, Apple, and various IoT devices.
We have also not observed abnormal TCP RST behavior. Applications are working normally, latency is around 1 ms, packet loss and jitter are essentially zero, and the SSR interfaces show no errors or drops.
What makes this interesting is that we see relatively high retransmission figures not only in Mist Premium Analytics but also when analyzing other networks with TAP & Network Analyzer. In many otherwise healthy networks, the traditional rule of thumb that retransmissions above roughly 1–2% indicate a network problem no longer holds.
This raises a more fundamental question: "Are all events reported as "TCP Retransmissions" actually true TCP retransmissions caused by packet loss, or are some of them other TCP behaviors being grouped under the same metric?"
For example, packet analysis can distinguish between:
* normal retransmissions
* fast retransmissions
* spurious retransmissions
* out-of-order packets
* duplicate ACKs
* SACK/DSACK-related recovery behavior
* RSTs
A spurious retransmission, for example, does not necessarily indicate packet loss. The sender may retransmit data that has already arrived due to reordering, delayed ACKs, short-lived queuing, or TCP recovery behavior.
Therefore, before using a fixed percentage as a quality threshold, I think we first need to understand exactly what the metric represents.
For SSR specifically, the key question is:
What is the exact telemetry source and calculation behind Premium Analytics "TCP Retransmissions"? Does it count only actual repeated TCP sequence numbers observed on the wire, or does it also include spurious retransmissions, out-of-order/recovery events or other SSR session-level telemetry?
This is especially relevant because SRX/MX are Junos-based platforms, whereas SSR uses the Session Smart architecture and its own session-oriented telemetry. It would be useful to know whether the same metric name refers to the exact same underlying event on both platforms.
A packet capture comparison would be useful, but the important first step is to understand whether we are really comparing **TCP retransmissions to TCP retransmissions**, or one aggregated analytics metric to several different TCP behaviours.
------------------------------
Hannu Rokka
Senior Advisor (DataCom)
------------------------------
Original Message:
Sent: 08-23-2026 22:59
From: Anonymous
Subject: SSR / Mist Premium Analytics: TCP Retransmissions scaling with traffic – Architectural metric misinterpretation?
This message was posted by a user wishing to remain anonymous
Disable SACK, do replays still occur? Are TCP RST's happening?