PathView is AppNeta’s network performance monitoring capability. From complex, multi-layer LAN and WAN, to hosted MPLS and beyond, PathView can provide a level of visibility into network health and performance not achievable with conventional tools.

Consider two applications attempting to communicate via a public or private network: the series of hops that packets take from one host to the other is a path. The end-to-end performance of that path, in terms of capacity, latency, data loss, etc., is the result of a complex combination of geography, network capabilities, priorities, and limits; and it’s vital to end-user experience.

PathView is designed to continuously monitor the various metrics that impact the delivery of application data from the source, through the network, to the destination. It does this using appliances that are surrogates for actual end-stations, and something called packet dispersion analysis. Essentially, appliances periodically send out a burst of packets with a precise inter-packet gap, and then measures the response to each of those packets. Several measurements can be made directly, like latency and jitter, while other measurements are inferred, like total capacity.

In addition to continuous monitoring, PathView has diagnostic and assessment capabilities. A diagnostic is a hop-by-hop analysis of a path, using the same technique as continuous monitoring; this analysis enables you to determine where and why a path is performing poorly. Data assessment is a tool that enables you to assess the health of an entire network, rather than just a single path. It rates on a proprietary readiness scale how paths would perform if they were loaded with user-generated application data.

How PathView works

PathView is designed to continuously monitor the various metrics that impact the delivery of application data from the source, through the network, to the destination. It does this using appliances that are surrogates for actual end-stations, and something called packet dispersion analysis. Essentially, appliances periodically send out a burst of packets with a precise inter-packet gap, and then measures the response to each of those packets. Several measurements can be made directly, like latency and jitter, while other measurements are inferred, like total capacity.

What is capacity?

Any discussion on how PathView works should start with capacity. Total capacity is the highest transmission rate that you can achieve between sender and receiver when no other traffic is on the line. In theory, capacity can be calculated for each segment in the path, and end-to-end capacity is equal to the lowest segment capacity. In other words, you’re never going to go any faster than your slowest link.

Total capacity is calculated based on measurements from numerous test iterations containing various packet sequences. The accuracy of this technique is not affected by variations in latency or cross traffic, e.g., a network path with a 10 Mbps total capacity already considers the other traffic on the network, and reflects this capacity regardless of distance to the target.

Capacity is not bandwidth

It’s important to differentiate capacity from bandwidth. Bandwidth means different things to different people. For our purposes, we’ll say that bandwidth is the potential transmission rate of the physical medium. It’s agnostic of any communications standard so there’s nothing standing in the way of putting bits on the wire except for the type of media and the network cards in use.

Capacity on the other hand is a throughput measurement from the perspective of the network layer where some rules of communication are considered. At the network layer, ‘data’ is IP packets rather than just a constant stream of bits. IP packets are subject to a maximum size in order to accommodate link layer headers and framing overhead, and are also subject to the mechanics of routing, namely queuing delays.

So while capacity and bandwidth are both throughput concepts, they assume different perspectives. Because of this, capacity measurements will generally be lower than any bandwidth value that is marketed by your ISP. Regardless, capacity is the best representation of how your applications are experiencing the network.

How is capacity measured?

PathView uses packet dispersion analysis to calculate capacity. At it’s simplest, the technique is as follows: send out two packets of equal size back-to-back, with no other traffic on the line. What we’re interested in is the distance between those packets by the time they reach the target, which we call dispersion. 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.

The method above can only be used when the target is an AppNeta appliance because coordination is required between the path endpoints. But, PathView actually offers two different methods for continuous monitoring. Dual-ended monitoring is the method that requires appliances as endpoints, and measurements are taken at the target. This method uses UDP packets. Single-ended monitoring on the other hand uses ICMP packets and can be used against any desired target. The source sends out two back-to-back pings and the target replies to each. Now instead of observing the packets as they arrive at the target, the source can measure round-trip time for each ping + response pair. Half the difference between the two round-trip times is the one-way dispersion.

