Simulate RTSP streaming—client (from probe) requests video to server (to probe) - to probe sends video traffic to client (RTP/UDP). It is a simple transaction (one packet) with get from client (endpoint from-E1) and response from server (endpoint to-E2). And it defines a video stream from E2 to E1 with defined bit rate and MPEG2 or customizable codec. The client is the 'From' endpoint and the server is the 'To' endpoint.

Measure simple TCP response time and / or transaction rate. Allows to understand response time for TCP through very simple transactions on network. Also generates a unidirectional video flow from E2 to E21. This can simulate video based on RTP/UDP flows going through the network.

• Test Duration

• Generated bitrate

• DSCP setting

• Delay (ms)

• Jitter (ms)

• Jitter max (ms)

• Loss (%)

• Max loss burst

• Throughput video (Mbps)

RTSP Control:

• Response Time (ms)

This test sends tcp sync and waits for response. Then 100 bytes are sent from E1 to E2 and 100 bytes are sent from E2 to E1. Typically, only 2 packets are exchanged for full transaction.

This test allows generating video rtp streams—bitrate defines corresponding codec (HD or SD).

The response time is the expected time to transfer very simple packets in both directions into two payloads with TCP. In case of retransmissions, the response time increases significantly.

By default, no objective is set to throughput: any result is good enough, because the total throughput must reflect the response time and transaction rate (transaction rate is 1/response time).

This test generates video stream on the selected path. It can be optimized with setting up send low jitter in the preferences to be 1 if the endpoints support it.

If the configured bitrate is set too high compared to the expected line capacity:

• The test may not be able to accomplish first measurement. This configuration results in an error with time out ('Some pairs in tests failures complete').

If the test result pair cannot be collected:

• Check that your E2 endpoint can open 10115 port toward E1 for management (this is needed for stream pairs).

• Check that synchronization port between pairs is opened (management UDP 10115).

• Check that port in use is in the range. See preferences/Test Controller/Destination Port Conf option and preferences/Test Controller/First Destination Port, so that correct destination port for test traffic is used.

Simple transaction (one packet) with get from client (endpoint from) and response from server (endpoint to).

Measure simple TCP response time and / or transaction rate. Allows to understand response time for TCP very simple transactions on network.

• Test duration , DSCP setting

• Response time Average (ms)
• Throughput (Mbps)
• Transaction rate (per second)

This test sends tcp sync and waits for response.

then 100 bytes are sent E1 to E2 and 100 bytes are sent from E2 to E1. Typically only 2 packets are exchanged for full transaction.

The response time is the expected time to transfer very simple packets in both directions into 2 payloads with TCP. In case of retransmissions the response time will increase significannotly.

By default no objective is set to throughput : any result is good enough as total throughput should reflect response time and transaction rate (transaction rate is 1/response time).

