In the previous episodes, we took you on an “internet road trip” to help explicate some of the issues concerning content delivery across the network. However, the network does not work with such efficiency and simplicity as we have previously alluded. In fact, our previous metaphors are still missing some important features that are used in this process. As an attempt to complete the full picture, let us return to our pizza hotline, but this time include the Extended DNS Client Sub-net (ECS). For the explanation of DNS indirection, we imagined that the pizza hotline had to guess where you were, based on the information they had: you are in a hotel. Well this time, let’s say you provided an address, or for the sake of the internet, we implement the ECS. With an address, the hotline operator could look up your location and pizza store proximity on a map in order to choose which store is closer and, theoretically, ensure the fastest delivery time.

Today, when an internet user requests content, the information begins by going directly to the DNS. Here, the CDN selects a well-located server based on the DNS-R location, and then proceeds further to the user. This, of course, is in the simplest terms. The IP address (user’s location), however, does not leave the network, thus creating a guessing game for the CDN to decide which server is the closest to the user. Although, if the ECS is activated, then the IP address is forwarded to the CDN as well, thus giving it the knowledge it needs to make a more accurate delivery. But does accurate mean fastest?

Now imagine that we are back on our road trip. You, the hungry customer just ending a long day of driving, arrive at your hotel. You call the number for a pizza hotline, place your order and provide your address. The pizza hotline forwards the order to the pizza store closest to your hotel and tells you that your order will be at your door in 30 minutes. Perfect! In the meantime, you fall asleep on the bed. When you finally awaken, you check the clock. An hour has passed. Anxious with the thought that you somehow missed the sound of someone knocking on the door, you call the front desk of the hotel and ask if the delivery driver left the pizza there. They assure you that no delivery driver has come through the hotel doors. You then call the hotline, who contacts the driver, and then tells you the bad news. Your pizza is stuck in traffic and will take another 30 minutes. Apparently, there was a terrible accident on the road between the shop and your hotel, which caused the road to temporarily close. Had the hotline known this, they could have forwarded your order to the next closest shop, which would have made your wait time 50 minutes instead of the now predicted 90. If only the hotline had a device that provided up to date road conditions to ensure the order was sent to the pizza store that would reach the customer the fastest.

Just like our scenario, by merely applying the ECS on the internet highway does not guarantee the fastest results. Sometimes the closest server has the heaviest traffic, and there is no traffic report to warn the CDN. At BENOCS, our products do just that. By looking into the network vision gaps – as discussed in episode 1 – we create a traffic report by using the information naturally stored within the ISP. Therefore, we are the ones that can give the CDN the most accurate map when choosing the fastest path to the user. Stop making your customers wait and start choosing the store with the fastest delivery time!

Tune in next time where we will explain what information we leverage from the network and how this helps CDNs achieve their different delivery objectives.

After a long and stressful day of driving (almost stranded in the middle of nowhere without gas), you finally arrive to your destination tired and hungry. While scouring through the local phone book located in your hotel room’s desk drawer, you stumble upon an advertisement for a pizza delivery chain with three locations nearby. You decided to call their call center and order the largest pizza available. After placing the order, the person asks, as expected, your location. You provide them with the address of your hotel. With this information, the call center is then able to forward your order to the pizza store closest to you, ensuring that you will receive your pizza in the shortest amount of time and still hot on arrival. How is the pizza hotline able to provide such seemingly effortless service to prevent you from collapsing of hunger? It’s easy. With your address, they are able to look up your exact location.

In this case, the best Quality of Experience (QoE) comes from the pizza hotline being well equipped with the information of your exact location. However, if we imagine that, instead of telling them your address, you only told them that you are in a hotel, how would it look in a town with more than one hotel? Perhaps the hotline would use a similar method to the one currently being used by the content delivery networks (CDN).

Along the content delivery path today, CDNs often rely on the domain name system resolver (DNS-R) address as a representation of the user in order to connect the content to the user. Since the CDN does not know the user’s actual address, it uses the location it does know: the DNS-R from where the request came. From there it chooses the content server closest to that location.  As outside observers, we would assume that the user and the DNS-R are not that far apart. However, we as observers are wrong. Instead, when a user wants to view content, the network decides which DNS-R the user should use, which in most cases, changes to equally distribute the traffic across the DNS system. Thus, the network rotates the user’s requests between all of them: one of which is closest to you, one in the middle and one very far away. The CDN that is carrying the requests then assumes the location of the DNS-R is the same as the user, and will distribute the content back to the location of the DNS-R – this would mean two out of three cases in our scenario are wrong! This is known as DNS Indirection: when the CDN uses either of the two servers furthest from the user because it does not know the real location. If we were to implement DNS Indirection into our pizza scenario, we would imagine that you only told the operator that you were in a hotel, unaware that there are two other hotels in the town. The operator would then have to guess which hotel you were in and which pizza location is closest to it. As a result, the operator would send your order to pizza store B, if the last person’s order was sent to pizza store A. That means two out of every three times a customer orders a pizza, it will be delivered from a shop further away than necessary, and hungry customers don’t like to wait!