Going off the rails on a packet train…

Whether we use one-way or round-trip times, real networks present a few obstacles to the packet pair method. For example, sometimes packets get dropped. Losing one packet when you only have a pair is a problem. Packets might not get queued, in which case there’s no dispersion and capacity gets overestimated. Not least, analysis is premised on packets dispersing with each hop, but if queueing is uneven between the first and second packet, you could get compression instead. You might think that you could just send out a 1000 packet pairs and average the results, but that leads to spurious results. Instead, PathView overcomes these obstacles by using many back-to-back test packets, or packet trains.

The measurement process is iterative:

  • 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.
  • Measurements are taken every 1 minute; there are up to 50 packets per train; and iterations start with PMTU for packet size.
  • PathView considers the best option for total capacity measurement to be a train with the largest packet size possible but still experiences zero loss.

Anything that affects the round-trip time of test packets including low-bandwidth links, congested links, and operating system effects, are already considered in the capacity measurement. But these are the same effects your applications are experiencing.

Why you need 10G to measure at 10G

It’s true that PathView is low impact. Continuous monitoring uses on average just 2 Kbps and diagnostics only 10-200 Kbps. But you still need a 10G appliance to monitor at 10G. PathView is interested in dispersion, which is how much the distance between two packets grows while traveling from A to B, and packet dispersion is premised on queuing. To guarantee that packets actually get buffered you need to send them out with very small inter-packet spacing. Some serious hardware is required for that kind of transmission rate and the timestamping fidelity to go along with it, which is why we introduced 10G appliances.

The advantages of capacity over bandwidth

There are two major advantages of using capacity over bandwidth 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 measured at a higher layer in the network stack, closer to the application layer. It’s the equivalent of moving closer to someone so you can see what they’re pointing at.

The other reason that capacity is better is because the method used to measure it, packet dispersion, is extremely lightweight. As a result the network can be monitored continuously. Bandwidth on the other hand, using tools like PathTest or speedtest.net, is measured in a destructive fashion. They essentially generate huge bursts of packets with the goal of entirely saturating the path to the target. This technique makes the network inoperable for the duration of the test. The implication is that bandwidth testing has to be scheduled rather than continuous, and the test only ever returns maximum bandwidth, never utilized bandwidth.

Deriving available and utilized capacity

Available capacity is calculated using the average dispersion of a series of packet trains. Compare that to total capacity which uses the minimum dispersion over a series of packet trains.

You might ask, ‘why average dispersion?’ Available capacity is straight-forward case of what you see is what you get. If you send out a series of bits, whether test packets or other application traffic, the rate at which those bits reach their target, the throughput that they experience, is what is available to the application. There is no more capacity because other apps are using it, and there is no less because no other apps are asking for it. At AppNeta we use this analogy: imagine a train with a hundred cars going by at some speed, and only a random half of those cars are carrying payload. If you have cargo that you need to get on that train, to you that train is at 50% capacity, regardless of which cars are already full. Once we have available capacity in hand, subtract it from total capacity to calculate utilized capacity.

There’s one caveat. Packet loss and capacity are related: a test packet that returns too late or never returns indicates zero available capacity, or 100% utilization. To account for brief periods of 100% utilization, PathView includes a coefficient of packets lost in its available capacity calculation.

How is latency measured?

Every 1 minute, PathView sends out multiple packet trains each with a specific packet size and number of packets per train. Among all of those test packets, the one with the fastest round-trip time is used to calculate latency. Latency is equal to one half RTT.

Deploy PathView

You can actually setup quite quickly by setting up a bunch of paths with the default configuration. But rather than simply taking the fastest route to monitoring, this workflow aims to give you leave you with a PathView deployment that makes sense for your operating environment, and is easy to manage in the long run. To be successful, you’ll need to have a high-level understanding of your network, and the access required to reconfigure networking equipment and workstations. If that’s not you, then the challenge for this deployment will be more on a human rather than technical level. You’ll have to coordinate with your network and systems admins, and most likely schedule some of this work. We strongly recommend that you consider this workflow a rubric for the determining your stakeholders and the planning your deployment, rather than an action list that can be completed in one session.

