Interpretation Overview and Terminology

The objective of this article is to help users make the best use of the performance reports provided by their appliance. You will find an overview of how application performance issues can be solved with Cisco Provider Connectivity Assurance Sensor Capture (formerly Skylight sensor: capture).
This article focuses on synthetic metrics to produce a measure of the quality of user experience (QoS - End User Response Time).

Objectives

Before you start analyzing performance reports, there are certain things to keep in mind: Performance metrics should not be considered as absolute values, but in comparison with different time intervals, servers and user groups. Performance metrics represent time interval. Although most of them correspond to the measurement of a concrete phenomenon, it is almost impossible to provide a scale of what is a good or a bad response time, with no experience of the impact it has on users. For example, indicating that the Network Round Trip Time from a site A to a site B is 200ms does not mean you have a measure that is acceptable or not. In the same way, a Server Response Time (SRT) of an application A of 100ms may be very “bad” when the same value would be excellent for an application B. As a consequence, it is important to consider performance metrics as relative values. One of the keys to a good interpretation of performance metrics is to compare systematically performance metric value with:

• Another time period;
• Another user group.

Mixing up performance metrics for several applications does not make sense. When looking at application performance metrics, you should be very careful of isolating applications for analysis. As a consequence, the metrics which very much depend on the application’s specific behaviour should not be considered altogether. This is true for metrics such as EURT (End User Response Time), SRT (Server Response Time) and DTT (Data Transfer Time).

RTT measurements can marginally be impacted by the behaviour of the operating system. Network Round Trip Times for TCP are based on the TCP acknowledgment mechanism. This means that, although RRT is generally a good measurement of round trip latency, if the operating system of one of the parties is so overloaded that the acknowledgment process becomes slower, RTT values will be impacted. RTT Server would be impacted on the server side and RTT Client on the client side. RTT should then be analyzed in parallel with CT (Connection Time) because the treatment of a new session by the IP stack has a higher priority.

Some values are averaged measures. For each conversation, two kinds of values are reported:

• Counters, for instance packets or byte counters, which are the sum over all connections aggregated for this conversation;
• Performance metrics, for instance RTT, SRT, DTT and the like, which are average values over all samples aggregated for this conversation.

EURT

EURT stands for End User Response Time.

This metric is an aggregate of various other measures meant to give an idea of the perceived overall end user experience. It is taken as the sum of RTT, SRT and DTT.

EURT has no meaningful physical counterpart. Only its evolution makes sense and allows the system administrator to check at a glance whether a network zone is behaving as usual or not. Notice that expected correct values for both SRT and DTT depend on the protocol at hand. As a consequence, you should not try to compare two EURTs of different applications.

RTT

RTT stands for Round Trip Time.

RTT gives an approximation of the time required for a packet to reach its destination, and can be further decomposed into an RTT Server (delay between a data packet send by the client and its ACK from the server) and an RTT Client (in the other way around). As a typical IP implementation will delay acknowledging of incoming data, additional tricks are exploited in order to rule out these software biases:

• Make use of SYN/FIN acknowledgment and some exceptional conditions such as TCP resets, that suffer no such delays, to estimate a realistic upper bound.
• Exclude unusually high RTT values.
• Bound RTT Server/Client by SRT/CRT if RTT sample set looks suspicious.

RTT is refers to the bare speed of the physical layer. It is unaffected by packet retransmissions, packet loss or similar occurrences. RTT may be affected by (from most common to the rarest):

• Slow network equipment between client and server (such as a router or a switch);
• Link layer overloaded (ethernet collisions, for instance);
• Malfunction of one of the involved network adapters.

These troubles should be further investigated by comparing with other client and/or server zones in order to locate the misbehaving equipment. Notice that a degradation of RTT will almost invariably impact other metrics as well.

SRT

SRT stands for Server Response Time.

SRT gives an estimation of the elapsed time between the last packet of an applicative request and the first packet of the server’s response.

SRT represents the processing time of the server, at the application layer, for a given request. SRT may be affected by (from the most common the the rarest):

• Time-consuming application request (a complex SQL command can let the server process longer);
• Application layer overloaded (too many requests that the server can’t handle in a small period of time);
• SRT can be marginally affected by the increase of network latency between the point of capture and the server (parallel increase of the RTT Server value).

To pinpoint the root cause of the slowdown, we want to compare the SRT for a given server/application with other applications on the very same server. If there is a blatant difference, the application is guilty. Otherwise, we want to compare it with other servers in the same zone, then different zones.

DTT

DTT stands for Data Transfer Time.

DTT server is defined as the time between the first data packet of the response (with ACK flag and a non-nil payload) from the server and the last packet considered as part of the same response (if the packet has the same acknowledgement number); FIN, RST packets from server or client will also be considered as closing the sequence. A Timeout will cancel a DTT. Note that if the answer is small enough to be contained in only one packet, the DTT will be '0'.

DTT client is the same metric in the other direction.

DTT (sum of both server and client DTT) is the time the user is going to wait for the response to circulate on the network from the server to the client. It does not depend on the Server Response Time (e.g., a DTT might be short for a long SRT:

• The request might require a large calculation, but the result represents a small volume of data; or a DTT might be very large, but SRT is very short because the request is easy to handle yet the response is very large). DTT depends on (from the largest impact to the smallest):
• The size of the response (the more data is contains, the longer it takes to transfer it),
• The level of retransmission (the more packets are retransmitted, the longer it will take to transfer the whole response),
• The network latency (the longer it takes to transfer packets through the network, the longer it will be to transfer the response - minor impact),
• The actual throughput that can be reached to transfer the response from the server to the client.

DTT may vary (from most common to the rarest):

• Globally or on a per transaction basis (if only some transaction is impacted, it may be linked to the size of some specific application response),
• For all or some client zones (if only some client zones are impacted, it may be linked to specific network conditions — retransmissions),
• For all or some servers (if only a specific server is impacted, it may be due to a specific server issue in broadcasting the response).