Now, let’s put the address back into the pizza hotline scenario. When you tell the hotline your order, they can easily figure out where you are, and where to send the order so that you have the shortest possible wait time. At BENOCS, our products do just that. We discovered how to communicate the address to the network and CDN, and have created a context-enriched model as well as the mechanism that can distribute it to the CDN. Therefore, we are the one that the CDN can contact in order to see which server is the closest to the user.  Therefore, only the closest server receives the requests to ensure the fastest delivery possible. Stop serving your customers cold pizza, and get your map today!

For more information on DNS indirection at Google, check out Leonidas Kontothanassis’s talk starting at 37:00 minutes.

Tune in next time where we will explain Extended DNS Client Sub-net, which, when activated, sends the client’s IP address from the network to the CDN.

Imagine that you are on a road trip almost exactly half way to your destination. You are at that part where it is simply you, the road, and the beautiful landscape that seems to go on for forever. This should be a relaxing and enjoyable drive, but instead you become frantic having just learned your car is about to run out of gas. With only a few minutes left until you are  stranded in the middle of nowhere, unfamiliar with your surroundings, you come to a fork in the road with three possible paths. Each path has a sign for a gas station, however, the distance and potential road obstacles are unclear considering each road leads directly into a luscious forest. Therefore, your ability to see past the entrances is almost impossible. Running out of time, you have to decide which road will get you to a gas station the fastest using an old submarine sonar that your grandfather gave you from his days in the navy. Of course, using a sonar could only give you an idea of which gas station is the closest but cannot tell you of any potential obstacles, such as traffic, road damage, or even the gas station with the least amount of customers, which can delay receiving gasoline. If you think the solution in this scenario for finding a gas station sounds ridiculous, you are not alone, however, this is  similar to what is currently happening across the internet as content is being delivered to the user.

Like our scenario above, the delivery of content (the gasoline) between a requester (you) and many available content sources (the gas stations) over the network can be a difficult and disorganized journey due to vision gaps (the forest). These vision gaps prevent the content from choosing the best possible path, thus causing a longer travel time and a slower internet service for the user. Of course, if you could only see past these vision gaps, then you could figure out which path will get you to your destination the fastest. Unfortunately, the market today provides inefficient and outdated technology for making these measurements. That leads us to the role of grandpa’s old sonar.  Currently, many content delivery networks rely on a network-measuring tool known as a ping. Like a sonar, the ping operates by sending an echo request to a content host in order to measure the distance between them based on how long it takes the request to come back. The response will ultimately make a ping when it has returned, hence the name. The ping measurement, however, has been the measurement of choice since the 1980s and is now unfit for the already large and continuously growing network. Not only do the circumstances of the paths change within milliseconds causing the ping’s information to already be outdated when it returns, but studies show it is hard to determine how accurate the ping measurement actually is. Just like how you wouldn’t find grandpa’s sonar to be the best tool when looking for the fastest path to the gas station, the ping is not the best tool to measure network traffic.

Now imagine that, instead of using your grandfather’s sonar, you had a GPS system tracked by satellite. Your device could not only show you which gas station is the closest, but also advise you on which path has the least obstacles and the shortest wait time, therefore getting your car fueled as fast as possible. At BENOCS, our products do just that. We explore the vision gaps using information already provided by traffic generators and operators (the satellite) within the network in order to show the content delivery network the best possible path to the server, thus providing customers with the best possible quality of experience. So get rid of that old sonar and start seeing past the vision gaps!

Tune in next time where we will explain what information inside the network BENOCS gleans as to equip our “GPS for the internet” with the right map material.

In just a few years’ time, the Internet has changed significantly. Starting as a hierarchical Tier-1, Tier-2 and Tier-3 topology, it is evolving more and more towards a mashup of directly interconnected networks, thus increasing its complexity both physically and logically. Driven by higher quality demands and lower transit network cost, content providers have been working on increasing the content to user speed by shortening the path, which positions the content as close to the consumer as possible. Content delivery networks (CDNs) started to develop enhanced algorithms to choose the “best” – or at least a better path – to the user in order to make the connection faster.

