The name resolution process started simple: the Domain Name System (DNS) was solely used to hide IP addresses by making human readable bookmarks assigned to participating entities. The distributed database contains an address book of name to IP mappings. Any advanced network functionality, such as failover and load balancing, was performed outside the realm of DNS. At that time, the resolution process worked and scaled very well to support the Internet at a global scale.
Over time, user requirements changed and network complexities began to surface. Roaming users and dispersed content in multi geographic areas drove a different type of DNS than what we initially started with. The need to serve content from a variety of endpoints with greater speed and accuracy came to the forefront. NS1’s DNS service addresses this shortcoming by including monitoring and geolocation based routing, allowing the DNS layer to intelligently send users to both the healthiest and closest content endpoint.
For some time, these metrics were sufficient for most requirements. However, the closest style routing metric had drawbacks and in some scenarios completely falls apart. Geotargeting doesn't help with multi Content Delivery Networks (CDN) environments as each CDN may have multiple endpoints hidden behind a single front-end. Essentially, we were stuck with traditional round robin load balancing algorithm or an executive decision to move to an advanced traffic management solution. Round robin is one of the first load balancing algorithms and potentially primitive for the dynamic nature of the Internet. It doesn't absorb performance related telemetry and make endpoint selection decisions based on eyeball criteria.
Advanced traffic management solutions like NS1’s Pulsar take endpoint selection and performance monitoring to the next level. It intelligently measures on what the end user really sees, leveraging Real User Monitoring (RUM) data to dynamically tailor the content ecosystem providing the best possible experience to end users. Pulsar is tightly coupled to NS1 existing DNS Filter Chain solution. Both are used conjunctively, offering ultimate endpoint selection. Endpoints are not confined to specific nodes or networks and may consist of Data Centers, CDN’s, individual physical / virtual servers, microservice containers, and load balancers.
The following post begins with an overview of NS1 Pulsar traffic management solution. It then goes under the hood of Pulsar, highlighting key components and inner workings. It finishes with a real life example of how an Internet streaming company improves end user experience by employing Pulsar’s multi-metric design.
Pulsar: A Practical Example
Let's roll back and view Pulsar to the analogy of going for a coffee and selecting the best out of three favorite coffee shops. Imagine you are using NS1’s Filter Chain solution, but with the added granularity of Pulsar. The following steps display an example filter chain list selection designed to influence endpoint selection:
The first filter is the UP filter eliminating any closed coffee shops.
The second filter is the GEOTARGET filter sorting coffee shops by physical proximity. The coffee shop physically located closest is at the top of the list while the furthest is at the bottom. Now, we have a list of coffee shops based on physical proximity, similar to the methodology of routing user requests to the closest CDN.
Physical proximity is not always the “best” fit so we need to dig deeper inside the coffee shops to determine how busy they are. Maybe there is water spillage reducing the queue to one lane, a machine breakdown, and sick or lazy workers. Knowing that a particular coffee shop is closest to you does not provide this kind of detailed information.
The third filter is the advanced tailored metrics defined by the Pulsar filter. It takes the list from the GEOTARGET filter and reorders the priority based on real time conditions that may affect the speed of getting a cup of coffee. Once the list is analyzed by Pulsar, the best coffee shop is selected and moved to the top of the list. The final list enhanced by Pulsar’s inputs is orders of magnitude better than the initial GEOTARGET list.
Next, we delve deeper inside the coffee shop and determine any congestion related factors by introducing the Pulsar SHED_LOAD filter. This filter de-prioritizes busy coffee shops due to excessive queues or overburdened baristas. This type of detailed analysis presents an accurate picture of what the real “best” coffee shop is, currently not available with the GEOTARGET filter.
Finally, we have the SELECT_FIRST_N filter. This filter eliminates all answers except the first one. Now, Pulsar presents the best possible answer based on multi-metric design properties of proximity, route speed, and load within each coffee shop.
The ability of Pulsar to gather telemetry information for defined endpoints over a period of time creates a model specific to customer application requirements. It allows the definition of metrics that are important and the selection of the best possible endpoint based on those metrics. Approximations are no longer needed, Pulsar creates a tailored performance map for each endpoint. Pulsar is not a pick and leave solution, it continuously monitors and changes endpoint selection based on customer defined thresholds.
Pulsar Base Architecture
Now that we have a general idea of what benefits Pulsar can offer your business, let's take a look under the hood.
NS1 operates a 24 PoP Anycast and Core network infrastructure. PoP selection is intelligently based on user locations and the majority have multiple Tier 1 and Tier 2 provider connections. The core network leverages a highly available, redundant design.
Anycast architectures enable multiple PoPs to respond to a single IP address. Services get advertised externally with one IP address from multiple geographically dispersed locations. Anycast designs bring many benefits to PoP selection and network high availability. Users requests always get routed to the nearest PoP unlike an unicast approach that may lead to suboptimal PoP selection. It also acts as a DDoS reflection mechanism. Anycast networks are flat and efficient meaning they naturally absorb all types of Layer 4 and Layer 7 DDoS attacks keeping NS1 Pulsar up and running through unpredictable times.
NS1's solution is written from the ground up and is not based on BIND or powerDNS. While the majority of the Internet runs on BIND or PowerDNS, NS1 developed a proprietary name server software. As the protocol is 33 years old, in order to make new and interesting things work with the DNS, a flexible piece of software had to be written to provide the unique and fast-propagating service that is available today. This brings really fast response and rapid change notification times from the nearest PoP. DNS queries arriving at each PoP are reported immediately. When a customer makes a change it is served live in under 2 seconds. NS1 propagation times are breathtaking. Additionally, for enhanced security the distribution of data is over encrypted channels.
Pulsar - Under The Hood
Pulsar has two main components - A Data Ingest and Intelligent Filter Chain layer. The data ingest is a RESTful API that speaks JSON and sends API calls to Pulsar. Pulsar requires an IP address, either from a web site or mobile phone, Job ID to identity endpoints, and a Floating Point Metric. The Floating Point Metric (FPM) is a key differentiator between Pulsar and legacy traffic management systems. The FPM enables NS1 customers to take a number of telemetry metrics and combine them into a single number, known as the scoring card number. Pulsar’s measurements are based on many metrics, while most traditional traffic management systems are simpler and tied to only one.
The power of NS1 lies in the fact that each measurement is a simple API call to the Pulsar backend. Customers are not bound to any specific type of measurement and have tailored scope to measure exactly what they want; creating a customised performance map. We also have the opportunity to measure on multiple parameters influencing the final performance score. This type of flexibility propels endpoint selection to enter a different world of traffic management and multi-metric performance scoring.
End users take measurements and report to Pulsar systems with an API call. Subsequent DNS request are used to route user connections to the fastest endpoint. Pulsar continually monitors and reports the best endpoint based on tailored criteria meaning Pulsar routing is monitored and enabled on a per record basis.
A lightweight JavaScript can be embedded in the content of pages. On page loads the Javascript executes asynchronously in the background gathering performance data. Page views start the performance gathering phase, as it works asynchronously nothing gets blocked or impacted. It is an non intrusive performance gathering mechanism. Once data is gathered it gets pushed to Pulsar and new DNS based routing tables are created at the 24 PoP anycast design.
Pulsar has two modes of operation - dedicated or community mode. Dedicated is a private mode used for customer specific measurements. Community mode collects data based on generic non customer specific application performance metrics such as RTT. Anyone is the NS1 community can access the pool and draw from it. The community data is only accessible through the use of Pulsar. It's a dataset that is used to ascertain endpoint performance when custom tags are not installed on an endpoint.
Pulsar enables you to measure and ingest custom data on specific event performance criterias, quality of service measurements and end user environment detection. Specific event performance for example may include a Layer 7 three way handshake to monitor application performance. Quality of service measurements such as packet loss, retry count, or audio stream jitter. It also offers end user environment detection by detecting conditions other than link quality or performance criteria. For example, you have two interesting endpoints, one serving desktop optimized content and the other servicing mobile optimized content. The Javascript can detect the resolution of the display and handheld orientation ( tablet, mobile phone ).
Pulsar: Case Study
The following case study involves a World Music Broadcast company offering radio broadcasting and DJ news. Their service includes streaming live DJ sessions from a single location to a user base scattered throughout the world. The creation of live streams involves a number of actions and steps:
Firstly, the upload of a large audio stream from unpredictable locations. Due to the largely unknown global users base they employ a multi CDN strategy to distribute the streams.
Before the encoders encode the live stream, they communicate with Pulsar and beam information about latency changes to World Music Broadcasts multiple data centers.
Pulsar digests the information and informs back to the encoder the lowest latency data center for that particular stream.
The end user subscribing to the stream has a local application informing Pulsar of a number of performance metrics, including latency to World Music’s various origins and the speed of the multiple CDNs.
Streaming live content to a global user base is challenging. User expectations are high especially when content is live. Every second counts and excessive buffering is not acceptable. Pulsars ability to digest performance metrics from various encoders and user locations gives World Music Broadcast users the best possible experience viewing live streams.
Summary
Pulsar is a practical solution that intelligently selects endpoints based on what matters to you. A group of metrics are defined creating a custom application map that exactly fits performance requirements. The Internet as we know it has varied performance characteristics meaning endpoint selection based on traditional methods is no longer on par with customer expectations. More information about Pulsar, or any of NS1’s innovative Application Delivery Management technology can be had by getting in touch with us.
This is a guest article posted by Matt Conran, Network Architect at Network Insight.
If you're interested in guest blogging for NS1, contact us with your idea!