Collecting response time data

The typical Telnet data flow can be represented as shown in Figure 1.

Figure 1. Typical Telnet data flow
Example of a Telnet data flow when a client in IP network communicates with an SNA host by using Telnet

Telnet saves timestamp A when it sends a client data request to VTAM®, saves timestamp B when the target SNA host application returns data, and saves timestamp C when the client responds to the definite response request that flowed with the reply.

There are many clients, mostly those not supporting TN3270E negotiation, that do not support the Definite Response (DR) function. In this case, Telnet approximates IP response time by appending a TIMEMARK request immediately after the data. A Telnet TIMEMARK acts as a synchronization mark or as an "are you there" function for almost all clients. Almost all clients respond to the TIMEMARK request. Timestamps B and C are set based on when the TIMEMARK request is sent and a TIMEMARK response is received. In rare cases, a client does not respond to a TIMEMARK request. If Telnet does not receive a response to the TIMEMARK, a flag in the connection data indicates that IP transit time measurements were not attempted.

Some installations might not want to incur the additional network traffic of DRs or TIMEMARKs to measure IP transit time, and are interested only in the SNA application side transit time. In this case, turn off IP response measurements by specifying NOINCLUDEIP within MonitorGroup. Total response times will be the SNA response time only.

Specify INCLUDEIP within the MonitorGroup to include IP response measurements when monitoring a connection. It does not matter whether the SNA host application requested a definite response on its reply. Many applications save processing time and IP transactions by not requesting Definite Response. If IP response time monitoring is wanted and the client supports DR, specify DYNAMICDR within MonitorGroup to add the definite response request to ensure that a response is received from the client. In this case, Telnet does not forward the response to the target SNA host application, as indicated by the dotted line in Figure 1. Specify NODYNAMICDR to turn off dynamic DR creation. If INCLUDEIP and NODYNAMICDR are specified and data from the application does not include a DR request, the TIMEMARK method is used.

If chained data is sent from the host application, Telnet collects the entire chain before sending the complete data stream to the client. Telnet will save timestamp B when the entire data chain is sent.

It should be pointed out that the measured response time might not be exactly what the user sees. The first timestamp, A, is recorded when the data passes from Telnet to VTAM on its way to the SNA VTAM application. For various SNA reasons, Telnet might have received the data much earlier and had to queue it before it could be sent to VTAM. The most common reason for this is the application might not have given Telnet direction (the ability to send data). SNA applications often use a Change Direction Indicator (CDI) to manage which side can send data. The current sender can send data until it sends a CDI, which gives the other side permission to send. There might be scenarios where a client data request comes in, Telnet does not have direction, and must queue the data until the application sends a CDI. The measured response time will not include this queue time.