Choosing the Right Test Protocol for Network & App Synthetics Tests
PreviousBest-Practices GuidesNextOptimizing SYN vs SACK Probing Methods to Avoid Unexplainable Packet Loss
Last updated
Last updated
Whenever possible, always use the protocol that is as close to the actual payload as possible to gain the most reliable results.
Most of the time, this will be TCP.
Use UDP for agent-to-agent tests if you want to simulate media traffic.
Use ICMP as a fallback option if TCP or UDP don't work as expected.
Tests that run from Cloud and Enterprise agents (CEA) can use different protocols for testing:
TCP and ICMP for all tests
TCP, ICMP, and UDP for agent-to-agent tests
It is not always clear when to use each. This article aims to explain the best practices in choosing this setting.
Every test in ThousandEyes consists of two parts: An end-to-end measurement, which determines the end-to-end packet loss and latency, and the path trace, which builds the path visualization. For full details please look at Network Tests Explained
In general, it's always advisable to test with the same protocol that the application uses. What that means we will explain in the next sections.
The choices for the end-to-end tests are mostly mandated by the test type performed and what is being measured. (For a full description of available test types, see Tests.) For example, an HTTP server test will use HTTPS as the end-to-end test metric, whereas a voice test will use RTP as the test protocol.
The first test type where the user must make a choice is the agent-to-server test.
Agent-to-server tests can be performed using either ICMP or TCP.
If we are testing a specific application on our destination host, it's always advisable to use a TCP test to the application specific port. So, if we test an SSH server, we use TCP/22. If we are testing an SQL server we use TCP/1433, etc.
This approach gives us more information about the actual service health: We are not only testing if a host is responding, but also if the service port is open and accepting connections.
For both Windows and Linux-based hosts, we measure service health by ensuring both the TCP port and the service are responsive. For Linux-based hosts, if the port is open but the service is unavailable, you will see a TCP RST response for those test rounds in the path visualization view. Because we measure packet loss based on the TCP RST response, alert rules that only monitor packet loss could fail to trigger notifications for an unavailable service hosted on a Linux-based host. To be alerted for a scenario where the port is open but the service is unavailable, you can create an alert rule to trigger notifications on Probe Response Type is TCP RST.
By using the same protocol and port as the actual payload, we also ensure that the network between the agent and host handles the test traffic the same as the production traffic. This will yield the most reliable measurements, whereas ICMP might be handled with lower priority as compared to TCP.
Sometimes there is no TCP service port that you can connect to – either because of firewall rules, or because there just isn’t any TCP port open on the host tested. If this is the case, ICMP can still give reachability, and path information.
Another test where the payload is user configurable is the agent-to-agent test. For this test we can choose between TCP and UDP.
Agent-to-agent tests are very useful in testing how a network behaves for a specific application payload, for example voice and video traffic.
Most voice and video traffic uses UDP as transport protocol. Given the connectionless nature of UDP, it's not possible to test UDP traffic without control over both source and destination. Using an agent-to-agent test, with UDP as transport, and the right port and QoS markings, allows you to test end-to-end voice and video performance.
This flexibility in protocol, port numbers and QoS marking allows us to carefully mimic applications on the network. See Agent-to-Agent Test Overview for further information about agent-to-agent tests.
When choosing the protocol, consider the goal of the test: What kind of traffic are we evaluating on the network? Once we know that, we can choose the right protocol, port and additional settings. As always, the more closely you can mimic actual applications on your network, the more reliable and business-relevant the test results will be.
The default port number used for agent-to-agent tests, both for UDP and TCP, is 49153. Sometimes, the path visualization doesn't work as expected due to this port being blocked in firewalls between source and destination. If that happens, try to work with your firewall administrators to have this port opened. If that's not possible, find a port that is open between source and destination to ensure the best possible measurements.
Now that we've explained the end-to-end measurement, we can discuss the second part of the testing, which is the path trace. For the path trace, there are two options: ICMP and TCP. In general the same considerations apply for path trace as for the end-to-end test. Wherever possible, use TCP. The path trace traffic will be treated the same as the actual payload, giving the most reliable output of the path trace. If TCP doesn’t give the desired result, mostly because of misbehaving firewalls in the path, ICMP can be used as a fallback.