While the Delivery monitoring tools that run by default (Continuous Path Analysis (CPA) and Deep Path Analysis (DPA) / Diagnostics) measure the capacity of a network path, they do this by sending relatively small packet trains and then calculate the path’s capacity based on the dispersion between the packets on the receiving end. Because they create very little load, it is possible that the network will behave differently (provide a lower capacity) once it is actually loaded. For example, some ISPs trigger rate limiting when your traffic rate crosses a threshold, other ISPs market a ‘burst’ technology, which means that they’re limiting your regular capacity, but give you more for short periods of time, for example, during large downloads. In either case, your true available capacity is the one in the rate-limited state.

PathTest and Rate-limited monitoring are tools that can be used to generate a load that triggers these techniques and then measure the capacity of the network under load. PathTest is used when you need to make a single measurement. Rate-limited monitoring is used when you need to make measurements at regular intervals over time. Both of these tools require a monitoring point at each end of the network path being tested (i.e. a dual-ended path).

Caution: While these loading techniques produce accurate results, be aware that they can have an impact on the available network capacity for the duration of a test.

PathTest

PathTest is a powerful load generation tool used to examine the network capacity between two endpoints on a LAN or WAN link. With PathTest, it is possible to accurately measure the available ICMP, UDP and/or TCP capacity and analyze the behavior of a network under different traffic loads.

Examples of how you can use PathTest include:

  • Verify that a link can achieve the capacity provisioned by your ISP.
  • Generate traffic with a QoS DSCP marking to verify or stress a traffic engineering strategy. This can be used to confirm that traffic with a given DSCP marking is given priority over best-effort traffic.
  • When separate bandwidth is allocated to data and voice, use PathTest to stress the network with data and voice traffic.

Things to keep in mind

  • By default, only Advanced and Organization Admin user roles can run a PathTest.
  • Networks treat different traffic types in different ways.
    • For example: data vs voice, protocol used (ICMP, UDP, TCP), and QoS type.
    • Use PathTest to see how the network behaves using the traffic type(s) expected on it.
  • Networks can be provisioned asymmetrically.
    • For example: Uplink capacity lower than downlink capacity.
  • There can be a large discrepancy between a test using UDP and the same test using TCP.
    • This is due to TCP’s flow control mechanism as well as the affect of packet loss and retransmissions on TCP. It can also be due to the distance between source and target as Round-trip time (RTT) plays a significant role in TCP networks.
    • This can be addressed by running more than one stream when using TCP. Set bandwidth to maximum expected capacity (e.g., 1000Mbps) and run a test. Then, gradually increase the number of streams (e.g., 5, 10, …) and decrease the bandwidth proportionately (e.g., 200Mbps, 100Mbps, …) until UDP tests and TCP tests show the same results.
  • The number of packets seen in a packet capture will be less than the number actually sent on the network by PathTest.
    • By default, at the driver level, PathTest sends multiple copies of a packet “on the wire”. This means that a packet capture will show only a small percentage of the traffic actually sent on the network by PathTest. For example, on physical monitoring points the multiple is 20. So 20 packets are sent on the wire for every one seen in a packet capture.
  • For PathTest using UDP:
    • PathTests using UDP are the best way to test general network capacity.
      • UDP is considered true data traffic (unlike ICMP which is considered control traffic) and it doesn’t have flow control and retransmissions like TCP.
    • The target must be a monitoring point or an AppNeta WAN Target.
    • Tests are unidirectional.
      • Inbound tests are started after outbound tests complete.
  • For PathTest using TCP:
    • PathTests using TCP are the best way to test the capacity of networks carrying TCP traffic.
      • As TCP uses flow control and retransmissions (unlike UDP and ICMP), the PathTest results can show a lower capacity than with UDP. The results, however, will show the true capacity to carry TCP traffic.
    • Test with multiple PathTest streams to better saturate the network with TCP traffic.
    • The target must be a monitoring point or an AppNeta WAN Target.
    • Tests are unidirectional.
      • Inbound tests are started after outbound tests complete.
  • For PathTest using ICMP:
    • ICMP is considered control traffic rather than true data traffic (like UDP and TCP).
      • Control traffic is treated differently than data traffic by network equipment.
    • The target does not need to be a monitoring point or an AppNeta WAN Target.
      • Use PathTest with ICMP when you don’t have a monitoring point at the far end of the path.
      • For PathTests using ICMP, tests are more accurate with a monitoring point on the far end.
    • Tests are bidirectional.
      • The source sends packets and the target simply replies.

Run a PathTest

To run a basic PathTest using UDP:

  1. In APM, change organization to the one containing the monitoring point you want to run the PathTest from.
  2. Navigate to Delivery > Path Plus.
  3. Click the PathTest tab.
  4. In the PathTest Settings pane:
    1. Select Data.
    2. Set Source to the source monitoring point.
    3. Set Target to the target monitoring point or AppNeta WAN Target.
    4. Set Protocol to UDP.
    5. Set Direction to Both (Sequential).
    6. Set Bandwidth to Max.
    7. Click Run Test.
      • Observe the results when the test finishes.

Rate-limited monitoring

When Rate-limited monitoring is enabled, APM instruments the network path with controlled bursts of packets at the total capacity rate in order to trigger the network’s rate-limiting mechanism. The source sends packet bursts outbound and the target sends packet bursts inbound. The rate at which the monitoring points receive the packet bursts determines the rate-limited capacity. These bursts, though brief, have more impact on the network than AppNeta’s standard monitoring techniques, but are required in order to trigger the rate limiting mechanism.

As Rate-limited monitoring generates network load, it must be used with caution. To that end, it is not enabled by default and must be enabled by AppNeta Support.

All user roles except View Only users can disable Rate-limited monitoring. Standard users can adjust the monitoring interval but no other settings.

To use Rate-limited monitoring:

  1. Open a support ticket to enable Rate-limited monitoring.
    • Once enabled, the Rate Limiting Capacity chart appears on the path performance page. There are some chart controls in the Analysis Modules panel.
    • If you disable rate-limited monitoring, only AppNeta Support can re-enable it.