Deploy an appliance

Three out of our four modules require an appliance of some type: PathView takes any type, FlowView takes a physical appliance, and you’ll need a physical or virtual appliance for AppView if there’s no global web monitor in the location you want to monitor from. So before you can dive into all these modules, you’ll first need to deploy an appliance. Deploying actually requires a bit more planning than doing—you’ll need to coordinate with your network administrator—so you don’t need to wait until your appliance is in hand to get started.

Deploy an appliance now…

Choose your targets

Once you’ve identified which application you want to monitor, this step is about mapping the application to an IP address or hostname. In plain language this means, ‘what is the thing you are trying to reach via the internet?’ If its a web service, either one you build or one you consume, you’ll want to target the webserver. If you’re monitoring voice/video, the best target is an AppNeta appliance in the same network segment as the handset or workstation of the person you are trying to contact. Appliances as targets yields the most accurate data, plus it’s a requirement for voice tests. If you don’t have an appliance deployed in that area, your next best option is the handset or workstation itself, however it’s important understand how these targets impact capacity measurements.

Data or voice?

Setup is the same whether you’re monitoring voice, video, large data transfers, or transactional data, with one exception. To monitor voice quality, you’ll have to know which audio codec your voip deployment is configured to use, so that PathView continuous monitoring can properly simulate that traffic. In case you’re wondering why codec specification isn’t required for video, this is because even though video data is subject to sampling and compression just like voice, and the same application level protocols are used to transmit that data, the end result amounts to a large data transfer which is addressed natively by PathView continuous monitoring.

Is QoS applied?

Monitoring the application path is not just about the route that traffic takes, but also the prioritization—or ‘quality of service’—the traffic receives while in transit. This because your intention should be to use PathView to understand the network from the perspective of your applications.

QoS is determined by the network administrator and an essential part of any traffic engineering strategy. If you’re unfamiliar: when routers experience congestion or otherwise have insufficient resources to handle the incoming traffic volume, they have to make decisions about what traffic to expedite, what traffic can wait, and under extreme circumstances, what traffic to drop. How they’re able to determine this on a per-packet basis is through DSCP markings. DSCP is simply a value that goes into the IP packet header that routers can read to understand a packet’s intended priority level. Packets get a marking, which maps to a queue on the router, and those queues are emptied according to some algorithm like round-robin or WRED. Packets pass through multiple administrative domains (AD) on their way from A to B on the public internet, and so there are some DSCP values that have an agreed upon meaning like EF and AF. But it’s not mandatory that those values be honored; they may be rewritten at any hop along the path; and there are also non-standard values which you may use within your AD, but have no agreed upon meaning in the outside world.

Now that you know what QoS is and why it’s important to PathView monitoring, it follows that before you make a path you’ll want to know whether QoS is applied within your AD. If it is, you’ll specify that in the path configuration, and choose an alert profile with a QoS condition so that you can verify that the QoS you intended isn’t being changed en route. How QoS changes are detected is described here.

Set up PathView alerts

An alert profile is a set of performance thresholds, the purpose of which is to continuously monitor for undesirable performance. In PathView, alert profiles can be used to monitor for a variety of path metrics including network connectivity, utilized capacity, and dscp changes. Choose a system-defined profile or create your own, and then apply one or more to a path. PathView will then annotate performance charts, generate logs, and notify you by email and/or snmp any time performance is not up to par.

Setup PathView alerts now…

Asymmetric first mile?