If the configured bitrate is set too high compared to expected line capacity, this might result in the test not able to accomplish first measurement. This would result in an error with time out ("Some pairs in tests failures complete"). If results cannot be collected Check that port in use is in range (see "preferences/Traffic Port Management/Destination Port Conf Option" and "preferences/Traffic Port Management/First Destination Port" so that correct destination port for test traffic is used.

http or https transactions from E1 (client ) to E2 (server) - download file or gif.

Measure simple TCP response time and / or transaction rate for http requests. Request is 300 bytes, response is 25 kbytes which is size of typical web page.

• Test duration
• Test bit rate
• http format (txt or gif)

• Response time Average (ms)
• Throughput (Mbps)
• Transaction rate (per second)

Synthetic transactions are simulated between E1 and E2 reproducing http or https traffic with same network pattern and footprint to measure network capability to transport this type of traffic.

The response time is the expected time to transfer web page.

By default no objective is set to throughput : any result is good enough as total throughput should reflect response time and transaction rate (transaction rate is 1/response time).

If the configured bitrate is set too high compared to expected line capacity, this might result in the test not able to accomplish first measurement. This would result in an error with time out ("Some pairs in tests failures complete"). If results cannot be collected Check that port in use is in range (see "preferences/Traffic Port Management/Destination Port Conf Option" and "preferences/Traffic Port Management/First Destination Port" so that correct destination port for test traffic is used.

pop3 or smtp transactions from E1 (client ) to E2 (server) - download file or gif.

Measure simple TCP response time and / or transaction rate for pop3 or smtp requests. E1 is email client, E2 is email server. The traffic reproduces synthetic transactions.

• Test duration
• Test bit rate

• Response time Average (ms)
• Throughput (Mbps)
• Transaction rate (per second)

Synthetic transactions are simulated between E1 and E2 reproducing pop3 or smtp traffic with same network pattern and footprint to measure network capability to transport this type of traffic.

The response time is the expected time to transfer email.

By default no objective is set to throughput : any result is good enough as total throughput should reflect response time and transaction rate (transaction rate is 1/response time).

If the configured bitrate is set too high compared to expected line capacity, this might result in the test not able to accomplish first measurement. This would result in an error with time out ("Some pairs in tests failures complete"). If results cannot be collected Check that port in use is in range (see "preferences/Traffic Port Management/Destination Port Conf Option" and "preferences/Traffic Port Management/First Destination Port" so that correct destination port for test traffic is used.

ftp transactions from E1 (client ) to E2 (server) - download or upload file of 100kbytes.

Measure simple TCP response time and / or transaction rate for FTP requests. E1 is ftp client, E2 is ftp server. The traffic reproduces synthetic transactions.

• Test duration
• Test bit rate
• ftp get or ftp put

• Response time Average (ms)
• Throughput (Mbps)
• Transaction rate (per second)

Synthetic transactions are simulated between E1 and E2 reproducing ftp traffic with same network pattern and footprint to measure network capability to transport this type of traffic.

File size for transactions is 100 kbytes.

The response time is the expected time to transfer ftp file.

By default no objective is set to throughput : any result is good enough as total throughput should reflect response time and transaction rate (transaction rate is 1/response time).

If the configured bitrate is set too high compared to expected line capacity, this might result in the test not able to accomplish first measurement. This would result in an error with time out ("Some pairs in tests failures complete"). If results cannot be collected Check that port in use is in range (see "preferences/Traffic Port Management/Destination Port Conf Option" and "preferences/Traffic Port Management/First Destination Port" so that correct destination port for test traffic is used.

DNS transactions from E1 (client ) to E2 (server).

Measure simple TCP response time and / or transaction rate for DNS requests. E1 is DNS client, E2 is DNS server. The traffic reproduces synthetic transactions.

• Test duration
• Test bit rate

• Response time Average (ms)
• Throughput (Mbps)
• Transaction rate (per second)

Synthetic transactions are simulated between E1 and E2 reproducing DNS queries with same network pattern and footprint to measure network capability to transport this type of traffic.

The response time is the expected time to accomplish DNS request.

By default no objective is set to throughput : any result is good enough as total throughput should reflect response time and transaction rate (transaction rate is 1/response time).

If the configured bitrate is set too high compared to expected line capacity, this might result in the test not able to accomplish first measurement. This would result in an error with time out ("Some pairs in tests failures complete"). If results cannot be collected Check that port in use is in range (see "preferences/Traffic Port Management/Destination Port Conf Option" and "preferences/Traffic Port Management/First Destination Port" so that correct destination port for test traffic is used.

Exchange protocol transactions from E1 (client) to E2 (email server).

Measure simple Exchange transactions based on sending and receiving traffic from remote site to central site hosting server.

• Number of users
• Send traffic bitrate
• Receive traffic bitrate
• Emails size (sent)
• Emails size (Received)

The total throughput is distributed amongst number of users !

• Per traffic type (sent or received)
• Response time Average (ms)
• throughput total transactions (Mbps) - bidirectional throughput
• Transaction rate (per second)
• Total bytes sent and received

Synthetic transactions are simulated between E1 and E2 reproducing Exchange messages sent and received. The maximum throughput is the limit set to allow this traffic to go through on each direction.

The response time is the expected time to transfer email or received.

By default no objective is set to throughput : any result is good enough as total throughput should reflect response time and transaction rate (transaction rate is 1/response time).

If the configured bitrate is set too high compared to expected line capacity, this might result in the test not able to accomplish first measurement. This would result in an error with time out ("Some pairs in tests failures complete"). If results cannot be collected Check that port in use is in range (see "preferences/Traffic Port Management/Destination Port Conf Option" and "preferences/Traffic Port Management/First Destination Port" so that correct destination port for test traffic is used.

SIP protocol transactions from E1 (caller) to E2 (call server).

Measure simple TCP response time and / or transaction rate for SIP requests. E1 is SIP client, E2 is SIP server. The traffic reproduces synthetic transactions that are representative of typical SIP based functions.

• Test duration
• Test bit rate
• type of SIP transactions

• Response time Average (ms)
• Throughput (Mbps)
• Transaction rate (per second)

Synthetic transactions are simulated between E1 and E2 reproducing SIP transactions with same network pattern and footprint to measure network capability to transport this type of traffic.

The response time is the expected time to accomplish SIP transaction.

By default no objective is set to throughput : any result is good enough as total throughput should reflect response time and transaction rate (transaction rate is 1/response time).

If the configured bitrate is set too high compared to expected line capacity, this might result in the test not able to accomplish first measurement. This would result in an error with time out ("Some pairs in tests failures complete"). If results cannot be collected Check that port in use is in range (see "preferences/Traffic Port Management/Destination Port Conf Option" and "preferences/Traffic Port Management/First Destination Port" so that correct destination port for test traffic is used.

Broadcast of RTP (over UDP) video stream to single.

Broadcast of video stream to single (node to node test) or multiple probes (hub and spoke mesh test).

Define multicast source IP address and port. Configure stream bit rate.

• Datagrams out of order
• Delay
• Jitter
• Loss throughput video rate
• Total bytes lost

Can be used for N2N or Mesh tests.Only available for hub and spoke mesh.

Confirm all probes receive video stream at acceptable rate and quality.

Port blocked errors.

Determines average speed between two endpoints in one direction (upload).

Performs TCP traffic using several TCP pairs. The test attempts to generate as much TCP throughput as possible using several TCP streams. The average throughput is reported.

• Test duration (sec)
• Specify which QOS (DSCP setting) to request between switches in network
• Number of pairs

• Identifies from IP address
• Identifies to IP address
• Average TCP throughput (Mbps) in one direction

If the test duration is too short the time taken to ramp up TCP throughput will reflect in a lower average throughput rate. The endpoint establishes multiple connections with the server over TCP port. An initial chunk of data is sent. The endpoint then adjusts the chunk size and buffer size based on TCP metrics to maximize usage of the network connection. As the chunks are received by the other endpoint, the endpoint will request more chunks throughout the duration of the test. During the initial stages of the test, the endpoint will establish extra TCP connections (streams) to the other endpoint if it determines additional threads are required to more accurately measure the throughput speed.

Speed test between endpoints.

See Common Errors - Real Services.

Determines average speed between two endpoints in one direction (download).

Performs TCP traffic using several TCP pairs. The test attempts to generate as much TCP throughput as possible using several TCP streams. The average throughput is reported.

• Test duration (sec)
• Specify which QOS (DSCP setting) to request between switches in network
• Number of pairs

• Identifies from IP address
• Identifies to IP address
• Average TCP throughput (Mbps) in one direction

If the test duration is too short the time taken to ramp up TCP throughput will reflect in a lower average throughput rate.

The endpoint establishes multiple connections with the server over TCP port. An initial chunk of data is sent. The endpoint then adjusts the chunk size and buffer size based on TCP metrics to maximize usage of the network connection.

As the chunks are received by the other endpoint, the endpoint will request more chunks throughout the duration of the test.

During the initial stages of the test, the endpoint will establish extra TCP connections (streams) to the other endpoint if it determines additional threads are required to more accurately measure the throughput speed.

Speed test between endpoints.

See Common Errors - Real Services.

Determines average speed between two endpoints in both directions.

Performs TCP traffic using several TCP pairs. The test attempts to generate as much TCP throughput as possible using several TCP streams. The average throughput is reported.

• Test duration (sec)
• Specify which QOS (DSCP setting) to request between switches in network
• Number of pairs

• Identifies from IP address
• Identifies to IP address
• Average TCP throughput (Mbps) in one direction

If the test duration is too short the time taken to ramp up TCP throughput will reflect in a lower average throughput rate.

The endpoint establishes multiple connections with the server over TCP port. An initial chunk of data is sent. The endpoint then adjusts the chunk size and buffer size based on TCP metrics to maximize usage of the network connection.

As the chunks are received by the other endpoint, the endpoint will request more chunks throughout the duration of the test.

During the initial stages of the test, the endpoint will establish extra TCP connections (streams) to the other endpoint if it determines additional threads are required to more accurately measure the throughput speed.

Speed test between endpoints.

See Common Errors - Real Services.

Determines average speed between two endpoints in one direction (download) using two Class of Service (COS) TCP streams.

Performs TCP traffic using several TCP pairs. The test attempts to generate as much TCP throughput as possible using several TCP streams. The average throughput is reported. Each of the two TCP streams will be using a different QOS setting impacting priority of data packets and across the network which will be reflected in throughput.

• Test duration (sec)
• Specify which QOS (DSCP setting) to request between switches in network
• Number of pairs

• Identifies from IP address
• Identifies to IP address
• Average TCP throughput (Mbps) in one direction for each COS

If the test duration is too short the time taken to ramp up TCP throughput will reflect in a lower average throughput rate.

The endpoint establishes multiple connections with the server over TCP port. An initial chunk of data is sent. The endpoint then adjusts the chunk size and buffer size based on TCP metrics to maximize usage of the network connection.

As the chunks are received by the other endpoint, the endpoint will request more chunks throughout the duration of the test.

During the initial stages of the test, the endpoint will establish extra TCP connections (streams) to the other endpoint if it determines additional threads are required to more accurately measure the throughput speed.

The lower the COS number the lower the priority of the TCP stream (QOS).

The software endpoint is dependent upon endpoint base OS to add COS to ipV4 packets and it is possible the base OS (particularly if windows) will not always do this. Additionally, COS is layer 2 traffic, just the ToS 1 byte value in the IP header.

QOS is layer 3 traffic where COS and traffic type are both taken into consideration.

Speed test between endpoints.

See Common Errors - Real Services.

Determines average speed between two endpoints in one direction (download) using three Class of Service (COS) TCP streams.

• Test duration (sec)
• Specify which QOS (DSCP setting) to request between switches in network
• Number of pairs

• Identifies from IP address
• Identifies to IP address
• Average TCP throughput (Mbps) in one direction for each COS

If the test duration is too short the time taken to ramp up TCP throughput will reflect in a lower average throughput rate.

The endpoint establishes multiple connections with the server over a TCP port. An initial chunk of data is sent. The endpoint then adjusts the chunk size and buffer size based on TCP metrics to maximize usage of the network connection.

As the chunks are received by the other endpoint, the endpoint will request more chunks throughout the duration of the test.

During the initial stages of the test, the endpoint will establish extra TCP connections (streams) to the other endpoint if it determines additional threads are required to more accurately measure the throughput speed.

The lower the COS number the lower the priority of the TCP stream (QOS).

The software endpoint is dependent upon endpoint base OS to add COS to ipV4 packets and it is possible the base OS (particularly if windows) will not always do this. Additionally, COS is layer 2 traffic, just the ToS 1 byte value in the IP header.

QOS is layer 3 traffic where COS and traffic type are both taken into consideration.

Speed test between endpoints.

See Common Errors - Real Services.

Determines average speed between two endpoints in one direction (download) using four Class of Service (COS).

• Test duration (sec)
• Specify which QOS (DSCP setting) to request between switches in network
• Number of pairs

• Identifies from IP address
• Identifies to IP address
• Average TCP throughput (Mbps) in one direction for each COS

If the test duration is too short the time taken to ramp up TCP throughput will reflect in a lower average throughput rate.

The endpoint establishes multiple connections with the server over TCP port. An initial chunk of data is sent. The endpoint then adjusts the chunk size and buffer size based on TCP metrics to maximize usage of the network connection.

As the chunks are received by the other endpoint, the endpoint will request more chunks throughout the duration of the test.

During the initial stages of the test, the endpoint will establish extra TCP connections (streams) to the other endpoint if it determines additional threads are required to more accurately measure the throughput speed.

The lower the COS number the lower the priority of the TCP stream (QOS).

The software endpoint is dependent upon endpoint base OS to add COS to ipV4 packets and it is possible the base OS (particularly if windows) will not always do this. Additionally, COS is layer 2 traffic, just the ToS 1 byte value in the IP header.

QOS is layer 3 traffic where COS and traffic type are both taken into consideration.

Speed test between endpoints.

See Common Errors - Real Services.

Determines average speed between two endpoints in one direction (download) using five Class of Service (COS).

• Test duration (sec)
• Specify which QOS (DSCP setting) to request between switches in network
• Number of pairs

• Identifies from IP address
• Identifies to IP address
• Average TCP throughput (Mbps) in one direction for each COS

If the test duration is too short the time taken to ramp up TCP throughput will reflect in a lower average throughput rate.

The endpoint establishes multiple connections with the server over TCP port. An initial chunk of data is sent. The endpoint then adjusts the chunk size and buffer size based on TCP metrics to maximize usage of the network connection.

As the chunks are received by the other endpoint, the endpoint will request more chunks throughout the duration of the test.

During the initial stages of the test, the endpoint will establish extra TCP connections (streams) to the other endpoint if it determines additional threads are required to more accurately measure the throughput speed.

The lower the COS number the lower the priority of the TCP stream (QOS).

The software endpoint is dependent upon endpoint base OS to add COS to ipV4 packets and it is possible the base OS (particularly if windows) will not always do this. Additionally, COS is layer 2 traffic, just the ToS 1 byte value in the IP header.

QOS is layer 3 traffic where COS and traffic type are both taken into consideration.

Speed test between endpoints.

See Common Errors - Real Services.

Speedtest along with network KPI measures speed with TCP + latency/jitter/loss with RTP/UDP packets. It determines average speed between two endpoints in one direction (upload), along with the test network delivery KPI with low footprint (100 Mbps) and 50 packets per second—from E1 to E2 direction.

• Test duration (sec)

• Specify which QOS (DSCP setting) to request between switches in network

• Number of pairs

• Identifies from IP address

• Identifies to IP address

• Average TCP throughput (Mbps) in one direction

Network KPI Metrics:

• One way delay (ms)

• Jitter (ms)

• Max jitter (ms)

• Loss (%)

• Voice MOS score

• Packet loss burst

• Max delay variation(ms)

If the test duration is too short, the time taken to ramp up TCP throughput reflects in a lower average throughput rate. The endpoint establishes multiple connections with the server over TCP port. An initial set of data is sent. The endpoint then adjusts the data size and buffer size based on the TCP metrics to maximize usage of the network connection. As the data set is received by the other endpoint, the endpoint requests more data sets throughout the duration of the test. During the initial stages of the test, the endpoint establishes extra TCP connections (streams) to the other endpoint; if it determines that additional threads are required to more accurately measure the throughput speed.

This test generates unidirectional traffic with heartbeats to measure the key metrics. The traffic is like voice traffic—MOS score is an indicator of capacity of the link to transport voice in a good quality.

The following definitions help you to understand key metrics:

• Max delay variation: The time from when a packet is sent from a probe to when it is received, end to end, is the delay. The max delay variation is the difference between the shortest time and the longest time for this end to end delay for exchanging the packets.

• Max jitter: This parameter measures the variance in spacing between packets sent end to end. If the difference in time (spacing) between 1st and 2nd packet sent from the first probe is 2 ms, and the time on far end probe receiving 1st and 2nd packets is 3.7 ms, the jitter is (3.7-2) ms = 1.7 ms.

Speed test between endpoints:

• The network KPI pair generates packets in RTP stream.

• These packets traverse the network from one probe to the other and provides indication based on the time sent and received, how many are lost and so on.

• The packets are sent similarly to a G711 voice stream, because this behavior is expected to be a key application of the network's ability to transport.

• Voice MOS score gives an indication of the quality of transport network for voice G711 application.

If test result pair cannot be collected:

• Check that your E2 endpoint can open 10115 port toward E1 for management (this is needed for stream pairs).

• Check that synchronization port between pairs is opened (management UDP 10115).

• Check that port in use is in range (see "preferences/Test Controller/Destination Port Conf Option" and "preferences/Test Controller/First Destination Port" so that correct destination port for test traffic is used.

Also see Common Errors – N2N.