Getting started with Pulsar RUM-based traffic steering
IBM® NS1 Connect® provides an infrastructure-aware, real user monitoring (RUM) traffic steering solution built to optimize application delivery across complex globally distributed networks.
Pulsar RUM traffic steering is available as an add-on feature to a Premium plan.
RUM measures 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 Connect 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 doesn't 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, NS1 Connect routes each incoming query to the best possible endpoint at the time of query, prioritizing the experience over geographic proximity.
During initial setup, you 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 NS1 Connect.
Next, if using private data sources, you create your own RUM applications and jobs. Each job corresponds to an individual endpoint (CDN, web page, or server). The IBM support team configures your applications and jobs if you use community data sources.
Then, you connect each job to its corresponding DNS answer(s) to enable automatic updates from the RUM-enabled resource. This ensures the answer metadata is always updated with the latest RUM data.
Finally, to activate the configuration, you configure a Filter Chain for the corresponding DNS record using one of the Pulsar performance or availability filters. You can use these with other traffic steering filters to define a routing logic that NS1 Connect uses 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, and so on) and sent to NS1 Connect. NS1 Connect ingests this data and then updates the metadata values of the DNS answers connected to each RUM job.
When the DNS record is queried, NS1 Connect 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 Connect either arranges the answers in the list or eliminates the 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 answer metadata is updated, so the latest RUM data always informs the routing decisions.
You can view collected data using the Pulsar dashboards in the NS1 Connect portal, API, or 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 Connect portal, you can view the following RUM-based reports:
- Traffic distribution by record, location, autonomous system number (ASN), resource or job, and RUM filter
- Response time plus availability by location, ASN, and resource or job
- Errors
Data collection methods
During implementation, you can leverage RUM data collected from 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 Connect 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 (using 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 RUM-enabled resource 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 Connect 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 RUM applications and jobs corresponding to a resource — specifying the job type (JavaScript or beaconing) and other configuration settings.
RUM applications and jobs
If using a private data collection method, you must create RUM applications and corresponding jobs. An application refers to a collection of RUM-enabled resources (a group of resources being measured). Upon each impression, for example, every time an embedded JavaScript tag is run, the platform 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 job corresponds to a specific resource (CDN, data center, private cloud, and so on) being measured. During initial configuration, you create one or more jobs within an application, defining global default settings and other configuration details. Then, you connect each job to the corresponding answer via the answer metadata.
Optionally, you can configure RUM jobs to allow interactions over HTTP instead of DNS. See Decisions over HTTP for details.
RUM-based traffic steering filters
The Filter Chain 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.
RUM-based traffic steering customers can access specialized filters referencing real-time performance and availability metrics to make routing decisions.
There are five different RUM-based (Pulsar) traffic steering filters:
- Pulsar Performance Sort filter
- Pulsar Availability Sort filter
- Pulsar Performance Stabilize filter
- Pulsar Availability Threshold filter
- Pulsar Route Map filter
The following table briefly describes each Pulsar filter and the answer metadata field(s) referenced by each to inform their decisions.
| Filter name | Description | Related 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 RUM-based traffic steering, availability is measured by a moving average of successful connections to the endpoint (for example, CDN) over the last five minutes. This filter arranges answers from the most available (that is, a higher percentage of successful connections) to the least available (that is, 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 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 Pulsar (RUM-based) traffic steering filters to learn more about each filter.
After configuring your RUM applications and jobs, you connect each job to the corresponding DNS answer(s) through the answer metadata within the Pulsar data section.
After selecting the job from the drop-down menu, you are given the option to define an availability threshold and define any biasing to apply to this answer’s RUM 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 are 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 Performance filters use the adjusted value instead of the real value to determine the best-performing endpoint.
For example, if you would like NS1 Connect 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 performance (latency) data for this endpoint. It does not impact availability measurements.
Decisions over HTTP
The decision service allows interaction with RUM-based traffic steering 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 RUM-based traffic steering 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.
Route maps
By default, the RUM-based decision engine 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.
Alerts for RUM usage
To make sure that you stay informed about the amount of resources that you use over your billing period, you can create alerts to notify you when your usage reaches a certain percentage of your plan limit.
The number of Pulsar decisions available to you depends on your plan. You can view your plan type and usage limits on the Usage page.