Every participant of the internet supply chain, which goes from the content, to the CDN, to the upstream provider, to the transit provider, to the ISP, to the end user and vice versa, has an influence on quality, reachability, and security of content. To ensure quality and detect risks, the ISPs monitor and record different sources of data by utilizing various tools.

We at BENOCS seek to leverage these information sources in a completely new way based on the principles of completeness, transparency, and simplicity. We have developed the BENOCS collector, a multi-dimensional collector that stores all the different sources in a single place and, with our analytics, correlates them to gain new and deeper insights of one’s network.

Using analytics to understand what is happening in a network is not a new concept. The current tools on the market are used for specific questions pertaining to the current state of the internet; some of them are often misappropriated to gain “deeper” insights in a foreign domain (accepting the inherent risks of the constraints and misleading assumptions). However, in the past, two major problems prevailed: the first was the amount of data and different systems, and the second refers to processing and correlation. The BENOCS collector solves the first problem by gathering information of the different kinds of protocols (e.g. IS-IS, OSPF, SNMP, BGP, DNS, NetFlow, ect.) in real-time. The second issue is resolved by BENOCS Analytics, which are driven by real-world cases of departments of network operators, quality assurance, planning & forecasting, and sales & support. In fact, we believe the effectiveness of analytics will be so rapid and dramatic that many network professionals will wonder how they functioned without these capabilities.

Being able to answer the following questions in real-time will be the USP of next generation ISPs:

“Are subscribers having trouble with video services like YouTube, Netflix or Amazon? Which users in what locations are affected? Is it caused by an internal or external network? What could be done to solve it?”

Using the power of network analytics and developing a sophisticated intelligence are mandatory to deal with the above more-variables-than-equations types of problems. Thus, analytics will generate revenue and thus pay for itself – both from the cost savings and the increasing quality stand points.

In times of rapidly increasing internet traffic, it is becoming important for internet service providers (ISP) to seek more visibility and control over how and where content is entering its network, and how this can affect the user’s quality of experience. Content delivery is still a blind flight, but how can you equip for the future when you do not know your demand as well as how it affects your network assets? Instead of facing rising infrastructure costs, let us help you get over the “best effort” principle and make content delivery and Quality of Experience (QoE) for your end users great.

Most of the players offering Traffic Management and Analytics tools are providing a limited scope of network visibility by only collecting NetFlow or HTTP, and rarely look beyond one’s own nose to use a more complete network data. As a result, they offer a rather narrowly focused (thus limited) view with some sort of selection of pre-defined filters, however, fall short of clear-cut possibilities for addressing a wider array of business-critical questions. Data is often aggregated too early and too intensely, which leads to a short-term “memory” of the collected traffic. Moreover, they usually lack a comprehensive structure, yet use a case specific data structure that can only be brought about by correlating the right data sources in the right way and with the right timing/resolution. Demands on tomorrow’s network monitoring capabilities go beyond the mere counting of traffic flows and detection of “insular” configuration errors. The lack of context-awareness and powerful flow granularity management renders most of today’s solutions as unfit for the job inside large carrier networks and the diversity of business questions.

We at BENOCS believe that only a comprehensive data structure built from a wide array of network-innermost real-time data gives you the opportunity to gain the problem-relevant insight for tomorrow’s carrier business. BENOCS combines the deepest network data sources (IGP, BGP, SNMP, NetFlow, IPFIX, DNS, and more) to produce a real-time network database that provides a dynamically updated and high-resolution map of your core asset. Our “Insight Engine” then allows the highly flexible production of those answers you really need in your department – this may include identification of potential peering customers but stretches way over to network capex projections for the 5+ year planning discussions. BENOCS also offers fine-resolution retrospection on raw NetFlow data – more than twice as long as competing solutions – which allows you to detect historic patterns and apply predictive analytics. With the outstanding time resolution and “finer-than-AS-level” detectability offered by BENOCS Flow Analytics, it becomes possible for you to make real-time decisions based on your actual – and even the expected – traffic to bring the most out of your network at all times.

In order to improve QoE, not only by passively “seeing” your given infrastructure and traffic, but also by directing the traffic in more intelligent ways, BENOCS Flow Director gives you the opportunity to coordinate traffic between your AS and content delivery networks (CDN) – see chart below. With our network monitoring feature and API, we leverage the network information from the AS to offer selectable network parameters (e.g. delay) to CDNs and other content providers. CDNs can then choose the most efficient paths based on your published network parameters and can implement a content delivery strategy together with you to enhance cooperative traffic steering. This enables ISPs to inform partnering CDNs on how to reduce congestion, smoothen the overall flow of traffic and optimize end users’ QoE.

