Nobody likes waiting for downloads, and mobile users like it least of all -- a difficult fact of life for the makers of mobile apps. A big part of the problem for the slow loading speeds on mobile devices can be found in the underlying network protocols. TCP and HTTP were designed for a world with fixed connections and fixed IP addresses. As a result, they make certain fundamental assumptions that are simply not true in the mobile world of today.
TCP is not the only one making less than ideal assumptions. As with any general-purpose solution, even recently developed protocols such as HTTP2.0 and QUIC, which focus on the Web as the primary use case, are unable to address some mobile-specific problems, leaving them unsolved. This also means they fail to take advantage of unique opportunities afforded by the new dominant platform: native mobile apps.
That’s why developers at PacketZoom created their protocol-based service, which is designed to greatly speed up native app content downloads. The service, intended specifically for mobile app developers, today supports millions of users. PacketZoom developed a proprietary protocol, called PZP, that overcomes a number of limitations in TCP and HTTP.
For example, PZP is able to identify the device, rather than its IP address, as the endpoint for data packets, allowing it to accommodate the intermittent nature of mobile connections in a fault-tolerant manner. That means downloads continue seamlessly as the device roams from network to network. Further, by monitoring network conditions, reducing round trips to the server, and trimming HTTP overhead, PZP uses the bandwidth available to the user more efficiently.
PacketZoom pairs an SDK with a cloud service for accelerating content delivery to native mobile apps. At the heart of PacketZoom is a mobile app-centric networking protocol, combined with a global network of servers that act as cloud endpoints for the protocol. To use PacketZoom today, an app developer embeds the PacketZoom SDK into his or her application and sets up configuration details on the PacketZoom Web dashboard. This action starts the process of routing selected HTTP traffic from the app through PacketZoom’s worldwide network of cloud servers.
Why are mobile downloads so slow? Here are the major issues I continue to see and some notes about available solutions.
Latency: Round-trip latency on mobile networks is far higher than over a wired network. For example, connecting my phone to Wi-Fi gives me a 15ms ping time to google.com. That compares to anywhere from 50ms to 100ms over AT&T’s LTE network. The problem is that TCP has no understanding of the network environment and must discover the available bandwidth, which involves a slow start and many round trips using incrementally more of what’s available. As an example, a 100KB file that could take five or six round trips over TCP can be fetched in a single round trip (plus some fixed overhead) over the PacketZoom protocol.
There are varied means of addressing this problem, but the PacketZoom protocol utilizes prelearned intelligence about the capacity of a network channel, based on various parameters such as radio type, carrier name, location, and time of day.
Dropped packets: Dropped packets are a common occurrence in mobile networks because of the very nature of the medium. On mobile networks, packets are lost for a myriad of reasons, including solar flares, interference with other signals, or even walking between the wrong buildings. In the presence of even a tiny number of packet drops, TCP throughput drops precipitously, wildly disproportionate to the actual amount of data lost in dropped packets. This is due to the limitations of the TCP protocol. For example, TCP always assumes that a dropped packet means a router along the way is experiencing congestion. There’s no built-in feedback mechanism to allow it to judge the condition of the network apart from simply waiting for an acknowledgement of a packet from the receiving side.
The PacketZoom protocol recovers from dropped packets “gracefully,” with minimal overhead above the amount of data lost in the dropped packets.
Dead zones: Most mobile users move from one type of network to another multiple times during a day. As a result, almost everyone experiences “dead spots” in network coverage while on the move. TCP, the predominant network protocol used today, and HTTP, the most common file transfer protocol used in mobile apps, have simply no mechanism to handle these scenarios. Even worse, in many cases, the application has to wait for a full TCP timeout (which can take tens of seconds depending on OS settings) before the application is made aware of a lost channel. Every broken connection means complete loss of state on both sides of the connection and a restart from scratch. Each and every application has to design and implement its own scheme for recovery from such failures. This, more than anything else, is the cause of the terrible user experience in spotty mobile coverage.
The PacketZoom protocol was designed to deal with spotty mobile coverage. When a mobile application starts a session with a PacketZoom server, the identity of this session is a locally generated session identifier, not the (temporary) IP address of the device. The current IP address of the device simply acts as the current mailing address for packets from the server. In case of breaks in coverage due to routine causes, such as network type changes (say, Wi-Fi to LTE or 4G to 3G) and dead spots, the session continues across the IP address change with no perceptible delays. This allows for a seamless experience for the end user.
Identity and authentication issues: Web browsers use HTTP, a stateless protocol, as the file transfer protocol to talk to Web servers. This means that each HTTP request to the server is independent of the previous one, even if it comes as part of the same page load. (A typical page load can make hundreds of HTTP requests to multiple Web servers.) This means that for Web pages to act like “applications” (for example, an email client), an independent means of keeping state between HTTP requests is needed. That has led to the invention of ad hoc ways to pass state identifiers in HTTP headers, such as HTTP cookies and similar means of identifying a session.
The PacketZoom protocol creates a session that correlates with an application session. This session provides reasonable guarantees that an authorized native application is accessing the data from the server. This approach provides significant improvements over bare HTTP endpoints that anyone can access from any client (a major problem for apps with restrictive access requirements, such as apps that serve licensed content). This approach can be easily extended in the future to provide username-based authentication.
Security: The uncomfortable truth about Web security is that it isn’t. The peculiar requirements of Web browsers have driven the thinking about security over the last couple of decades. The result is that we have been trained to expect an almost monthly discovery of yet another SSL exploit, followed by patching and deprecating older versions of the protocol and software. The reason (or at least one of them) it’s so hard to make Web browsers secure is that they run code from millions of possible sources around the globe on billions of client devices while authenticating each party to the other, depending on hundreds of third parties to establish mutual trust, over a securely encrypted and authenticated connection.
Given that problem statement, the fact that we trust SSL/TLS to protect our financial transactions and other highly confidential information on a daily basis seems remarkable. But once again, this many-to-many problem is not the problem that native apps have to solve. Native mobile apps have a much narrower problem -- namely, the need to run compiled application code installed on N customer devices that has to securely connect to a fixed and limited number of server endpoints.
The security of native mobile apps deserves more attention. According to a 2015 report from Flurry Insights a full 90 percent of U.S. mobile users’ time is spent in native apps. And yet almost every native mobile application on the market still runs on the HTTP protocol over TCP. Native applications have no need to use HTTP at all, and thus could be freed of many of the constraints that plague Web-based applications.
The PacketZoom protocol has basic encryption by default (to prevent casual snooping by automated, man-in-the-middle listeners) with more to come in future releases.
Security concerns, authentication limitations, roaming hiccups, chatty protocols -- it’s time that native mobile apps were emancipated from the legacy of the Web. Hitching a ride on 1990s technology was a pragmatic way for mobile app developers to get up and running when mobile apps were new and the Web was still king.
Today it's very different. As more and more app publishers incorporate 21st-century solutions like PacketZoom in their apps, we hope and expect that the ecosystem of protocol bodies, carriers, and device vendors will get on board and finally ditch the legacy burden that’s weighing down the mobile user’s experience.
Chetan Ahuja is the founder, CEO, and CTO of mobile networking startup PacketZoom. Prior to starting PacketZoom in 2013, Ahuja worked on software and networking performance in companies such as Google, Admob, and Riverbed, where he gained a deep appreciation of the key role of network speed on application performance and thus on user happiness. He holds a Masters degree in computer science from Michigan State University and a Masters degree in computational chemistry from the Indian Institute of Technology, Mumbai.
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.