This article originally appeared in the July 2011 issue of infoTECH Spotlight.
You see it all the time in New York, San Francisco and other parts of the world. Someone standing on a sidewalk staring at his smart phone…and staring…and staring. Maybe they are watching a video. But more likely they are waiting for a page to load. And usually they look annoyed, which is understandable. For pages loading over a fast WiFi (News - Alert) or home broadband connection the process averages 2 seconds or less. Supposedly fast wireless networks average page load times of 8 to 10 seconds. In places where high usage of data services congregates, like the big cities, those page loads can stretch to 20 seconds more. No, it’s not only about the bandwidth or the backhaul, or overloaded towers either.
Rather, a major cause which is almost never discussed for these waits is the disparity in the round-trip-times (RTT) experienced by users on wireless versus wired broadband networks. In short, the RTT from the mobile device to the mobile gateway and back is inevitably greater than the last mile RTT from the end user back and forth over cable, fiber or DSL broadband connections at home or at work. That’s despite the best efforts of legacy Content Delivery Networks (CDNs) to speed up delivery times and cut latency, both of which will boost user engagement. It’s important to note, too, that very small changes to the data footprint of mobile Websites can result in large reductions in content latency. So let’s examine this question at three different levels and discuss why mobile content delivery is so much slower and what can be done to fix that problem.
At the network level, the HTTP request-response protocol is a significant cause of slow RTTs. HTTP is decades old but still dominates data traffic. Unfortunately, many of HTTPs characteristics lead to increased latency. For example, HTTP allows processing of only one request per connection, this means that it takes a minimum of an RTT to complete a single request, and prevents the browser from using that connection to send additional requests until the response is fully received. On high latency connections, like mobile, these results in low utilization of the connection, where most of the time is spent waiting on one of the sides. Browsers circumvent this issue by launching as many as 6 separate connections per hostname. But this solution is not a panacea as it adds complexity and processing overhead on both the end device and the origin server.
On wired broadband networks, where the RTT is typically brief (10ms-50ms) and connections are consistently fast and network conditions are reliable due to fixed nature of these networks, this additional overhead for delivering each object is barely noticeable. But on 3G and other mobile data networks, where the RTT from a mobile device to the mobile gateway alone is typically 120ms - 200ms, the dozens of requests for objects for a page cause compounding latency that can easily add up to seconds spent waiting on a spinning icon on the screen. Naturally, this leads to user abandonment of content and links.
TCP, too, compounds the problem as its efficiency and throughput is dramatically impacted by variable and inconsistent RTTs on the link. This ensures that those connections and the data requests behind them slow down even more. This explains why a mobile page load could lag for 15 seconds, but when the user reloads the page after hitting the back button the page loads far faster on the second try. The slow TCP connection was broken and a faster one replaced it. Needless to say, this is not an efficient way to accelerate page load speeds. The upshot of all this? Network bandwidth matters far less than the underlying protocols for data delivery. So even when the network is not busy and the mobile device obtains a speedy 8Mbps link, loading the same page on mobile device will require far more time than loading that page on a broadband connection.
One approach to address the HTTP problem is called “pipelining”, and in fact is part of HTTP/1.1. This enables the client to send additional requests on a connection before receiving the entire response back from the server. Pipelining actually enables better utilization of the link by eliminating some unneeded round trips. However, this approach has a few problems. Most browsers don’t support pipelining. Some servers and network proxies don’t support it, either. Further, HTTP pipelining cannot handle the sequencing of requests and responses. So for a page to load properly the responses must be sent in the exact same order as the requests. In that case, an object which is slow to serve will slow the entire connection, blocking further requests.
Google (News - Alert) is currently championing a newer protocol called SPDY that is fully multiplexed, allows for servers to initiate a request (“push”), permits header compression, and other latency reduction techniques presently missing in HTTP. Google has made SPDY an open standard and released their implementation as open-source code. They have also engineered SPDY into the Chrome browser and will likely include it in a future build of the Android (News - Alert) operating system used by tens of millions of mobile devices. However, greater client-side adoption of SPDY (by handset makers and mobile software developers) will take some time.
With regard to the problem of TCP-induced latency, CDN operators are creating special algorithms to optimize TCP delivery based on specific network conditions. This will make TCP requests “smarter” and less likely to create a downward spiral of latency resulting from a slow request continuing to languish in the back of the TCP priority queue. CDNs are also figuring out new ways to reduce the time it takes for each TCP request to be processed, thereby minimizing the impacts of compounding latency.
At the business logic level, the nature of mobile behavior comes into play. Mobile interactions tend to focus on highly personal activities such as communication, use of social networks, and local services (or location based services). These may include activities such as checking the weather, traffic data, or looking at movie times around you. Caching this type of information on a CDN is particularly difficult because it is personalized to a user or geographically fragmented into very small increments (Think how many movie theaters are there in a large city and you get the idea). Users requesting this data often experience painfully slow loading pages caused by round trips all the way back to the origin server.
Some of the newer CDN technologies can address the logic level in a number of innovative ways. First, they can more intelligently cache information close to end users with mobile devices, and use the location as a cache-key. So, for example, a weather site can, with this type of logic, cache appropriate detailed weather information for a user in the CDN based on their initial GPS contact point. This weather data can be later served to other users located a few blocks away, eliminating the need for additional round trips. Alternatively, the CDN can quickly detect the type of device and cache assets in the edge of the network that are required for that type of handset. By pushing logic closer and closer to the end user, CDNs will push the envelope on what can and cannot be cached and stored in the edge of the network. Further, with these capabilities CDNs can expand the number of ways they cache. Whereas legacy CDNs can cache only by URL and filename, newer CDNs with advanced edge logic can cache information based on the device, the location, network conditions, and many other key parameters. This advanced caching will dramatically reduce latency and will speed up content delivery because far fewer of the dozens of different data requests required to load an average Web page will need to travel all the way back to the origin server. Rather, a far higher percentage of those requests will be fulfilled by pulling cached data stored in the edge of the network.
While consumers are waiting for their mobile devices to speed up, carriers and content delivery networks will continue to work on a variety of new technologies to speed up content to mobile devices around the world. Bringing content and logic closer to the user, more intelligent content caching, optimizing TCP delivery for network conditions, shrinking file sizes with compression, and eliminating unneeded round trips on HTTP are all needed to reduce latency and improve end-user experiences on the mobile Internet. The drive to implement and propagate these technology improvements is spurred on by the fast growth of the various types of mobile applications and data usage patterns (dynamic, personal, location-based content applications) that most benefit from these newer mobile content acceleration technologies. As a result of these and many other newer technologies, we hope that soon a person standing on the street staring at their smart phone waiting for a page to load is a far rare occurrence.
Ido Safruti is VP of Product Strategy at Cotendo, where he leads the company's overall product and cloud computing strategy. He has extensive cross-functional experience in networking, security and high performance systems.