Since its beginning, the Internet as a system of systems has enjoyed unparalleled success as a powerful means of telecommunication. It is blazing fast, its infrastructure reaches even the most remote places on earth, and its design principles have shown to be quite robust. However, the opportunities that lie ahead of us will make greater demands on the Internet than being able to transfer emails or pictures. Already, well-connected societies have gotten used to video on-demand subscriptions, the streaming of major live events, and a ubiquitous IP capability of new devices. We may venture to project some trends:

• More connected things: More and more devices that have IP capabilities will find there ways into supply chains and homes. The current number of ~5bn units will grow four times to ~20bn units by 2020 (Gartner).
• More dynamic communication: The formerly unconnected-now-being-connected will more frequently communicate in real-time, which enables “dramatically faster cycle times” and “highly dynamic processes” (DHL, Cisco). In addition, various trends have pointed out that people are always on the move and need to be constantly in control of their physical devices while not being present at the source (Forbes).
• More traffic – delivered mostly by CDNs: IP traffic will grow at a compound annual growth rate (CAGR) of 23% from 2014 to 2019 (Cisco). An estimated 62% of all internet traffic will cross CDNs by 2019 globally, up from 39% in 2014  (Cisco).  The 50% mark was surpassed in 2013 for internet consumer traffic in the US having been delivered by CDNs (Streamingmedia, Deepfield).

The last point highlights the importance of Content Delivery Networks (CDNs) in transporting content to the end user – in the right quality. The main idea behind this technique is to geographically distribute servers and then place content replicas on subsets of the server infrastructure (step 1: “generate abundance”).  The second important step is then – whenever a user requests content—to select the “best” server to serve the content to the user. “Best” can relate to different parameters – a geographically close server may offer great latency, but can still be heavily utilized. Gathering the right information and making a well-informed decision is a CDN’s important step 2: “select a server”.

No serious web-based business today can do without some sort of CDN technique. This is reflected by the enormous share of global IP traffic crossing CDNs and the strong diversification that has occurred in the CDN space (Network World). Although, what  the discussions around web performance techniques have largely neglected is the role of Internet Service Providers (ISP), who actually supply and manage the physical networks. Who would have thought that IP packets still have to pass the networks of the Verizons, AT&Ts, Telefónicas, British Telecoms, Oranges, Deutsche Telekoms, and China Telecoms (just to name a few) in this world. Every CDN (or any other performance improving technique) inevitably needs to interconnect with an ISP in order to be eventually networked to the end user. Furthermore, it is at this very frontier between the ISP and CDN universes where we actually observe a certain kind of idleness. An idleness, which, of course, breeds … opportunity.

Technical University of Berlin revealed that ~50% of server selections made by CDNs assign a suboptimal server to an end user (see the paper here). That means the network path between server and end user could either have been shorter, less utilized, more reliable, etc. The reason for this mismatch is obvious: CDNs just cannot see in real-time what the conditions at the edge or in the ISP network really are (not to mention what they will be). The two subsystems (CDN | ISP) are shielded from one another by design of current internet protocols. This does not mean that the information for alignment is non-existing. ISPs literally sit on it – the information is currently just not accessible or ready for use. This is a huge unexcavated potential which, if elevated, would significantly improve the quality of delivery and drastically reduce network Opex and Capex. The core idea is created from the observed “darkness” of ISP networks: shed light on network state information and provide it to all content delivery partners in the internet ecosystem, i.e. Raising All Visors!

BENOCS has implemented the idea and is already running its solution in a major European Tier 1 backbone network. Centrally collecting network inventory and performance information in real-time continuously feeds and updates our data engine. Exploiting NetFlow, IS-IS, OSPF, SNMP, DNS, among other protocols, provides the basis for our optimization and network state prediction algorithms. These “network state maps” are offered via standard API in a high frequency manner to CDNs, but are also branched off to internal units for Business Intelligence (BI). The benefits are clear: if a major ISP engages in this symbiotic communication with just its top 5 CDNs (by volume), peak link utilization in the network is sustainably lowered by ~30% (drastically driving down projected Capex figures for planned network capacity), and customer segments with mediocre delay numbers are almost entirely shifted into the sweet regions below 75 milliseconds.

Therefore, tear down the artificial walls for network-aware, smart content delivery: Raising All Visors!