Internetwork traffic

Attempts

The number of monitoring intervals during which attempts were made to connect to a server. Note that this is counted separately for each server, client and software service. Thus, if in a given monitoring interval there are attempts to connect to three different servers, the Attempts metric will be incremented by three for that one monitoring interval. The actual value shown on the report is the sum total of all the attempts, for all the monitoring intervals, in the period covered by the report.

Availability (total)

The percentage of successful attempts, calculated using the following formula:

Availability (total) = 100% * (All Attempts – All failures) / All Attempts

where

All attempts = all failures + all successful operations + all standalone hits not classified as a failure + all aborts not classified as a failure

All failures = all failures (transport) + all failures (TCP) + all failures (application).

Bad MOS calls

The number of VoIP calls with the Mean Opinion Score (MOS) rating below acceptable threshold.

Bad R-factor calls

The number of VoIP calls with R-factor value below the acceptable value.

Bad delay calls

The number of VoIP calls with delay above the acceptable level.

Bad jitter calls

The number of VoIP calls with jitter exceeding the acceptable level.

Bad lost packets calls

The number of VoIP calls with loss rate above the acceptable level.

Call duration

The average call duration.

Calls

The total number of VoIP calls. Note that for a selected software service the number of calls as seen from the sites' perspective may differ from the number seen from the endpoints' perspective. This is because in one site we may have two users taking part in the same call.

Client not responding errors

The number of errors of category Client not responding .

Errors of this category occur when the server closes the TCP session with a RESET packet after the client has been idle for too long. Such a situation happens when the server TCP/IP stack detects that network connection to the client exists, but the client remains idle and does not respond. In such a case, the server closes the TCP session with a RESET packet. This may occur when the client has been silently disconnected from the network, for example, due to link failure, or the client has crashed. Note that this error will not occur if the client session has ended gracefully, that is, by closing the client application.

Closed TCP connections

The total number of successful or failed TCP connections.

Connection establishment timeout errors

The number of TCP errors of category Connection establishment timeout errors . This category of errors applies when there was no response from the server to the SYN packets transmitted by the client.

Connection refused errors

The number of TCP errors of category Connection refused errors, also referred to as Session establishment errors . This category of errors applies when a server rejects a request from a client to open a TCP session. Such a situation usually happens when the server runs out of resources, either due to operating system kernel configuration or lack of memory.

Downstream TCP packets

The total number of TCP packets sent in the downstream direction, excluding the traffic control packets.

Downstream VoIP Jitter

VoIP average jitter measured by the probe in the downstream traffic, that is, from a remote VoIP phone to the local endpoint. Jitter is a variation in voice data transit delay, in milliseconds. The Jitter is the mean value of the deviation: deviation Jitter = LastJitter * 0.9375 + D * 0.0625. In RTP packets, a creation time stamp is written. To calculate the deviation of last packet, the creation time stamp (TRTP) is subtracted from the time stamp written in previous packet (LastTRTP). The previous value is subtracted from, Arrival to destination last packet Timestamp (TM), subtracted from previous Arrival to destination packet Timestamp (LastTM). D = absolute value ((TM - LastTM) - (TRTP - LastTRTP)).

Downstream VoIP MOS

VoIP average Mean Opinion Score (MOS) measured in the downstream direction, that is, from a remote VoIP phone to the subscriber. It is within a range from 1 to 5. MOS is calculated basing on some statically configured parameters and dynamically measured call variables. Statically configured parameters are codec parameters and MOS constants. Dynamically measured call variables are: latency, size of frame and loss rate. MOS may be unavailable if there is no RTCP traffic in the call.

Downstream VoIP R-factor

VoIP average R-factor value in the downstream direction, that is, from a remote VoIP phone to the subscriber. A value derived from metrics such as latency, jitter, and packet loss, the R-Factor value helps quickly assess the quality-of-experience for VoIP calls on the network. Typical scores range from 50 (bad) to 90 (excellent).

Downstream VoIP RTCP Jitter

VoIP average jitter as reported by Real Time Transport Protocol (RTCP) for the downstream traffic, that is, from a remote VoIP endpoint to the local endpoint. Jitter reflects a variation in voice data transit delay, in milliseconds. The Jitter is the mean value of the deviation: deviation Jitter = LastJitter * 0.9375 + D * 0.0625. In RTP packets, a creation time stamp is written. To calculate the deviation of last packet, the creation time stamp (TRTP) is subtracted from the time stamp written in previous packet (LastTRTP). The previous value is subtracted from, Arrival to destination last packet Timestamp (TM), subtracted from previous Arrival to destination packet Timestamp (LastTM). D = absolute value ((TM - LastTM) - (TRTP - LastTRTP)).

Downstream VoIP delay

