How the ExtraHop system calculates TCP round-trip times (RTTs)

tcp
rtt

#1

(copy / paste of a post by Dr. Snaut on the old ExtraHop forum. I find myself referring to the old post so I thought I’d bring it into the new forums --gumby)

The ExtraHop system TCP round-trip time calculation is based on the Van Jacobsen method and RFC 1323, which proposes improvements to it. Section 3 of RFC 1323 describes the method in detail and suggests a couple of improvements on top of it: http://www.ietf.org/rfc/rfc1323.txt

The general premise of the RTT calculation is that in general case each sent packet is acknowledged immediately. So the most simple algorithm for round-trip time estimation performs the following sequence of tasks:

  1. Calculate RTT from ExtraHop to server
  • Note when a packet arrived on its way from client to server
  • Wait for an acknowledgment for that packet from server
  • Time the difference between these two events and divide by 2
  1. Calculate RTT from ExtraHop to client
  • Note when a packet arrived on its way from server to client
  • Wait for an acknowledgment for that packet from client
  • Time the difference between these two events and divide by 2
  1. Combine the measurements from steps 1 and 2 for end-to-end RTT time

However, some factors can affect accuracy of this basic algorithm. As a result, certain measurements are excluded from analysis:

  • If the link is lossy and the acknowledgment is lost, RTT time will be overestimated. As a result, when packet loss is detected, RTT measurements associated with this event are discarded.
  • If the TCP Delayed Acknowledgments option is on, acknowledgments are not sent immediately. As a result, when this option is present, some RTT measurements on such a connection may be discarded. However, the SYN-SYN_ACK and FIN-FIN_ACK combination of packets is never delayed, even when the TCP Delayed Acknowledgments option is on, so it is possible to estimate RTT times even in this case.

Differences between Round Trip Time, Request or Response Transfer Time and Processing Time
#2

Thank you for this, these are excellent metrics to have and understanding them is important as well. Does ExtraHop have a way to monitor and graph TCP connection timing? I currently use another product to obtain a better view of congestion within the delivery path. This is very important for obtaining visibility into packet delivery timing and congestion within the path an application is delivered and is different from RTT because this is measuring the RTT of the smallest packets within a TCP connection (close to ICMP messages, but up one layer and can see effects of QoS and other buffering,) TCP connection time (network separate from server) is defined as the below:

The Network Connection Time (NCT) metric provides the average value measurements of the packets involved in last two network legs of the TCP connection setup (excluding Server Connection Time (SCT)) involved in the TCP 3-way handshake (SYN->, SYN/ACK<-, ACK->). So to try be clear, NCT is the time measurement between the SYN/ACK and ACK and SCT is the time measurement of the SYN and SYN/ACK.
Connection Time = Serialization Delay + Queue Delay + Forwarding Delay + Distance Delay