The first mile—or last mile, depending on your perspective—is the link that connects the customer’s LAN to the access layer of the ISP. In many cases it’s asymmetric and therefore likely the bottleneck. AppNeta recommends that any path that includes this link be a dual-ended path. Even if you know that the is link provisioned equally for upload and download, make at least one of your paths dual-ended—perhaps to a AppNeta WAN target— so that you can verify that this is the really what your applications and end users are experiencing. And if you know the link to be asymmetric, you should definitely make the path dual-ended because when a single-ended path is used in this this scenario, all of your capacity measurements will reflect the slower of the two directions.

LAN or WAN?

PathView differentiates LAN from WAN according to these definitions. But, for ease of use, you can set all of your paths to LAN. PathView performs a nightly check, and any paths designated as LAN are changed to WAN if it meets the WAN criteria, and your LAN/WAN counts are adjusted accordingly. It’s important to note that the reverse is not true. WAN paths are never changed to LAN even if LAN is the appropriate designation or a transient condition flipped LAN to WAN. Keep in mind that you might run out of licenses if many paths change from LAN to WAN overnight.

Set up a path

Paths are added in PathView via the add paths page. Using the left-side navigation panel, select PathView > path list and then click ‘+ add path’. The path setup wizard is the most involved of the three add-path methods in PathView, but it’s the preferred method. You can configure one or more paths at a time, target any reachable IP address world-wide including other appliances, and it makes all path attributes available for customization.

Set up a path now…

Create a notification profile

Event notices are emails about changes in appliance availability and path performance. The set of rules which determine when notices are generated and sent are called profiles. There is a default profile which applies to all paths, but you can add exceptions to it by creating additional profiles. Within a profile you can specify the organization, paths, and events that trigger notices; the addresses to which notices are sent; and the frequency of notices.

  1. Navigate to > update notification options.
  2. ‘Default email addresses’—applies to all profiles that don’t have their own address list. Click the email address link to edit the default list.
  3. ‘Enable service bulletins’—Support occasionally needs to send service related emails. Emails are sent to the default addresses specified in your account settings.
  4. For profiles that should not use the default list, add addresses through the profile action menu.
  5. The following events can be selected to trigger a notification. If you choose ‘digest summary’, all notices triggered during the digest period are aggregated into a single email, so that addressees receive fewer emails.

    Violation event
    Notices are triggered by alert threshold violation and clear events. To apply notification rules to only some paths in an organization, you’ll need to use saved path lists: first trash the ‘all paths’ list, then click ‘add list…’. You may add more than one path list to a profile. For PathView violations, you can also choose to receive additional notices when a diagnostic completes and/or fails.
    Appliance availability
    Notices are triggered whenever the appliance loses its connection or reconnects to AppNeta . For time windows, enter times according to appliance timezone.

How to unsubscribe: The footer of event notification emails indicates which notification profile triggered that email, and contains a direct link to edit that notification profile.

SNMP notification

You can configure appliances to generate SNMP traps upon PathView violation and clear events from > manage SNMP. Traps are generated for all paths in the organization, but only one appliance is responsible for sending the traps to the NMS. The appliance designated the ‘trap sender’, must have an SNMP trap license. Appliances with an SNMP NMS license may be polled for violation events in the last 15 minutes. Only violations on paths for which the appliance is the source are reported; the associated objects are in the ‘pathview’ table of the MIB. The default community string is ‘public’; this can be changed from web admin.

Pending release: PagerDuty is a popular tool used by teams to centrally manage alerts from multiple services and systems. You can optionally integrate AppNeta with PagerDuty so that our alerts can also be managed from there. See > Manage PagerDuty Integration, which will guide you through integration.

Go solve problems!

PathView returns continuous monitoring data on the path performance page. You’ll likely want to start by examining capacity measurements. If capacity seems too high or too low, or your charts or data isn’t loading, see the section on performance analysis.

Also check out path diagnostics. Anytime you set up a path the first thing PathView does is run a hop-by-hop diagnostic. You’ll find a link to that diagnostic in the right-side panel of the path performance or path list page. Diagnostics are dense with data, but luckily PathView does the interpretation for you and produces a summary of issues. Each of those issues, or messages, are fully explained here.