DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
View Events Video Library
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Integrating PostgreSQL Databases with ANF: Join this workshop to learn how to create a PostgreSQL server using Instaclustr’s managed service

Mobile Database Essentials: Assess data needs, storage requirements, and more when leveraging databases for cloud and edge applications.

Monitoring and Observability for LLMs: Datadog and Google Cloud discuss how to achieve optimal AI model performance.

Automated Testing: The latest on architecture, TDD, and the benefits of AI and low-code tools.

Related

  • VPN Architecture for Internal Networks
  • Build Sustainable Applications Using Azure Services
  • Load-Balancing Minecraft Servers with Kong Gateway
  • Using Envoy Proxy’s PostgreSQL and TCP Filters to Collect Yugabyte SQL Statistics

Trending

  • Lost in Communication and Collaboration
  • Best Practices for Writing Clean Java Code
  • Exploring String Reversal Algorithms: Techniques for Reversing Text Efficiently
  • Cognitive AI: The Road To AI That Thinks Like a Human Being
  1. DZone
  2. Software Design and Architecture
  3. Performance
  4. Understanding RTT Impact on TCP Retransmissions

Understanding RTT Impact on TCP Retransmissions

Mehdi Daoudi user avatar by
Mehdi Daoudi
·
May. 07, 14 · Interview
Like (0)
Save
Tweet
Share
7.26K Views

Join the DZone community and get the full member experience.

Join For Free

Ever get asked to explain or elaborate on something that you should definitely know, only to realize that you don’t fully understand it yourself? You’re certainly not alone.

Even though the basics of Transmission Control Protocol (TCP) connections are one of the very first topics covered when learning about computer network fundamentals, many of us are perplexed by retransmission logic and still have no idea what Smoothed Round Trip Time (SRTT) means. But fear not; we’re here to shed some light on them for all levels of speed gurus.

First, we start with Round Trip Time, or RTT. For Ping and Traceroute, this measures the round trip time between sending the Ping packet and getting the ICMP packet back. For TCP connections it is quite similar; it measures the time sending a packet to getting the acknowledgment packet from the target host.

Let’s say you have host A and host B. The TCP Three-Way Handshake is as follows:

TCP Handshake

  1. Computer A sends a TCP SYN packet to computer B (This is where RTT timer begins)
  2. Computer B sends a TCP SYN-ACK packet to computer A (This is where RTT timer ends)
  3. Computer A then sends a TCP ACK packet to computer B (The TCP connection is now established!)

If you are relying on Wireshark to capture and analyze packets, the tool will calculate and display the RTT on the packet containing the ACK. See the last line in the figure below:

RTT in Wireshark

Easy to understand, right? But what happens when a packet is lost? TCP protocol has built-in logic for ensuring that packets are received. Thus, to ensure the packet is received, the sender will retransmit the packet to the other party.

The majority of us are well aware of the primary retransmission logic. On the initial packet sequence, there is a timer called Retransmission Timeout (RTO) that has an initial value of three seconds. After each retransmission the value of the RTO is doubled and the computer will retry up to three times. This means that if the sender does not receive the acknowledgement after three seconds (or RTT > 3 seconds), it will resend the packet. At this point the sender will wait for six seconds to get the acknowledgement. If the sender still does not get the acknowledgement, it will retransmit the packet for a third time and wait for 12 seconds, at which point it will give up.

While this is the most well-known fact of RTO, it is not the only logic in TCP. The TCP protocol was designed to take in consideration that the connection between two computers is not the same – hence the retransmission logic should be quicker for cases where the two computers are close. This where RTT starts impacting RTO.

When the TCP connection is established, there is one RTT value, and the RTO will be adjusted based on the Smoothed RTT (SRTT) calculation. The calculation applies a smoothing factor to the RTT which creates a predicted round-trip time that is beneficial to the assurance of packet delivery. SRTT formula is:

SRTT(ALPHA * SRTT) + ((1-ALPHA) * RTT)

ALPHA = smoothing factor between .8 and .9
RTT = Round Trip Time

Once the SRTT is calculated, it is used as a determining factor of how long the host will wait before retransmitting the segment, which is calculated as RTO below:

RTO = min[UBOUND, max[LBOUND(BETA * SRTT)]]

UBOUND = upper bound on the timeout (e.g. 1 minute)
LBOUND = lower bound on the timeout (e.g. 1 second)
BETA = delay variance factor (e.g. 1.3-2.0)

If no response packet is received after sending the segment, then the RTO is doubled after each re-transmission and the previous re-transmission is ignored in the RTT calculation. This strategy is known as Karn’s Algorithm and is considered to be highly effective, especially in areas with high packet latency.

Take, for example, the packet capture seen here from a Windows client, and the retransmission highlighted:

packet capture with retransmission

In the packet capture above, you can see that in Frame 4 there was a packet sent with length of 1502, and there is a retransmission in Frame 5 due to the lack of acknowledgement from the receiving host. If you dive into the individual frame details, you can find out how long the RTO was set for this particular retransmission:

RTO packet capture

Remember, the new RTO is calculated based on the SRTT, which is based on RTT, which results in an adjustment that is highly effective when experiencing latency on your network. The lowest RTO will vary by operating system (or TCP implementation); in Windows it is 300ms, and in Linux it is 200ms.

In the case of web browsers, the computer opens multiple connections to the same host. For Windows each connection has its own SRTT calculations, so one connection does not impact the other. We have not received confirmation of this for Linux, but probably it is the same.

The Smoothed RTT retransmission logic exists to ensure that the Retransmission Timeout is based on the connectivity between the two machines in communication, and to ensure that users do not experience long latency when there is congestion in a low latency connection. So for example, connections from New York Fiber and London 3G to a server in Los Angeles are going to vary significantly based on distance, peering, and type of connection – thus deserving separate RTO calculations. After all, why would you apply the same RTO to all cases when it could be adaptively changed to the behavior of your network?

If it wasn’t for the application of these accurate predictions then you would experience even more latency on your network due to unnecessary retransmissions.

Transmission Control Protocol

Published at DZone with permission of Mehdi Daoudi, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • VPN Architecture for Internal Networks
  • Build Sustainable Applications Using Azure Services
  • Load-Balancing Minecraft Servers with Kong Gateway
  • Using Envoy Proxy’s PostgreSQL and TCP Filters to Collect Yugabyte SQL Statistics

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends: