Calculation of Flowmon NPM Metrics

This chapter explains in detail how the following NPM (Network Performance Monitoring) metrics are being calculated by the Flowmon Probes:

• RTT - Round Trip Time

• SRT - Server Response Time

• RTR - Retransmissions

• OoO - Out of Order packets

All the NPM metrics are provided with microsecond precision.

Round Trip Time (RTT)

Round Trip Time represents network delay (packet going from client to server and back). It is available for TCP-based network communication and measured by observing the TCP handshake.

1. Server Network Time = time difference between first two packets of TCP handshake: SYN packet and SYN-ACK packet

2. Client Network Time = time difference between the second and third packet of TCP handshake: SYN-ACK packet and ACK packet

3. RTT = Server Network Time + Client Network Time

Server Response Time (SRT)

Server Response Time is measured for all TCP flows and UDP flows with DNS traffic (that is, UDP flows where one of the ports is 53). All time measurements are done in microsecond precision.

TCP Flows

The client and server are distinguished based on who sent the SYN packet (client) and who sent the SYN+ACK packet (server). The measured Server Response Time expresses the time difference between the predicted observation time of the server’s ACK packet (this prediction is based on the observation time of the client request and previously measured server network time) and the observation time of the server’s response. The measurement cannot rely on observing an ACK packet from the server before its response because the ACK packet might be merged with the server response. If the server’s response packet is captured before a client’s request packet, then the SRT = 0.

1. If, and only if, the L4 protocol is TCP, measure server network time tsnt as the time difference between observations of client’s SYN and server’s SYN+ACK packets in TCP handshake.

2. 1. For all TCP traffic except TLS and SMB protocol: Measure the time difference ∆trr between the first observation of the server’s response (2) and observation of the latest (3) preceding client’s request (1).

   2. For TLS protocol: Skip the TLS handshake and measure the time difference ∆trr between the first observation of server’s TLS Application data response and observation of the latest (3) preceding client’s TLS Application data request.

   3. For SMB protocol: Skip the SMB session initialization and measure the time difference ∆trr between the observation of server’s response and observation of the latest (3) preceding client’s request. The following SMB requests are not applicable for determining SRT: Negotiate, Session Setup, Logoff.

3. Server Response Time tsrt = max(0, ∆trr − tsnt) (4), if ∆trr is not measured at time of flow export, then tsrt = 0.

DNS (UDP) Flows

The client and server are distinguished based on whether 53 is the source port (server) or destination port (client). The measured Server Response Time expresses the time difference between the observation times of the client’s request and the server’s response. The measurement algorithm for DNS (UDP) flows is similar to steps 2 and 3 in the TCP measurement. If the server’s response packet is captured before a client’s request packet, then the SRT = 0.

1. Measure the time difference ∆trr between the first observation of the client’s request (1) and the first subsequent observation of the server’s response (2).

2. Server Response Time tsrt = ∆trr, if ∆trr is not measured at the time of the flow export, then the tsrt = 0.

(1) Any packet from the client containing application layer data is recognized as a request.

(2) Any packet from the server containing application layer data is recognized as a response.

(3) A client’s request can contain multiple packets. In this case, use the observation time of the last client’s packet received.

(4) If the L4 protocol is not TCP, the SYN and SYN+ACK packets were observed out of order, or any of them were not observed, then the tsnt is defined implicitly as tsnt = 0.

Retransmissions (RTR) and Out of Order packets (OoO)

Retransmissions or Out of Order packets represent a situation when data packets are not correctly delivered between communication parties and need to be resent or reassembled. This calculation is complex and is explained by the following algorithm.

Used terms:

• SEQ - sequence number of a TCP packet.

• ACK - acknowledgment number of a TCP packet.

• threshold - initial Round Trip Time (measured in TCP handshake) or 3 milliseconds (if RTT is not available).

• TCP KEEPALIVE - If segment length = 0 or 1 and current SEQ = expected SEQ - 1 and the packet does not have SYN, FIN, or RST flag. Then this packet is a TCP keepalive.

• DUPLICATE ACK - If segment length = 0 and the packet does not have SYN, FIN, or RST flag and the window and ACK numbers are the same as in the previous segment and current SEQ = expected SEQ. Then this packet is a duplicate ACK.

Evaluation algorithm

Process only packets with data length > 0 or packets with SYN or FIN flag set. Skip TCP KEEPALIVE packets.

(When some of the following conditions are met, the processing of the current packet ends. Conditions are executed in the following order.)

• Is it FAST RETRANSMISSION? - If current SEQ < expected SEQ and there was more than1 DUPLICATE ACK in the reverse direction (explained later) and the SEQ number corresponds to duplicate ACK numbers and the segment was received at most 20 milliseconds after the last duplicate ACK packet, then this packet is a (fast) Retransmission.

• Is it OUT-OF-ORDER? - If current SEQ < expected SEQ and segment received at most "threshold" milliseconds after last segment with the highest sequence number and current SEQ + segment length != expected SEQ (otherwise it would be Retransmission of the last packet), then this packet is Out of Order.

• Is it SPURIOUS Retransmission? - If the current segment length > 0 (packet contains data) and the current SEQ + segment length <= the last ACK (this segment was already ACKed), then this packet is a (spurious) Retransmission.

• Is it RETRANSMISSION? - If current SEQ < expected SEQ. Then this packet is a (classic) Retransmission.

The final Retransmission count is the sum of all Retransmissions detected as described above.