VoIP weighted average networking delay in the downstream direction, that is, from a remote to the local VoIP endpoint. The Delay for one call is calculated as follows: Delay = Latency + LookAheadDelay + JitterBufferDelay + PLSize / BaseFrameSize * BaseFrameDuration Where Latency in this formula is not a Delay from a Report Block of RTCP packet. It is calculated on the basis of time stamps (measured by the Probe) of RTCP packets and Delays extracted from Report Blocks of RTCP packets. Other parameters apart from PLSize are codec specific. PLSize is the current RTP payload size.

Downstream VoIP loss rate

The percentage of VoIP packets lost or discarded that needed to be retransmitted, measured for downstream traffic.

Downstream bandwidth usage

Downstream traffic bandwidth per data resolution (hour/day/week/month).

Downstream bytes

The number of bytes transferred in the downstream direction (to the subscriber).

Downstream packets

The number of packets transmitted in the downstream direction.

Downstream packets lost

The number of lost TCP data packets sent in the downstream direction, excluding the traffic control packets.

Downstream realized bandwidth

Realized bandwidth in the downstream direction, to a site.

Failures (total)

The total number of failures, that is all Failures (transport) + all Failures (TCP) + all Failures (application)

Local ACK RTT

RTT measurement performed during ACK packet transmission, from local site side of the transaction.

Local ACK RTT measurements

These metrics keep track of how many RTT of local site's ACK measurements were made. ACK measurement is performed during ACK packet transmission either from server or client side of the transaction.

Local RTT

The round-trip time measured for the local site.

Network performance

The percentage of total traffic that did not experience network-related problems (traffic in which the values of loss rate and RTT did not exceed configured thresholds).

RTT measurements

The number of RTT measurements. An RTT measurement occurs during every TCP handshake, so it provides some insight into the number of attempted TCP sessions, and the potential accuracy of the RTT measurements that are reported.

Remote ACK RTT

Remote ACK RTT is the time it takes for an ACK packet with no payload to travel from the remote site the AMD and back again.

Remote ACK RTT measurements

This metric keeps track of how many remote ACK RTT measurements were made. ACK measurement is performed during ACK packet transmission either from server or client side of the transaction.

Remote RTT

The round-trip time measured for the remote site.

Server not responding errors

The number of Server Not Responding errors. This category of errors applies when the client closes the TCP session with a RESET packet after the server has failed to respond for too long.

Server session termination errors

The number of Server Session Termination errors. This category of errors applies when the server detects an error on the software service level and closes the TCP session with a RESET packet.

Successful attempts

The number of monitoring intervals during which successful attempts were made to connect to a server. Note that this is counted separately for each server. Thus, if in a given monitoring interval there are attempts to connect to three different servers, the Successful attempts metric will be incremented by three for that one monitoring interval. Note also that, even if TCP errors occur, but the connection is established during the given monitoring interval, then this monitoring interval is counted as a success (for that server).

TCP errors

The total number of TCP errors.

Those errors may indicate server or application problems and therefore measurements of those are critical to understanding the issues that may affect end-user experience. AMDs measure and report on the following types of TCP errors:

  • Connection Refused Errors - Client attempts to open a TCP session with a server, which rejects the request. SYN packet from Client is followed by RESET packet from Server, with matching TCP sequence numbers. This error is typically caused by resource exhaustion on the server, which is unable to accept more concurrent TCP sessions. This may be either a configuration issue (too few resources allocated in the kernel) or lack of memory. SYN flood attacks typically result in servers being unable to accept new connections.

  • Server session termination error - Server is unexpectedly terminating a connection that was successfully opened. The server sends a RESET packet to the Client. Such an error originates at an application using TCP session that is monitored. It does not necessarily mean application failure; usually it means that the application encountered a condition in which it decided to immediately terminate session with the client, for example, because of an application security policy violation by the client.

  • Session Abort - Client is unexpectedly terminating a connection that was successfully opened. The Client sends a RESET packet to the Server. These errors are inspected in the context of the client application and may or may not be reported. For example, the browser running HTTP may terminate the load of a GIF file if it is older than the one that it had previously cached and this is normal behavior. However, if all connections to the server are terminated because the user hits the STOP button, then this is abnormal session termination and is reported as "Aborted operation" or "Stopped Page".

  • Client not responding errors (server timeout errors) - Server networking stack takes an assumption that the network connection to the client exists, but the client remains idle and does not respond. In such a case, the server closes the TCP session with the RESET packet. Such a condition may occur when the client has been silently disconnected from the network, for example, due to a link failure, or the client has crashed. Note that this error will not occur if the client has ended the session gracefully, e.g. by closing the client application.

  • Server not responding errors (client timeout errors) - Client networking stack takes an assumption that network connection to the server exists, but the server remains idle and does not respond. In such a case, the client closes the TCP session with the RESET packet. This may occur either during the Session Setup phase (no response to the SYN packet), or during a normal data exchange process. Such a situation may result in the intermittent network problems between the client and the server. In the case the traffic is routed through asymmetric paths across the Internet, which is often the case, the path from the server to the client may be broken.

