Ever since the commercial web went live, we’ve been trying to accelerate performance. There’s been a lot of investment in the sticky problem of speed and reliability, from optimizing the front end to caching and load balancing at the back end. As far as the web goes, the user experience from tethered or Wi-Fi-connected laptops is pretty good, though “your mileage will vary” is still the operative phrase. That’s not at all the case when it comes to mobile networks.
Mobile networks and mobile apps are an entirely different world when it comes to sending and receiving data. Because cellular and Wi-Fi networks rely on radio transmission, they have inherent challenges that technology originally designed for web data networking -- technology such as CDNs and DNS -- never anticipated.
It's well known that CDNs depend on DNS to map HTTP requests to the supposed nearest replica of the content. They have done so since the 1990s when Netscape was the dominant browser and few people were using Wi-Fi, let alone mobile networks to access the web.
As a brief reminder, the method CDNs use to accelerate content is as follows:
- The original content provider, say the New York Times, hands over control of its DNS service for some of its domains to a CDN.
- When an NYT customer initiates a connection request to a domain controlled by NYT (say, image.nyt.com), the DNS request is ultimately routed to the CDN’s DNS servers for resolution into an IP address.
- The CDN takes advantage of this opportunity to inspect the source IP of the incoming request, and based on internal knowledge of IP-to-location mapping, the CDN crafts a DNS response to direct the requester to the replica server of the content that is closest to the user instead of the origin server that NYT owns. This is referred to as IP(A) in the image below.
This DNS-based mapping is a universal technique used by all CDNs, including established players like Akamai and Limelight, as well as startups like Instart Logic and Twin Prime. On the surface, this technique makes a lot of sense, cleverly incorporating intermediate steps in the user's journey to direct them to the closest replica of the content they’re interested in.
The question for mobile publishers and developers: Can this work for mobile apps?
The DNS-CDN problem
DNS is not designed like traditional client-server. Rather it is built as a hierarchical, distributed, autonomous, and reliable database service. In simpler terms, there is no guarantee that the source IP seen by a CDN’s DNS is anywhere near the actual user. Quoting from an article, “What DNS Is Not”:
[I]t has never been wise to assume that a DNS request’s IP source address gives any hint of an end-system Web browser’s network location. This is because DNS requests heard by a CDN come from recursive DNS servers as a result of cache misses; they do not come from end systems themselves. Some ISPs regionalize their recursive nameservers, allowing CDNs to encode rules improving the quality of their estimates. [However] many recursive name servers are per-country or per-continent or even per-hemisphere…
Typically, there is at least one intermediary between the user and the CDN’s DNS node: the ISP-provided DNS server. In the case of mobile devices, this ISP is usually the carrier that the user bought the phone service from (Verizon, AT&T, Airtel, Orange, and so on). The mobile network provider as intermediary configures its DNS service with very different goals in mind, namely to be cost-effective for an entire region and to serve as a backup to handle outages in one location. This doesn’t conform to what is optimal for a CDN, which is localization: to get as close to the user as possible. Understandably, the mobile operator’s main incentive is to optimize its own costs and consolidate its operations in a few datacenters. The result is shown in the diagram below:
A very significant percentage of mobile user requests end up at a replica located far from the user, denoted by IP(B) in the diagram above, with very high latency and consequently a poor user experience.
Unfortunately for mobile app users, anecdotal accounts suggest that somewhere around 10 percent of all requests from mobile devices headed to large, multinational CDNs end up on nonoptimal replicas, far from the user.
CDNs are perfectly aware of this problem and trying out solutions such as user remapping and Extended DNS. But these are band-aid solutions to the main problem of how mobile networks work. For example, Akamai states:
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 lookup 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.
Another effort to fix CDNs for mobile involves Extended DNS or EDNS. As espoused by other CDN companies, EDNS expands the total packet size to preserve the original location of the user. (The original design of DNS restricts the total packet size to 512 bytes.) This approach requires a nontrivial, widespread industry adoption.
The proposed solutions from CDNs impose an extra DNS lookup and an HTTP redirect or require adoption of EDNS across the industry. Meanwhile, the mobile user is not only paying in terms of time and annoyance for each extra round-trip, but spending money out of pocket for every byte of extra data consumed.
The PacketZoom solution
The majority of internet usage is shifting to mobile devices, and 90 percent of the time spent on mobile is in native apps, not the browser. As I’ve shown, DNS-based replica discovery systems, based on legacy, Netscape-era technologies, can’t accelerate performance over cellular and Wi-Fi networks. This has significant consequences for mobile publishers and developers in the form of frustrated customers and abandoned apps.
At PacketZoom, we've rethought the entire mobile networking stack from the ground up. This includes rethinking the use of DNS for the purposes of accelerating content discovery and delivery. Mobile devices have enough information on board, so there's no need to rely on 1990s techniques to do location-aware service discovery using slow, insecure, and unreliable services like DNS, especially for a purpose it was never designed for.
PacketZoom is designed to serve the content acceleration and reliability needs of mobile apps. We use a worldwide cluster of load-balanced, fault-tolerant servers to discover the closest and fastest available content server. This process takes only a single round-trip to the network and is authenticated using the identity of the application publisher (our customer). What’s more, PacketZoom is free to ping multiple content servers in parallel. Our mobile-specific techniques not only render PacketZoom service immune to the problem of wrong replica selection, they add a level of fault tolerance and robustness that legacy CDNs can only dream of.
Chetan Ahuja Chetan is CTO at PacketZoom. Prior to co-founding PacketZoom, he was involved with developing technology at several companies, including Google, IBM, and Riverbed Technology. Chetan holds computer science degrees from the Indian Institute of Technology and Michigan State University.
New Tech Forum provides a venue to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to newtechforum@infoworld.com.