Loading full navigation.

Autonomous IT is here. The alert loop ends now. LEARN MORE

Partners

Docs

LM Academy

LM Community

Pricing

Platform
Solution
Industry
Role
There is no result.

LOGICMONITOR BLOG

TCP RTT and Retransmissions: How Round-Trip Time Affects Recovery

RTT and retransmissions flag trouble but never name the cause. See how to read them together to pinpoint where loss or delay enters your global network.

6–9 minutes
Denton Chikura

NEWSLETTER

Subscribe to our newsletter

Get the latest blogs, whitepapers, eGuides, and more straight into your inbox.

SHARE

The quick download:

TCP RTT and retransmissions are signals worth investigating on their own terms. Reading them together, alongside loss, routing, and application data, is what tells you where a problem actually is.

  • RTT measures the time between sending a TCP segment and receiving the acknowledgment that covers it. Ping and traceroute measure path delay using their own probes; neither one sees a live connection’s congestion window, retransmission history, or timer state

  • Retransmissions come from different mechanisms, including fast retransmit, SACK-based recovery, and RTO expiry, and each one points to a different condition

  • RTO is calculated fresh for each connection from smoothed RTT (SRTT) and RTT variation (RTTVAR), so a stable path settles near the implementation’s floor while a jittery or long-haul path carries a wider safety margin

  • Compare RTT and loss across the affected regions and ISPs, then correlate that pattern with infrastructure telemetry from the same window

A retransmission spike could indicate packet loss, reordering, path instability, or delayed endpoint processing. A slow page could share those causes, or it could come from an application that is simply taking too long to respond. Before you can fix either problem, you have to separate the signals. That starts with understanding what TCP RTT measures and what it does, and does not, explain about retransmissions.

A few terms worth pinning down first:

  • RTT (round-trip time): the elapsed time between sending a TCP segment and receiving an acknowledgement that covers it.
  • RTO (retransmission timeout): TCP’s estimated waiting period before it falls back to timeout-based recovery.
  • Retransmission: TCP sending unacknowledged data again after inferring that it was lost.


RTT, packet loss, retransmissions, and application response time are related, but they are not interchangeable measurements. They need to be analyzed together, not read as proxies for one another.

What TCP RTT measures

TCP measures RTT directly: the interval between sending a segment and receiving the acknowledgment (ACK) that covers it.

The three-way handshake that opens a TCP connection gives you a clean, observable RTT sample:

  • Computer A sends a SYN packet to computer B. This is where the RTT timer starts.
  • Computer B replies with a SYN-ACK. This is where the RTT timer for that exchange ends.
  • Computer A sends the final ACK, and the connection is established.


That handshake timing is real and observable, but it’s only a single sample of connection-establishment delay. It doesn’t expose the sender’s internal SRTT or RTO values; those are computed and maintained inside the TCP stack over the life of the connection, and a single capture only shows the outside of that process.

Is RTT the same as ping?

No. Ping measures round-trip time using ICMP echo messages, and traceroute uses ICMP, UDP, or TCP probes depending on the implementation. Both are useful for isolating path delay, but neither one samples the same thing as an active TCP connection’s own RTT measurement. A ping to a host can look fine while a TCP connection to that same host is timing out retransmissions, because ping never sees that connection’s congestion window, retransmission history, or timer state.

When TCP retransmits data

TCP retransmits when it infers that previously sent data has been lost or has not been successfully acknowledged. That inference can come from more than one mechanism, and they behave differently.

  • Fast retransmit / fast recovery (RFC 5681): When out-of-order data arrives, the receiver normally sends a duplicate ACK indicating the next sequence number it expects. In classic fast retransmit, three duplicate ACKs cause the sender to retransmit the apparently missing segment without waiting for the RTO.
  • SACK-based recovery (RFC 6675): Selective acknowledgements, defined in RFC 2018, let the receiver report exactly which blocks of data it has, not only the highest in-order byte. That extra precision can help a sender recover faster and more accurately when multiple segments are lost in the same window. Not every TCP stack implements SACK-based recovery the same way, and some connections do not negotiate SACK support at all.
  • RTO recovery: When the sender does not receive enough duplicate ACKs or SACK information to trigger the mechanisms above, the retransmission timer eventually expires, and TCP retransmits the earliest unacknowledged segment.


