In Analyzing TCP sessions, best practices, Different ways to troubleshoot

This is the 2nd post (in a series of 5) about analyzing the healthy and not-so healthy starts and endings of a relationship. This approach is the core of our best practices as TCP relationship therapists for cloud services, applications and networks.

All 5 posts are also available in one convenient PDF; click here to get your copy.

During the 1st post, you learned how to identify the healthy relationships based on a few KPI’s (Key Performance Indicators) and its thresholds. Again, base-lining these KPI’s is highly recommended as a starting point for managing the SLO’s (Service Level Objectives) on your cloud services and applications.

In this post you will learn how to identify and analyze the not-so healthy starts of a relationship and how this impacts the user experience; potentially even a complete application chain. The case study about a Health-check on a Citrix/SAP environment clearly shows how such behavior between the Citrix client and the Netscaler indeed impacts the complete application chain!

The time needed for starting a relationship should be far less than the sum of the client- and server-side RTT (Round Trip Time). This is because the 3-way handshake SYN | SYN-ACK | ACK is handled by the network card; OS involvement is close to zero and is limited to updating its session table.

The SYN, SYN-ACK and ACK in one go indicating a healthy start of a relationship

This time is also known as the CT (the Connect Time). The example with the 2 hosted e-mail services shows you that the CT is indeed far less then aggregated RTT (i.e. “∑ RTT”) for the given client- and e-mail servers.

Comparing the connect time with the sum of the RTT

If the server-side is not responding fast enough on the initial SYN, then the client-side will retry a few times by sending the same SYN. If still no response, an error message is returned indicating that the server-side is not available.

Similar on the server-side: if the client is not responding fast enough to the initial SYN-ACK, the server will retry a few times by sending the same SYN-ACK. If still no response, the server-side sends a RST telling the client to start from scratch. If again no response from the client-side, the server-side gives-up and removes things from the session table.

A not-so healthy session start

A not-so healthy start of a relationship

Such a not-so healthy start of a relationship is recognized by a CT that is close or even higher than the values in the column “∑ RTT” (the sum of the client and server RTT). In addition, the value in the column “x SYN” is greater than 1.00; for example 1.14 or 3.12.

If such values are persistent for one or more of your cloud services and applications, then there is definitely room for improvements on the overall user experience! This is particular true if the column “% Retrans.” is showing values higher than 3% for a longer period of time.

Evaluating the values in the columns “# SYN”, “# Conn.” and “x SYN”

The case study on the Citrix/SAP environment shows clearly how this behavior impacts the user experience. Here, persistent, not-so healthy relationships between the Citrix clients and the Netscalers resulted in erratically, non-responsive behavior of the whole application chain. Part of which were several seconds of additional delays on the user response times.

This completes the 2nd post in which you have learned how the not-so healthy starts of a relationship impacts the user experience.

What is covered in the next episode

The upcoming posts are covering the not-so healthy endings of a relationship as well as 6 easy steps discovering the low hanging fruit for getting healthy relationships (again):

  • How the not-so healthy relationship endings impact the user experience (part 3)
  • How to get healthy relationships (again) (part 4)
  • How this works for streaming, multimedia type of applications (part 5)

As mentioned earlier, all 5 posts are also available in one convenient PDF; click here to get your copy.