PacketShaper tracks the course of a client-server transaction and uses information about a TCP connection to differentiate one portion of the exchange from another.
From its position between the client and server, PacketShaper makes transmission time and size observations during a transaction. Then, PacketShaper incorporates TCP basics to render accurate performance figures.
The following illustration shows the path of a TCP transaction over time. Arrows indicate packets traveling between the client and the server. As you progress down this diagram, you’ll see that time increases, with successive events’ times noted as TN, with T1 representing the first event and T22 representing the last event.
A client initiates a server connection with a SYN (synchronize sequence numbers flag) at time T1. PacketShaper notes the SYN at time T2 and passes it along to the server. The server responds with a SYN-ACK (acknowledge flag) at time T3. PacketShaper notes the SYN-ACK at time T4 and passes it back to the client.
TCP stacks usually respond with a SYN-ACK very rapidly, within the kernel and with no context switches. The SYN-ACK follows the SYN almost immediately. Therefore, time T4 minus time T2 gives an accurate measure of the round-trip network delay between PacketShaper and the server. This interchange provides the server transit delay (STD):
STD = T4 - T2
The client receives the SYN-ACK and issues the final ACK of the three-way handshake at time T5. PacketShaper notes the ACK at time T6, passing it along to the server.
Assume that no processing transpires between the client's receipt of the SYN-ACK and its own corresponding ACK at time T5, as this is handled within the kernel. Time T6 minus time T4 yields an accurate measure of the round-trip network delay between the client and PacketShaper, which provides the client transit delay (CTD):
CTD = T6 - T4
The server transit delay and the client transit delay yields the total delay between the client and the server for a single round trip:
RTT (Round-Trip Time) = STD + CTD
The client initiates its request at time T8, arriving at PacketShaper at time T9. The TCP illustration eliminates the server’s corresponding ACKs to simplify the picture, because these ACKs are not relevant to PacketShaper’s calculations. The last request packet, sent at time T11, sets its Push Flag to one (1) to indicate that it is the final packet. PacketShaper notes the time of this last request packet at T12.
The last request packet arrives at the server at time T13. The server assembles and processes the request, assembles a response, and sends the first packet (there may be several response packets) at time T14. Time T14 minus time T13 is the actual server-processing time required for the request. These times are not visible to PacketShaper.
PacketShaper knows the server’s processing time occurred after PacketShaper saw the last request packet and before PacketShaper saw the first response packet (time T15 minus time T12). PacketShaper also knows that the transit time from PacketShaper to the server and back again (the server transit delay) is another component of this interval.
In addition, a small amount of time is spent serializing the bits in the response packet and preparing them for the bit stream. This time is not included in the original server transit delay because the SYN and ACK packets are extremely small. PacketShaper knows the size of the packet, calculates this preparation time accordingly (D1), and adds it to the server transit delay (STD) before subtracting the sum from the time difference.
Therefore, the server delay is calculated as follows:
Server Delay = (T15 - T12) - (STD + D1)
The termination of a transaction is key to calculating the total delay; however, it is not always obvious when a transaction has ended. The combination of the Push Flag from the server and the ACK from the client provides one way of signaling an end, but it is not necessarily the actual end of the transaction. Often applications with long transactions insert Push flags throughout the transaction.
Therefore, in addition to monitoring Push Flags, PacketShaper uses a timer to track transactions. PacketShaper also checks the following conditions to determine if a transaction has truly ended:
Since the network delay is derived from the total delay, the method for determining total delay impacts the network delay measurements.
In the illustration shown above, PacketShaper notes the last response packet at time T18, and makes sure that it saw all required ACKs for the request packets. It also checks the conditions listed above to determine if the transaction has truly ended.
The client receives the final response packet at time T19 and sends an ACK. The ACK reaches PacketShaper at time T21. The client’s perspective of response time starts with sending the first request packet (T8) and ends with receipt of the final response packet (T20). PacketShaper sees that interval as time T9 until time T21. This estimate of the client’s view is missing some extra preparation time for serializing the first request packet, assuming that the first request packet is larger than the final ACK. PacketShaper knows the packet-size difference and calculates this small discrepancy (D2).
The total delay is calculated as follows:
Total delay = (T21 - T9) + D2
Since total delay is a function of transaction size, do not attempt to compare ping times to RTM measurements.
Using the server delay and the total delay, PacketShaper calculates the amount of time the transaction spent in transit:
Network delay = (Total delay) - (Server delay)
The network delay reflects all transit time for the transaction. If the transaction’s data is large, multiple packets go to and from the server. Only the network delay reflects this overhead. The network delay is not necessarily a multiple of the RTT because multiple packets are not sent consecutively and may overlap to varying degrees.
PacketGuide™ for PacketWise® 8.3