The Packet Train Difference for Network Visibility Why all throughput measurements are not created equal
A number of factors can impact application performance but without a doubt, one of the most important factors outside of the application itself is the performance and throughput of the network paths the app runs on. In order to get a comprehensive view of the network impact on an application, AppNeta relies on its patented, packet train dispersion technology to give unprecedented visibility across complex, multi-layer LAN, WAN, MPLS and other networks.
Unlike other network performance solutions that provide you with basic latency and round-trip time metrics at a point in time, our technology gives you continuous monitoring of both basic and advanced metrics. Additionally, unlike other network tools that may flood your network and provide you with bandwidth throughput measurements, we provides you with more advanced capacity throughput measurements that are critical to giving you a more accurate measure of network performance.
- Continuous monitoring of critical network metrics impacting application delivery and user experience for IT and DevOps teams
- Bringing you closer to the application layer with capacity throughput metrics
- Providing more precise and accurate measures of network resources available to the application
- Minimal to no impact on production environments
What is packet train dispersion analysis?
Packet train dispersion is AppNeta’s patented technology that directly measures key network performance metrics (latency, jitter, round trip time (RTT), etc.), while inferring others (total and used capacity).
How does it work?
Packet dispersion analysis uses AppNeta appliances as surrogates for actual end-stations to periodically send out bursts of packets with precise inter-packet gaps, and then measures the response to each of those packets. At its simplest, the appliances send out two packets of equal size back-to-back, with no other traffic on the line.
Dispersion is the distance between those packets by the time they reach the target. To calculate dispersion, we measure the time between the arrival of the last byte of the first packet and the last byte of the second packet. Divide the packet size by dispersion to calculate the end-to-end capacity of the path in bits per second.
Unfortunately, real networks present a few obstacles to the packet pair method. For example, sometimes packets get dropped. Other times, packets might not get queued, which leads to a lack of dispersion and capacity gets overestimated. PathView overcomes these obstacles by using many back-to-back test packets, or packet trains. The measurement process is iterative and each iteration consists of multiple packet trains with a specific packet size and number of packets per train. Multiple trains enables us to tolerate some loss, while using large packets guarantees queuing.
Why is it important?
Packet train dispersion is designed to continuously monitor the various metrics that impact the delivery of application data from the source, through the network, to the destination. In other words, packet train gives IT and DevOps teams the in-depth visibility they need to ensure applications are being successfully delivered to end users.
Additionally, packet train dispersion is the only technology on the market to give teams critical throughput measures such as total available and actual used capacity. Unlike bandwidth throughput, capacity has two major advantages as a measure of network performance. The first is that capacity is a more accurate measure of the network resources available to the application. This is because capacity is measured at a higher layer in the network stack, closer to the application layer.
The other reason that capacity is better is because the method used to measure it, packet dispersion, is extremely lightweight. Bandwidth on the other hand, generates huge bursts of packets with the goal of entirely saturating the path to the target. This technique makes the network inoperable, rendering it difficult to use for live production environments. Bandwidth testing has to be scheduled rather than continuous, and the test only ever returns maximum bandwidth, never utilized bandwidth. As a result, capacity on the network can be monitored continuously.