RUM-based (Pulsar) filters

IBM® NS1 Connect® customers leveraging real user monitoring (RUM) data collection to inform traffic steering decisions can use the premium RUM-based (Pulsar) traffic steering filters. These filters reference real-time performance and availability measurements from active application users when determining the best answer(s) to return to each requesting client.

  • The performance of an endpoint is determined by the measured latency (in milliseconds) experienced by active application users.
  • The availability of an endpoint is determined by a moving average (percentage) of successful connections within the last five minutes.
Attention: You must attach a Pulsar (RUM-based) job to the Pulsar data metadata field for each answer when using any of the RUM-based traffic steering filters.
Table 1. RUM-based traffic steering filters
Filter Description Related metadata

Pulsar Performance Sort filter

This filter rearranges the list of answers based on the real-time performance measurement specified in the answer metadata. Pulsar data
Pulsar Performance Stabilize filter This filter eliminates answers whose observed latency is not within the defined threshold. The threshold can be set to a percentage or value in milliseconds relative to the best or worst-performing answer. Pulsar data
Pulsar Availability Sort filter This filter arranges answers from the most available (i.e., a higher percentage of successful connections) to the least available (i.e., a lower percentage of successful connections). Availability is measured by a moving average of successful connections to the endpoint (e.g., CDN) over the last five minutes. Pulsar data
Pulsar Availability Threshold filter The filter eliminates answers whose availability percentage as a moving average over the last five minutes falls below the defined threshold. For example, if you define a threshold of 90%, any endpoint whose percentage of successful connections falls below 90% is eliminated from the answer pool. Pulsar data
Attention: As a best practice, combine RUM-based traffic steering filters with at least one other filter when configuring a Filter Chain. This configuration ensures a fallback strategy in cases where there is insufficient telemetry available to inform routing decisions. Placing standard traffic steering filters before the premium RUM-based filter ensures the other filters do not undermine the RUM-based traffic steering strategy.

Pulsar Performance Stabilize filter

This filter compares the latency measurements in the answer metadata and eliminates answers whose latency value is lower than the defined stabilization threshold. If there is not insufficient RUM data available to make a decision, the filter is skipped and all answers pass through to the next filter.

By default, the filter eliminates answers whose performance measurement exceeds the defined threshold. This behavior is ideal for latency-related RUM data where a higher value can slow traffic flow. Alternatively, you can enable the Stabilize from the worst value option. This setting is helpful if you use bandwidth-related RUM data (percentage), in which case a lower availability percentage indicates a potentially overloaded endpoint.

Within the filter settings, you must set a stabilization threshold. This value is compared to the latest RUM measurement in each answer to determine if the answer meets the criteria to remain in the answer list. If the RUM measurement exceeds the defined threshold, it is eliminated. You can set an absolute or relative threshold.

  • The absolute threshold is represented by a latency measurement in milliseconds. As such, a lower value is preferred as it indicates a faster response time. This is the default setting with a default value of 50 ms. The absolute threshold value is added to the best-performing answer
  • The relative threshold is represented by a percentage within which the observed latency measurement or other RUM data must remain within compared to the best-performing endpoint (answer).

Pulsar Availability Sort filter

By default, answers are sorted from most available to least available. If there is insufficient availability data, answers are passed through unchanged, and the decisions are reported as Insufficient data in the Global decisions dashboard. You must associate each answer with a Pulsar job to gather the statistics that are used to sort answers.

Pulsar Availability Threshold filter

This filter determines which answers have the greatest bandwidth based on a specified threshold, expressed as a percentage. This action provides the most available answers while dropping those not meeting the threshold. If there is not enough availability data, or if you do not specify a threshold in the Apply availability threshold field, answers pass through unchanged, and these decisions are logged as Insufficient data in the Global decisions dashboard.

Pulsar Performance Sort filter

By default, answers are sorted from lowest to highest value. You can enable the Sort from the worst value option to sort in ascending order to account for certain metrics that require answers to be sorted from highest to lowest. If there is not enough performance data available to make a decision, answers are passed through unchanged and are logged as Insufficient data in the Global decisions dashboard.

The default behavior (lowest to highest) works best when your sort criteria is latency because you want to send end users to endpoints with lower latency values. If you’re measuring bandwidth, you will sort from the highest value to sort in a way that places endpoints with higher bandwidth on the filtered answers list than lower-performing answers.

Pulsar Route Map filter

This filter searches for a source IP in at least one route map. If the IP is matched, answers with the associated targets are kept. This filter lets you control and automate routing behavior.

After you upload custom route maps, you can define the associated records to control and automate routing behavior. To activate the route map, you must attach it to at least one record. Maps without a corresponding record are inactive. The map itself associates IP ranges with at least one target that corresponds to the route_map_targets metadata value in an answer.

You can attach multiple route maps to the same record. When you use more than one route map, the filter attempts to find a match within the first listed route map. If the filter encounters an issue with the route map, it tries the next map, continuing until it finds a matching IP range with associated targets and answers.