Total bandwidth usage

The number of all transmitted bits (client + server) per second.

Total bytes

The number of all transmitted bytes (client + server).

Upstream TCP packets

The total number of TCP packets sent in the upstream direction, excluding the traffic control packets.

Upstream VoIP Jitter

Average jitter measured by the probe in the upstream traffic, that is, from a local to a remote VoIP endpoint. Jitter reflects variation in voice data transit delay, in milliseconds. The Jitter is the mean value of the deviation: deviation Jitter = LastJitter * 0.9375 + D * 0.0625. In RTP packets, a creation time stamp is written. To calculate the deviation of last packet, the creation time stamp (TRTP) is subtracted from the time stamp written in previous packet (LastTRTP). The previous value is subtracted from, Arrival to destination last packet Timestamp (TM), subtracted from previous Arrival to destination packet Timestamp (LastTM). D = absolute value ((TM - LastTM) - (TRTP - LastTRTP)).

Upstream VoIP MOS

VoIP average Mean Opinion Score (MOS) measured in the upstream direction, that is, from a subscriber to a remote VoIP phone. It is within a range from 1 to 5. MOS is calculated basing on some statically configured parameters and dynamically measured call variables. Statically configured parameters are codec parameters and MOS constants. Dynamically measured call variables are: latency, size of frame and loss rate. MOS may be unavailable if there is no RTCP traffic in the call.

Upstream VoIP R-factor

VoIP average R-factor value in the upstream direction, that is, from a subscriber to a remote VoIP phone. A value derived from metrics such as latency, jitter, and packet loss, the R-Factor value helps quickly assess the quality-of-experience for VoIP calls on the network. Typical scores range from 50 (bad) to 90 (excellent).

Upstream VoIP RTCP Jitter

VoIP average jitter as reported by Real Time Transport Protocol (RTCP) for the upstream traffic, that is, from a local VoIP endpoint to a remote one. Jitter reflects a variation in voice data transit delay, in milliseconds.

Upstream VoIP delay

VoIP average networking delay in the upstream direction, that is, from a local to a remote VoIP endpoint. The Delay for one call is calculated as follows: Delay = Latency + LookAheadDelay + JitterBufferDelay + PLSize / BaseFrameSize * BaseFrameDuration Where Latency in this formula is not a Delay from a Report Block of RTCP packet. It is calculated on the basis of time stamps (measured by the Probe) of RTCP packets and Delays extracted from Report Blocks of RTCP packets. Other parameters apart from PLSize are codec specific. PLSize is the current RTP payload size.

Upstream VoIP loss rate

The percentage of VoIP packets lost or discarded that needed to be retransmitted, measured for upstream traffic.

Upstream bandwidth usage

The number of upstream bits per second.

Upstream bytes

The number of bytes transmitted in the upstream direction.

Upstream packets

The number of packets transmitted in the upstream direction.

Upstream packets lost

The number of lost TCP data packets sent in the upstream direction, excluding the traffic control packets.

Upstream realized bandwidth

Realized bandwidth in the upstream direction, from a site, area or region.

VoIP Jitter

VoIP average jitter measured by the probe, for both downstream and upstream traffic. Jitter is a variation in voice data transit delay, in milliseconds. In general, higher levels of jitter are more likely to occur on either slow or heavily congested links.

VoIP MOS

VoIP average Mean Opinion Score (MOS) rating of the call quality, for both downstream and upstream traffic.

VoIP R-factor

VoIP average R-factor value, for both downstream and upstream traffic. It is a transmission quality rating, with a typical range of 50-100. An R-Factor score is derived from multiple VoIP metrics, including latency, jitter, and loss.

VoIP RTCP Jitter

VoIP average jitter as reported by Real Time Transport Protocol (RTCP), for both downstream and upstream traffic. Jitter is a variation in voice data transit delay, in milliseconds. Higher levels of jitter are more likely to occur on either slow or heavily congested links.

VoIP delay

VoIP average networking delay, as reported by Real Time Transport Protocol (RTCP), measured for both downstream and upstream traffic.

VoIP loss rate

The percentage of VoIP packets lost or discarded that needed to be retransmitted, measured for both upstream and downstream traffic.

Zero window size events (client)

Client sets this in TCP header when it wants the other side to slow down with data transmission because it cannot keep up with the transmission speed. Indicates that receiving machine is busy with other tasks.