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.
ECS forwards the client subnet to the CDN, but does accurate mean fastest?
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.
Fastest delivery speeds come from the best path, not always the closest server
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.