The ‘QoS change’ condition violates when QoS has been altered in either the outbound or inbound direction.
For the outbound direction, AppNeta Performance Manager (APM) uses ICMP port-unreachable messages to monitor for when that happens. Small UDP packets are sent to a random high port at the target, which is most likely unused. This is done to elicit a port-unreachable (PU) ICMP message. The PU packet contains in its payload the IP header of the denied UDP packet. By comparing the QoS marking in that header to the QoS marking we sent, we know whether QoS was altered en route. If the QoS found in the payload was altered or cleared, the condition violates. If it matches what we sent, we then check the inbound direction.
In order to know whether QoS was altered from target to source we compare the ICMP echo and response pairs used for continuous monitoring. Generally, the target will use the same QoS value as arriving packets, or it will zero the QoS. If the echo-response QoS is zero we have no way of determining whether the target cleared it, or it was cleared en route. So, the condition is not violated. If the echo-response QoS is non-zero and different from the echo-request, we know from the PU check that the outbound direction is fine, so most likely the QoS change happened inbound, and the condition is violated.
For dual-ended paths, the QoS detection in the inbound direction is different since dual-ended paths use UDP not ICMP. The source and target monitoring point are both configured to use the user-specified QoS value, so the source monitoring point simply has to inspect incoming UDP packets to determine whether the QoS was altered en route.
Quality of service changes are detected only if the path settings include QoS markings and an alert profile with QoS condition is applied. Quality of service changes are also only detected by the source monitoring point, so if QoS is added and then stripped by your ISP, which is upstream, changes to those markings won’t be detected by the monitoring point.
The PU check normally occurs every 5 minutes. This means that if a QoS change violation occurs, it takes this long to clear.