Akamai Diversity
Home > Cloud Computing > Intelligent User Mapping in the Cloud

Intelligent User Mapping in the Cloud

A DNS-based, load-balancer solution allows companies to distribute application load between global datacenters or cloud providers. This solution, when combined with a Content Delivery Network (CDN), provides benefits such as improved load distribution, faster load times, and high content availability.  These benefits result from the user requests being directed to the optimal (often nearby) server. Latency and packet-loss are therefore minimized due to a shorter physical distance traveled.

When the client DNS resolver queries the IP address of a hostname, it recursively queries the CDN's DNS servers for the answer. The CDN's DNS server examines the IP address of the client name server, and returns the server that is optimal for that name server.

$ host www.example.com
www.example.com.    3353    IN    CNAME    www.example.com.edgesuite.net.
www.example.com.edgesuite.net. 530 IN    CNAME    a123.gi3.akamai.net.
a123.gi3.akamai.net.    20    IN    A
a123.gi3.akamai.net.    20    IN    A

In the above example, the last two DNS queries are performed by the CDN's DNS. Ideally, the CDN name server would map users based on the end-user's IP address, rather than by the IP address of the client name server. However, the client IP is not visible to a CDN's DNS server as limited by query structure. (RFC 1035). The choice of the local name server and its geographic proximity relative to the client become a critical factor in the quality of service a CDN provides.
In most situations an end user's machine is configured to use a close-by name server, which results in the connectivity of the local name server being a good representation of the connectivity of the end-user's machine. However, there are a number of circumstances where an end-user's machine is not configured to use a local name server that is representative of their connectivity. Some of these examples include:

-    The usage of open resolvers like OpenDNS, where clients with a wide geographic distribution may be using a fairly distant name server.
-    A local ISP uses an Anycast(http://en.wikipedia.org/wiki/Anycast) network of DNS servers

A more detailed example illustrated below: a user is located in Taiwan and uses a OpenDNS name server in the United States. The CDN would think the user is in the US, and would serve content from the US servers.  This would severely degrade throughput performance, and defeats the benefits of geo load balancing and CDN.

blog 2.png

One solution to address the above issue is for the Edge servers to perform request re-mapping, based on the client IP, when the initial server connection is determined to be non-optimal.

When the Edge server receives a request for an object, it first evaluates the round-trip delay time(http://en.wikipedia.org/wiki/Round-trip_delay_time )(RTT) of the TCP SYN-ACK. If the RTT value is low (good), the edge server starts serving the object immediately. If the RTT is above a pre-defined threshold (bad), the Edge server makes a special request to the DNS server, which looks up the client IP and returns a CNAME to the Edge servers that are close to the client IP. The Edge server constructs a fully qualified redirect URL to send to the client. The client will then chase the redirect by resending the request to the newly assigned server.

We conducted a production test to assess the effectiveness of this solution. The feature was enabled randomly on 50% of requests for a high volume, high bit-rate video streaming service.  The test ran for 8 days and performance data was aggregated daily to calculate the average mapping distance (between the client and Edge servers) and the average RTT for requests that triggered remapping.

blog 3.png

blog 4.png

As the results show, both RTT and mapping distances improved significantly for remapped requests. The average RTT is reduced by 44% and the average mapping distance is reduced by 56%. An analysis of the user sessions revealed that those sessions which utilized the end-user mapping feature, had a higher percentage (84%) of good sessions (connections maintain above 5mbps throughput) than the sessions without this feature (78%).

It is important to note that end-user mapping is not designed as a replacement for DNS-based mapping. It should also not be used as a generic solution as the extra server side DNS look up and eventual client redirect add overhead. For example, end-user mapping is not a good fit with site delivery as site delivery consists of small objects and the redirect URLs would be exposed in the web browser.

Our analysis shows that high bandwidth large downloads such as video streaming would stand to benefit most from end-user mapping, as decreasing latency to a server directly improves the available bandwidth. Additionally, the long playtime of streaming video means that an initial, extra lookup to obtain an improved server map adds minimal overhead.
With the ever-increasing consumption of rich contents, intelligent server mapping plays an essential role to ensure a consistent and positive user experience.  

Eugene Zhang is a Senior Enterprise Architect with Akamai's Professional Services organization and an expert on web performance optimization


It's interesting to see this approach and the associated figures but I'm wondering why there is no mention of the "Client subnet in DNS requests" IETF draft (http://tools.ietf.org/html/draft-vandergaast-edns-client-subnet-01).

It seems to be the optimal solution to this problem for those resolvers that support the feature (OpenDNS and Google Public DNS already do). For those that don't pairing it with the solution proposed in this article would be a good compromise.

Thanks for the feedback, Steve. As the adoption for EDNS0 client-subet grows among ISPs, public DNS, and CDNs, it will be an
effecive and transparent mechanism to address the distance mapping issue.

Thanks for the feedback, Steve. As the adoption for EDNS0 client-subet grows among ISPs, public DNS, and CDNs, it will be an
effecive and transparent mechanism to address the distance mapping issue.

Like what you said in this article, client re-mapping adds overhead. Perhaps it's time Akamai adopts edns-client-subnet EDNS0 option or explores Anycast like CloudFlare.

Leave a comment