Note: The content below is relevant only to NS1 customers who have purchased the Pulsar Active Traffic Steering solution. To learn more, contact your NS1 sales representative.
Utilizing real time telemetry data, Pulsar can operate in two modes:
- The first leverages the basic Pulsar filter to sort answers from “best” to “worst” by the chosen performance metric as defined by the user.
- The second leverages the Pulsar Stabilization filter, which gives you greater control over dynamic routing decisions. A threshold can be defined to characterize an acceptable level of performance differentiation between available answers. While stabilization is active, any answers outside of this threshold will be removed. Answers within the threshold are kept and retain their order from the previous filter.
By default, the filter is configured to stabilize from the lowest value. This is most commonly used when comparing latency. Enabling Stabilize from Highest Value will pin the threshold to the highest value. This could be used for throughput, for example.
Absolute is the default way to define the threshold. Answers are compared against the "best" value and must fall within the defined threshold to be considered acceptable. For example, if the absolute threshold is set to 50, answers within 50ms of the most performant answer are considered to be inside the acceptable threshold.
Alternatively, the Relative allows you to define the threshold using a percentage (instead of a hard-set value). For example, if set to 30%, answers within 30% of the most performant answer are considered to be inside the acceptable threshold.
There are some specific cases where the Pulsar Stabilization filter offers a unique approach to routing using Pulsar data. For example, a user can factor in additional information such as the cost associated with a specific CDN when compared to another or the need for user traffic to connect to the same CDN consistently when the latency is within an acceptable range.
Below are a few use cases to differentiate between the Pulsar filter and the Pulsar Stabilization filter.
All users routed to the most performant endpoint (Pulsar without Stabilization)
In this example, the basic Pulsar filter is used where there is no stabilization. The answers in the answer list will be sorted in order of most performant to least performant—ensuring all users are sent to the CDN with the lowest latency. The Sticky Shuffle filter provides a fallback if there is no sufficient or recent Pulsar data available.
Consistently distribute users to CDNs within an acceptable range (Pulsar Stabilization)
Here, the stabilization option is configured with a threshold of 100ms. The performance of CDN C is over 100ms worse than the best available option, CDN A. As a result, CDN C is removed from the answer list. CDN B’s performance is within 100ms of CDN A’s and as a result, Pulsar will make no change to their ordering. Users will be be evenly distributed to CDN A or CDN B with each user reaching the same CDN consistently (as defined by the Sticky Shuffle). Once CDN C’s performance reaches an acceptable level, traffic will begin to rebalance between all 3 CDNs.
Route users based on the cost of each CDN (Pulsar Stabilization)
This example introduces the cost filter prior to the Pulsar Stabilization. Here, a cost is associated with each answer and the answer list is sorted from lowest to highest cost value. Next, the Pulsar Stabilization filter is set to remove answers using a relative threshold of 30%. This filter chain configuration sends users to the lowest-cost CDN (unless that CDN is performing poorly). In this example, we can see that all answers are performing within the acceptable threshold, so Pulsar Stabilization does not remove any of the answers and retains the ordering from the cost filter.
For more information, contact the NS1 support team at firstname.lastname@example.org.