Where to install measurement agents and measurement controllers, what can be measured, how to set the parameters, etc. That is what understanding measurement topology is all about. It is one of the key things regarding QoS measurements.
Measurement topology is something that deals with almost everything related to the Qosium measurement setup, including at least the following:
Thus, mastering the measurement topology is essential. To get started with Qosium measurements, consider the following:
In the next section, we go through typical topology models.
This section presents some general topology types. Please note that often, in reality, the topologies can be much more complex. However, even complex topologies typically resemble one of these at a logical level. In the presented measurement topologies, we focus only on two-point measurement cases.
A general two-point Qosium measurement with the QMCP flows, including a listener, is shown in the figure below. You can select the measurement controller’s location (e.g., Qosium Scope, Scopemon) quite freely. However, you should still consider the QMCP traffic flow orientation: they are chained, as seen in the figure below. The controller does not communicate directly with the Secondary measurement point but through the Primary. The optimal place in terms of minimizing the overhead is to run the controller in the Primary measurement point device. However, the QMCP connection between the controller and the Primary measurement point is very light-weight when measuring only average results and flow results. That is why the controller can very well be used remotely in a separate device, as illustrated in the figure.
Are you interested in how your connected service works from the perspective of an end-user? The end-to-end topology reveals that.
This topology is the simplest one, and it is very common. The communicating end devices also act as measurement points. Thus, the results give the most accurate view of how the measured interesting application traffic performs end to end, i.e., the QoS level the network path between the devices gives to the application.
Parameterizing such measurement is straightforward. Just tell Qosium that the measurement nodes are at endpoints, and Qosium calculates almost all the other parameters automatically. Even the packet filter is automatized. The automatic filter will include all the traffic between the end devices. If you are interested only in specific traffic flows, tune the filter manually.
Sometimes it is not possible to install Qosium Probe in the end devices on both ends. Also, it might be that you are interested in the performance of your own network part, not the whole end-to-end part. As a result, we get a measurement topology, where one measurement point is in an end device, but the other is in the middle of the application traffic path. In some cases, the other point is not directly in the path but located in an external device, to which the traffic of your interest is mirrored for measurement purposes.
This measurement topology is still sufficiently easy to parameterize. The key difference, when compared to the end-to-end topology, is that automatic filtering is not possible. Thus, you must always set the packet filter manually in this topology option.
What if you are interested only in the quality of some specific part somewhere in the network? In this case, none of the measurement points are located in end devices but the middle of the end-to-end path. When Qosium Probes are installed in the middle of the path, i.e., to devices through which the interesting traffic flows, parameterization is still straightforward. Parameterization is very similar to that of the One end-point topology. The only difference is in the placement parameters, naturally.
Consider a measurement topology like the Middle of the path, but where Qosium Probes are installed to external measurement devices, off-path, to which the interesting traffic is mirrored. Straightforward as such, but regarding passive measurement, there is one trick you need to parameterize so that the direction of the traffic can be determined. You need to set the Sender address parameters manually. Also, you cannot use the automatic packet filter in this topology. This is the most laborious basic topology in terms of parameterization. Should there be a NAT between the measurement points, you get a couple of parameter options more to do, but that is the most complex parameterization you can ever get.
Modern devices typically integrate multiple network interfaces. Consequently, it is essential to select the correct ones for the measurement. Choosing an incorrect interface is one of the most common mistakes in the measurement setup.
Consider the figure below. If you wish to measure the network path between the end-user device and the router, you need to select interface 1 in the end-user device and interface 2 in the router. By selecting interface 2 in the end-user device will show all packets coming from the router as lost. Besides, all packets received by the router are calculated as sent-info-not-found as their sending is not registered in the end-user device. If you select interface 1 in the router, the measurement will succeed, but the measured QoS includes the routing process performance. Of course, if that is what you want, then the interface selection is correct.
Since Qosium is a multi-thread solution, you can carry out interesting measurements by using only a single Probe. Consider if you perform a two-point measurement in the figure’s router. While the same Qosium Probe acts as the Primary and the Secondary measurement point, select different interfaces to them. For example, set the Primary measurement point to listen interface 2 and the Secondary to interface 1. What you get now with this kind of setup is the internal routing performance of the device. Moreover, since both of the measurement points are in the same device, the clock synchronization is ideal. You will be able to measure very accurate delay performance up to the microsecond level. Only the router’s internal process priorities cause some minor inaccuracies.
A two-point passive QoS measurement works only if the packet context in both ends matches. Consequently, if there is a tunnel, pipe, or similar within the network path, the measurement point selection needs some attention.
Consider the figure below: the application traffic is flowing inside a tunnel (e.g., VPNVirtual Private Network
A technique to provide a secure tunnel over a public network. between an end-user device and an application server. A successful QoS measurement can be made end-to-end since both of the end-points lie outside the tunnel. Also, a successful measurement can be carried out between the off-path external measurement points since they both see only the tunneled traffic. Nevertheless, for instance, a measurement from the end-user device to one of the external measurement points cannot be made since the packet context does not match. The end-user devices see the packets as they are, but the external measurement points see tunneled packets, often encrypted.
There are some exceptions. For example, MPLSMultiprotocol Label Switching
A routing technique in telecommunications networks that forwards data based on short path labels rather than long network addresses. tunnel does not include encryption, and Qosium is equipped with functionalities to dig the original traffic flows inside it. However, this depends on the platform and Pcap-version since not all of them can filter inside an MPLS tunnel. Without filtering, the QoS measurement will very likely fail. Of course, it is possible to perform manual low-level filtering based on individual protocol fields, but this gets easily laborious.
Consider the end-to-end measurement topology: which way is the traffic flowing? Determining that is very easy since the measurement points are the same devices that generate the traffic: just compare device addresses to the traffic addresses. But, what about in the off-path topology? You could think that it is obvious. Just look at the topology. But, Qosium does not see the topology as we do! Instead, Qosium Probes only see the device in which they run and now a single NIC through which all the traffic is coming in. The traffic is not originated, nor meant to that node, so there is no information left to tell which way the traffic was flowing in its original point of capture. Because of the two-point measurement, the measured one-way delay could be used to tell the direction, but as there can be clock synchronization errors, it cannot be trusted to cover all cases.
Therefore, there are special cases where you need to tell Qosium by extra parameters which way the traffic is flowing. This is done by the Sender parameters. You tell Qosium Probe, who, from its perspective, are the senders, i.e., the devices who send traffic towards the other measurement point. See the figure below. If, for example, one end-user device on the left-hand side of the figure is communicating with an application server on the right, the end-user is a sender from the Primary measurement point perspective. Then, the application server is a sender from the Secondary measurement point perspective. That you need to tell Qosium with parameters. It is typically enough to determine the senders only in one measurement point and then use the inverse definition (in Qosium Scope: According to primary/secondary Probe) in the other.
Qosium allows setting senders as individual addresses or as address range by using a mask. Senders can be set independently for IPv4, IPv6, and MAC addresses.
Network Address Translation
A technique for remapping an IP address space
Virtual Private Network
A technique to provide a secure tunnel over a public network.
Multiprotocol Label Switching
A routing technique in telecommunications networks that forwards data based on short path labels rather than long network addresses.