Modern implementations may instead use RACK-TLP (RFC 8985), which uses time- and ACK-based loss detection rather than duplicate-ACK thresholds. Its Tail Loss Probe mechanism solicits ACK feedback to reduce reliance on full RTO expiry.

Congestion control is not a separate retransmission trigger. It is a distinct mechanism that adjusts how much and how fast TCP sends in response to an inferred loss or congestion signal. It changes sending behavior, but it does not cause retransmissions on its own.

How TCP calculates retransmission timeout

RTO is an estimate, calculated fresh for each connection, and RFC 6298 defines the algorithm behind it. RFC 9293, which obsoletes the older RFC 793, confirms RFC 6298 as the current standard for computing RTO.

Before a connection has its first RTT sample, RFC 6298 sets the initial RTO at one second. Some implementations use a more conservative starting value.

Once measurements arrive, TCP tracks two running values:

  • Smoothed RTT (SRTT): an exponentially weighted average of RTT samples.
  • RTT variation (RTTVAR): how much those samples are actually varying, not just their average.


RFC 6298 updates them on every eligible sample using:

RTTVAR = (1 − β) × RTTVAR + β × |SRTT − R′|

SRTT = (1 − α) × SRTT + α × R′

where R′ is the new RTT sample, α = 1/8, and β = 1/4.

RTO is then recalculated as:

RTO = SRTT + max(G, K × RTTVAR)

where G is the clock granularity and K is a fixed constant of 4. If that comes out below one second, RFC 6298 rounds it up to one second.

Each time the retransmission timer expires, TCP doubles the RTO before retrying rather than trying again at the same interval, an approach called exponential backoff. A connection with a one-second RTO that keeps missing its ACKs backs off to two seconds, then four, then eight, roughly doubling with each attempt until it gives up or gets a response. A fixed three-second start with a hard three-retry limit doesn’t apply: RFC 6298 set the one-second floor, and how many times a stack retries before giving up is implementation-specific rather than fixed.

That floor is also OS-dependent in practice. Linux has historically defaulted to a 200ms minimum RTO, and Windows to 300ms. 

A stable path with low RTT variation settles near that floor. A jittery or long-haul path needs a wider margin, because RTTVAR is what keeps normal variation from triggering a premature timeout. A fiber connection from New York and a congested mobile connection from London, both talking to the same server in Los Angeles, will land on very different RTO values for exactly this reason: distance, peering, and last-mile type all show up in RTTVAR before they show up anywhere else.

RTT samples after retransmission

If TCP retransmits a segment and then receives an ACK, it cannot always be certain which copy of the segment, the original transmission or the retransmission, that ACK is actually acknowledging. Because of that ambiguity, TCP ordinarily discards the timing of that exchange rather than using it as an RTT sample. This is Karn’s Algorithm, which RFC 6298 requires TCP to use..

When TCP timestamps are in use, the echoed timestamp can disambiguate which transmission instance triggered the ACK, allowing a valid RTT sample to be taken, as RFC 6298 permits.

A packet-capture example

Wireshark is the standard tool for seeing this behavior directly, and its tcp.analysis filters flag it automatically:

  • tcp.analysis.ack_rtt shows the calculated RTT for a given ACK.
  • tcp.analysis.retransmission flags a retransmitted segment.
  • tcp.analysis.duplicate_ack flags the duplicate ACKs that drive fast retransmit.


A typical capture shows one of two patterns. In the first, a data segment goes out, later segments generate duplicate ACKs or SACK evidence, and the sender retransmits the missing segment well before its RTO would have expired: fast recovery working as intended. In the second, no useful ACK feedback arrives in time, the retransmission timer runs out, and TCP retransmits the earliest unacknowledged segment on its own, with the tcp.analysis.retransmission flag on that later frame and the elapsed time between the original send and the retransmit matching the connection’s current RTO.

Either pattern is worth reading alongside sequence numbers, duplicate ACK count, SACK blocks, and path conditions during that window. A capture shows you that recovery happened and roughly how. It takes other measurements, like loss rates by region or ISP, or application response time from the same window, to say why.

