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).
CDNs systematically make wrong assumptions about the location of the user
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!
The network holds the information CDNs need, BENOCS digs it up and voilà!
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.