Pulsar is NS1’s infrastructure-aware, active traffic steering solution built to optimize application delivery across complex globally distributed networks. It uses real user monitoring (RUM) to measure the performance and availability of your application delivery endpoints — such as application servers, web servers, and CDNs — from the perspective of real end users. The NS1 platform uses this real-time, performance-based telemetry to inform DNS traffic routing decisions.
Compared to standard geographic-based traffic steering mechanisms, RUM data collection provides a more accurate representation of internet topology and congestion points in the end user’s journey. It considers the way the fiber connections of the internet run as opposed to their geographic location, and it evaluates real-time endpoint performance and availability. Standard geo-steering tools are limited to making proximity-based decisions — even if the nearest endpoint will not deliver the best experience to your end user.
With multi-CDN networks, for example, an “endpoint” represents multiple edge locations worldwide. Intelligent traffic steering in edge networks requires more granular mapping of end users to CDNs and it must be able to adjust to real-time changes to network conditions. Using RUM data, Pulsar routes each incoming query to the best possible endpoint at the time of query, prioritizing the experience over geographic proximity.
During initial setup, you will work with the NS1 team to configure data collection from either community (shared) or private data sources. You collect data from private resources using an embedded JavaScript tag or beaconing data to the NS1 platform.
Next, if using private data sources, you will create your own Pulsar applications and jobs. Each Pulsar job corresponds to an individual endpoint (CDN, web page, or server). The NS1 team will configure your applications and jobs if you use community data sources.
Then, you will connect each Pulsar job to its corresponding DNS answer(s) to enable automatic updates from the Pulsar-enabled resource. This ensures the answer metadata is always updated with the latest RUM data.
Finally, to activate the configuration, you will configure a Filter Chain for the corresponding DNS record using one of the Pulsar performance or availability filters. You can use these filters with other NS1 filters to define a routing logic the NS1 platform will use to process all queries to that record. Note that the order of filters in the Filter Chain matters, and some require you to apply additional configuration options.
In real-time, RUM data based on active users as they connect with an application is collected from community or private resources (CDNs, servers, web pages, etc.) and sent to the NS1 platform. NS1 ingests this data and then updates the Pulsar metadata values of the DNS answers connected to each Pulsar job.
When the DNS record is queried, the NS1 platform references the Filter Chain configured to determine how to process the incoming query. Depending on the Pulsar filter you’ve included in the Filter Chain (and the order it appears), NS1 will either arrange answers in the list or eliminate answers based on their current performance or availability metrics. This ensures DNS traffic is directed to the best-performing endpoint (based on real-time latency data) or the endpoint with the highest percentage of successful connections within the last five minutes.
As network conditions change, the Pulsar-related answer metadata is updated, so the latest RUM data always inform the routing decisions.
You can view collected data using the Pulsar dashboard in the NS1 portal or by integrating with Grafana. These data visualization tools allow you to observe trends, detect anomalies, and compare the performance and availability of resources across your network.
In the NS1 portal, you can view the following RUM-based reports:
Traffic distribution by location
Traffic distribution by ASN
Response time by resource
Availability by resource
During implementation, you can configure Pulsar to leverage community or private data sources to inform routing decisions.
Community data is a turnkey solution allowing you to collect RUM data aggregated from various NS1 partners, including top CDNs and cloud services. This method is ideal for enterprises employing multi-CDN solutions without access to an inventory of impressions. It allows you to route users to the most performance or cost-effective option for their local connection.
Private data (sometimes called “bring your own” or BYO data) refers to data collection from your privately owned resources. It is configured by embedding a JavaScript tag on web properties or by beaconing data (via gRPC or HTTP) from existing resources that already collect RUM data.
-
Option A: JavaScript tag
This method of private data collection employs a JavaScript tag embedded in your web properties, including application servers, web servers, and CDNs. Each Pulsar-enabled resource (i.e., Pulsar job) hosts an asset, such as a single-pixel image, to measure availability and latency when executing the JavaScript tag. Upon each page load, the tag executes asynchronously in the background to collect RUM data directly from your user “eyeballs” or impressions.
-
Option B: Beaconing data via gRPC or HTTP
You can beacon existing telemetry to an NS1 API endpoint if you are already collecting RUM data. Data can be collected from your own CDN footprint or any combination of servers, data centers, or cloud providers. All data should contain some performance-based measurement, such as latency, to reference when routing.
Depending on your chosen data collection method, you will create Pulsar applications and jobs corresponding to a resource — specifying the job type (JavaScript or beaconing) and other configuration settings.
If using a private data collection method, you must create Pulsar applications and corresponding jobs. A Pulsar application refers to a collection of Pulsar resources (a group of resources being measured. Upon each impression — for example, every time an embedded JavaScript tag is run — the Pulsar engine references the application ID (appID) to determine which set of jobs should record a measurement. When creating applications, you can define default settings for all jobs within that application. You can override these settings at the job level as needed.
Each Pulsar job corresponds to a specific resource (CDN, data center, private cloud, etc.) being measured. During initial configuration, you will create one or more jobs within an application, defining global default settings and other configuration details. Then, you will connect each Pulsar job to the corresponding answer via the answer metadata.
Optionally, you can configure Pulsar jobs to allow interactions over HTTP instead of DNS. See Decisions over HTTP below for details.
NS1’s Filter Chain technology allows you to customize traffic steering logic for your DNS records. You can select from a portfolio of filters and arrange them to define a policy used to process incoming queries against the record’s associated domain. Upon each incoming query, each filter either sorts or eliminates answers (endpoints or resources) in the answer pool based on some criteria before passing the remaining answers to the next filter in the chain. This helps to ensure requesting clients are directed to the best possible endpoint based on current network conditions and your unique objectives.
Pulsar customers can access specialized filters referencing real-time performance and availability metrics to make routing decisions.
Note
NS1 strongly recommends using the Pulsar filters in conjunction with other NS1 filters — specifically, putting other filters ahead of the Pulsar filters as a fallback strategy in case there is insufficient performance telemetry at the time of a query.
There are five different Pulsar filters:
Pulsar Performance Sort filter
Pulsar Availability Sort filter
Pulsar Performance Stabilize filter
Pulsar Availability Threshold filter
Pulsar Route Map filter
The table below briefly describes each Pulsar filter and the answer metadata field(s) referenced by each to inform their decisions.
Filter name |
Description |
Relevant metadata |
|---|---|---|
Pulsar Performance Sort |
This filter arranges answers based on the latest performance data available for each resource. Specifically, it measures latency by time to the last byte (ttlb). |
Pulsar data (latency in ms) |
Pulsar Availability Sort |
In the context of Pulsar, availability is measured by a moving average of successful connections to the endpoint (e.g., CDN) over the last five minutes. 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). |
Pulsar data (availability %) |
Pulsar Performance Stabilize |
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 (latency in ms) |
Pulsar Availability Threshold |
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 (availability %) |
Pulsar Route Map filter |
For those using Pulsar Route Maps, this filter searches for the requester’s source IP to determine the best target endpoint based on your custom route map file. |
Route maps and Route map targets |
Refer to Overview of Pulsar filters to learn more about each filter.
After configuring your Pulsar applications and jobs, you will connect each job to the corresponding DNS answer(s) via the answer metadata within the “Pulsar data” section.
After selecting the Pulsar job from the drop-down menu, you are given the option to define an availability threshold and/or define any biasing that should be applied to this answer’s Pulsar metadata.
-
Availability threshold - If you are using or plan to use the Pulsar Availability Threshold filter, you must define a minimum percentage allowed for an answer to remain in the available answer pool. Answers whose average availability over the last five minutes falls below the defined threshold will be removed from the answer pool as queries are processed by the Filter Chain.
-
Biasing - Optionally, you can apply a “bias” to the metadata value to offset the collected performance measurement. You can add (plus) or subtract (minus) some number of milliseconds or specify a positive or negative percentage to apply to the measured latency of this endpoint. Any Pulsar Performance filters will use the adjusted value instead of the "real" value to determine the best-performing endpoint.
For example, if you would like the NS1 platform to give preference to a certain CDN, you can add a bias to the relevant DNS answer that will be applied to all future latency measurements. This ensures that the CDN is given higher preference, even if its performance measurements are not as high as other answers.
Note
Biasing only applies to Pulsar performance (latency) data for this endpoint. It does not impact availability measurements.
The Pulsar decision service allows interaction with Pulsar over HTTP — giving you the same decision-making power as the DNS mechanism. Decisions over HTTP, instead of DNS, is a better-suited solution to certain use cases like streaming application delivery. In traditional DNS, the recursive resolver can serve queries from the cache. Using HTTP instead of DNS removes this layer and allows Pulsar to be extensible beyond DNS.
When queried, the decision service via HTTP returns an ordered list of optimal answers, making it compatible with client integrations and CDN token authentication.
For example, those with video-on-demand or live-streaming applications are likely to prefer decisions over HTTPS if they are endpoint decisions on behalf of their end users, as it is more efficient than doing so using standard DNS mechanisms.
By default, Pulsar makes traffic routing decisions based on collected GeoIP and ASN data which is updated continually based on observed usage patterns. Alternatively, for more direct control over routing decisions, you can use Pulsar Route Maps to specify which locations are accessible to specific users based on a declarative data model.
During implementation, you will upload a custom route map file containing a list of IP ranges in CIDR notation and their respective target(s). Targets are applied to individual answers within the DNS record via the answer metadata. The configuration is activated once a Filter Chain configuration containing the Pulsar Route Maps filter is applied to the DNS record. Learn more.