How to investigate elevated RTT and retransmissions

  • Compare RTT and loss by user region, ISP, path, and time window.
  • Check whether retransmissions align with packet loss, reordering, host or interface saturation, receiver-side delay, or path instability. These conditions can produce different but overlapping patterns.
  • Correlate those findings separately against application response time.
  • Separate connection-establishment delay from data-transfer delay.
  • Combine outside-in path measurements with host, network, and application telemetry.
  • Use packet capture selectively to test or refine a hypothesis, not as standalone proof.


The aim is to move from “retransmissions increased” to a defensible explanation of where loss or delay is being introduced.

Where this leads

TCP RTT and retransmissions are diagnostic inputs. Read alongside loss, routing, infrastructure health, receiver behavior, and application performance, they tell you where to look next. A rising retransmission count on its own is a prompt to investigate, and confirming the cause takes the rest of that context.

This is where LogicMonitor Digital Experience extends the workflow above: correlating RTT and loss trends across regions and paths with infrastructure and application telemetry from the same window, instead of reconciling separate tools by hand.

A practical next step: compare RTT and loss across the affected regions or ISPs, then correlate that pattern with infrastructure telemetry over the same period.

Correlate RTT, loss, and application telemetry in one place

LogicMonitor Digital Experience gives you the same outside-in synthetic visibility behind the examples in this post, so you can trace where loss and delay enter your paths across every region without stitching separate tools together by hand.

FAQs

What is the difference between RTT and RTO in TCP?

RTT is the measured elapsed time between sending a segment and receiving the acknowledgement that covers it. RTO is TCP’s estimated waiting period before it falls back to timeout-based recovery, calculated from smoothed RTT (SRTT) and RTT variation (RTTVAR). RTT is a direct measurement, while RTO is an estimate derived from those measurements.

Does a spike in retransmissions always mean there is packet loss?

A retransmission spike has several possible causes, including packet loss, reordering, path instability, host or interface saturation, and delayed endpoint processing. You need to correlate retransmissions with loss, path conditions, and application response time before naming a cause. On their own, retransmissions tell you to investigate rather than confirming where the problem sits.

Why does TCP sometimes ignore RTT samples after a retransmission?

After a retransmission, TCP often cannot tell whether an incoming ACK is acknowledging the original segment or the retransmitted copy. Because of that ambiguity, Karn’s Algorithm has TCP discard the timing of that exchange rather than treat it as an RTT sample. When TCP timestamps are enabled, the echoed timestamp can disambiguate the two and allow a valid sample to be taken.

By Denton Chikura

Content Marketing Manager

Denton Chikura is a Content Marketing Manager for LogicMonitor Digital Experience, where he drives content on observability, Internet performance, and digital experience. He writes for SREs, IT operations teams, and business leaders, turning performance data into guidance they can act on.

Disclaimer: The views expressed on this blog are those of the author and do not necessarily reflect the views of LogicMonitor or its affiliates.

© LogicMonitor 2026 | All rights reserved. | All trademarks, trade names, service marks, and logos referenced herein belong to their respective companies.

Related Blogs

Optimizing Website Performance: Harnessing the Power of Image Lazy Loading
Blog Digital Experience

Optimizing Website Performance: Harnessing the Power of Image Lazy Loading

Image lazy loading can speed up your site, or slow it down. Learn how to apply it selectively, protect Core Web Vitals, and measure the real-world impact.
October 30, 2026
Learn more
Outage Retrospective: What a Google Cloud Incident Revealed About Hidden Service Dependencies
Blog Internet Performance Monitoring

Outage Retrospective: What a Google Cloud Incident Revealed About Hidden Service Dependencies

See how a Google Cloud outage took major brands like Home Depot offline, and why digital experience monitoring spots failures before status pages update.
October 30, 2026
Learn more
Outage Retrospective: How the Adobe Experience Cloud Outage Exposed Third-Party Blind Spots
Blog DevOps & CI/CD

Outage Retrospective: How the Adobe Experience Cloud Outage Exposed Third-Party Blind Spots

See how Internet-health signals, synthetic tests, and Real User Monitoring exposed third-party failures during the 2023 Adobe Experience Cloud outage, and how LogicMonitor Digital Experience connects those perspectives to help teams identify user impact and incident ownership.
October 30, 2026
Learn more