Client TCP Test

This test reports on the performance of TCP traffic to/from a client desktop. The performance of the TCP layer is impacted significantly by network performance issues - packet loss, congestion, connectivity failures, etc. Hence, by observing the performance at the TCP layer, administrators can easily determine if there is a network issue or not. Since the client desktop may be using different network paths to access different servers, the TCP performance has to be assessed for each server or server group. This test can be executed on Windows boxes only.

Target of the test : A Microsoft Client Desktop

Agent deploying the test : An internal agent

Outputs of the test : One set of outputs for every specification against the RemoteServers parameter; if the DynamicServers specification is uncommented, then one set of results will be reported for every IP address that is being accessed by the client desktop via each of the configured ports.

Configurable parameters for this test
Parameter	Description
Test Period	How often should the test be executed.
Host	The host for which the test is to be configured.
Adapter Device Selection	By default, the eG agent automatically discovers the interface that is to be used for packet capture. This is why, the Adapter Device Selection flag is set to Automatic by default. However, if you want to manually override this discovery process, then, you can do either of the following: Set the Adapter Device Selection flag to Manual, (OR) Edit the eg_desktop.ini file (in the <EG_AGENT_INSTALL_DIR>\agent\config directory) to manually configure the adapter you want the test to use. Both these options have been discussed below: Setting the Adapter Device Selection flag to Manual If this is done, then two new parameters, namely - device name and device id – will automatically appear in the test configuration page. Click on the Discover button next to the device name parameter to trigger the discovery of the adapters supported by the monitored host. Once discovery is complete, all discovered adapters will populate the device name drop-down. From this drop-down, select the adapter that you want test to use. As soon as the device name is selected, the ID of the chosen adapter will automatically appear against the device id box. Finally, click the Update button to register the changes. Editing the eg_desktop.ini file to manually specify the adapter name The eg_desktop.ini file on the agent side drives how the eG agent monitors packets transmissions to and from the client desktop. The example below shows a sample eg_desktop.ini file that can be found in the <EG_INSTALL_DIR>\agent\config directory. [EG_CONFIG] Interface= Ports=80,1494,7077,53,3389,2598 CacheTime=1 RemoteServers=Web::80:C,Dns::53:C,Citrix1494::1494:C,Citrix2598::2598:C,TerminalService::3389:C ;DynamicServers=80:C,1494:C,2598:C Then, save the file and restart the eG agent. Note: If you have picked a device name from the admin interface and also manually specified a different device name against the Interface parameter in the eg_desktop.ini file, the device name specification will override the Interface specification. In addition to specifying the Interface to use, you can also specify the Ports, Cache time, RemoteServers, and DynamicServers for the test using the eg_desktop.ini file. The Ports specification specifies the ports that the packet capture is set to process. Packets transmitted to other ports are not considered in the traffic analysis done by the eG agent. Note also that the eG agent currently only monitors TCP protocol traffic (i.e., UDP traffic is not analyzed). The eG agent can be configured to monitor all traffic on a specific port, or just traffic to specific servers. This configuration is provided in the RemoteServers specification. The right hand side setting for this configuration is a comma-separated list. Entries in the list are in the format name:ip address patterns:portNumber:C, where the name is the display name indicated in the eG monitor interface, and the ip address patterns is a pattern specifying the IP addresses for which traffic is to be monitored (e.g., 192.168.10.7 specifies a specific server to monitor, while 192.168.10. represents all servers whose IP addresses match the specified pattern). The port number is the specific port number to be monitored. Multiple entries corresponding to the same name are allowed and for such entries, performance statistics are aggregated while reporting (i.e., Web:192.168.10.7:80:C,web:203.197.*:80:C is allowed and traffic to all servers matching the IP address pattern will be reported as traffic for the Web descriptor). If you are not aware of the exact IP addresses or IP address patterns of the servers with which the client desktop communicates, then, you can configure the eG agent to monitor all traffic from the client desktop to a specific set of server ports. To achieve this, simply uncomment the DynamicServers specification by removing the ';' that precedes this specification. The server ports that the eG agent will be monitoring are specified on the right hand side of this entry in the format, portnumber:C. To enable the eG agent to monitor more number of ports, you can append to the comma-separated list of ports available on the right hand side of the DynamicServers specification. Then, save the file and restart the eG agent.

Measurements made by the test
Measurement	Description	Measurement Unit	Interpretation
Connection attempts	Indicates the number of TCP connections attempted by the client.	Number
Connection successes	Indicates the number of TCP connection attempts that succeeded.	Number
Connection failures	Indicates the number of TCP connection attempts that failed.	Number	Connection failures could be due to performance issues in the interconnection network or at the server end.
Connection status	Indicates the percentage of TCP connection attempts that succeeded.	Percent	A value close to 100 indicates that the network connection is good. A drop in this value is an indicator of poor network or server performance.
Avg. TCP connect time	This measure indicates how long it took on an average to establish a TCP connection.	Secs	When packet loss occurs on the network, TCP uses an exponential back-off algorithm to retry connection establishment. Hence, connection times are likely to grow exponentially as packet loss worsens. A high increase in this metric is an indicator of network connectivity issues (mostly congestion).
Max connect time	This measure indicates the longest TCP connect time during the last measurement period.	Secs
Out of order transmits	Indicates the number of TCP packets that were received out of order. TCP is a connection-oriented protocol, and in most cases, packets are received in order.	Number	While out of order transmissions by themselves are not a problem, a large number of our of order transmissions could potentially happen because of packet retransmissions being done at the TCP layer. It is important to monitor retransmissions because TCP throughput and responsiveness decrease drastically with increase in retransmissions. A sudden increase in the out of order transmits or a high percentage of out of order transmissions requires additional investigation. More often than not, such an increase in transmissions is an indicator of a network performance issue.
Percent out of order transmits	The ratio of packets transmitted out of order to packets transmitted. TCP is a connection-oriented protocol, and in most cases, packets are received in order.	Percent	While out of order transmissions by themselves are not a problem, a large number of our of order transmissions could potentially happen because of packet retransmissions being done at the TCP layer. It is important to monitor retransmissions because TCP throughput and responsiveness decrease drastically with increase in retransmissions. A sudden increase in the out of order transmits or a high percentage of out of order transmissions requires additional investigation. More often than not, such an increase in transmissions is an indicator of a network performance issue. A value of 30% or above is a cause for investigation (e.g., use a network sniffer to drill down deeper into the network transmissions).
Out of order packet receptions	Indicates the number of TCP packets received out of order.	Number	Typically, this should be a very low value. A large value is an indicator that potentially a number of retransmissions are happening on the network. Just like packet transmissions (see above), retransmission of packets received can also indicate potential network issues.
Percent out of order packet receptions	Indicates the ratio of packets received out of order to packets received.	Percent	A value greater than 20% requires additional investigation (e.g., use a network sniffer to drill down deeper into the network transmissions).