It was a sunny California day, sitting in Caltrain on my way to Mountain View, staring at the dreaded spinning wheel of death that I finally snapped.
I'm sure this resonates with millions of frustrated mobile users world-wide. Even more so among the next N billions of mobile users who are depending on constantly overloaded mobile networks in Asia, South America and other emerging markets. I experienced this first hand in my recent trip to India when a simple act of trying to load the first screen of an app in a moving metro train was enough to drive a man crazy. Only an exercise in enormous restraint prevented me from going the full Office Space on my phone:
The worst thing about all this is that it didn't have to be this way. The last few years we have seen an explosion of apps and new ways of using mobile. The next few years promise to bring exponentially larger number of devices in the form of "Internet Of Things". And yet, we have insisted on using technology invented 40 years ago to connect this new and amazing world of devices. Sadly, the legacy millstone weighs heavy around our necks as we try and make this exciting new world work with creaking old technologies.
Long, long ago in a world built on utopian ideals, it was decided that the address for a computer on the network (and yes, your mobile phone is a computer) would be an IP (Internet Protocol) address... a thing that was supposed to be solidly and reliably attached to one computer forever, like your street address attached to your house. A packet sent to that address could only go to one place (the house, or in our analogy, a single computer). But now, in the year 2015, the IP address is but an ephemeral property of the mobile device. It's as if everyone lives in a van now and your address depends on where you parked it last night.
The IP address of your device might change while you walk from your office to the parking lot. As you move away from your office wifi, to the LTE connection in the parking lot, and move through myriad disconnections and reconnections while traveling in personal or public transportation, you could be taking and releasing dozens of IP addresses during the course of your commute.
So why's that a problem. Well, the problem is, if the IP changes while your app is downloading something from the cloud it has to do a full cold start all over again. Every. Single. Time. If you were almost done with downloading that picture or that video snippet in your chat, well tough luck. Go back to zero. On top of this new IP address, TCP has to establish a new session which also starts cold and has to gently ramp up to full speed every single time. Oh... did we not talk about TCP yet?
TCP (Transport Control Protocol) is the data transport protocol that has been honed over the years to work "reasonably well" for general use over all possible kinds of networks. It was originally designed to connect big huge computers, adminstered by professional sysadmins, housed in meticulously maintained facilities with triple redundant power. It does the job that it's least-common-denominator design is expected to do. To get a stream of data from one computer to another (i.e. from one IP address to another),in a reliable, in-order manner. Those are the guarantees this protocol provides. What it doesn't guarantee however, is anything about speed.
In particular, TCP is horrendously wasteful of network round-trips. Here's how a TCP connection ramps up:
(Image courtesy of this excellent series of blog posts). What you're seeing in the diagram above is the server side TCP taking the first few round trips to gingerly "probe" the channel and see whether it can send, say, 50KB of data down the pipe without Breaking The Internet. The assumption is, the server side knows absolutely nothing about the channel it's operating on when it starts. This process is called slow start and is another HUGE problem in the mobile network situation. That is because the round-trip times on mobile carrier networks are much much larger than those over your home or office networks. Not by a few percent but by multiples of 5-10 or more (depending on what combination of mobile and wired networks you're comparing).
TL;DR - TCP uses the most conservative method possible to get your data packets from one place to another. It also has no mechanism to understand that the same computer (your mobile device) can move from IP to IP in a short period of time. The result -- user level protocols (e.g. HTTP) get cluttered with hacks atop other hacks to try to work around TCP.
Irony here is that browsers and other apps work as hard as they can to defeat TCP's conservative strategies.
Now imagine this conversation that literaly, actually (well, probably, maybe... I'm guessing) happened sometime in the early aughts among head boffins at the.. uh.. web browser factory:
Boffin A: "TCP doesn't allow us to use the full available bandwidth of the available channel (DSL, Dialup, those new fangled cable modems or what have you)"
So that's what the web browsers have been doing ever since then, with the intention of cleverly defeating TCP's slow-start and backoff strategies. What's backoff? Oh, don't get me started on backoff. Look at the graph representing TCP throughput below:
That huge gaping valley in transfer throughput around the 4 second mark... that's because a few packets were lost in transit. Basically think of TCP backoff as doing slow start all over again just because you lost a packet, say, in a moving train situation. (More details here. That is where the chart came from.)
So getting back to application level hacks, the Web, of course, runs on Hyper Text Transport Protocol aka, HTTP (which has been on version 1.1 for the last decade and a half). HTTP, as an application level protocol, knows nothing about speed either. It just trusts the underlying TCP layer to handle all that stuff. But the browser vendors, over the years, have come up with a sort of mishmash of folklore based tips, tricks and hacks to keep this train running somehow -- like the multiple-parallel requests hack mentioned above. Lately, a lot of these tips and tricks (along with some pretty good, solid protocol design) have been refined and codified into the latest revision of HTTP spec (version 2). But here's the problem: the old protocol, the hacks and finally the new protocol... they are all still limited by our old friend, TCP. Besides, the explicit and only focus of all these efforts is the web. The *WEB*!
Can we talk about the Web for a minute. Remember the time when we used to call it the World
Wide Web? You know what's
May I be blunt about what people do on their smartphones -- *NOT WEB*.
When was the last time you opened a web browser on your mobile phone and typed in a URL? You're not alone. About *86%* of mobile users agree with you. Here's a chart showing the rapid decline in mobile web usage from Flurry Analytics:
And therein lies the tragedy. Web has had almost 2 decades of being the dominant application platform. Gigantic hardware and software platforms (and companies) have been built to service the web (Notice how it's called "Amazon web services" even though what they're selling is basically raw virtual machines in a data center). And not surprisingly, when the mobile native apps first started becoming popular, the developers went right on using the same tools and protocols that everybody was using on the dominant platform of the day. Namely, HTTP running over TCP.
We had no recourse in the past, mainly because the constraints of what could be done in a web browser held us back. As long as your application is running in a web browser, there's nothing, absolutely nothing, you (the app dev) can do to fix the networking.
But now, a new dawn is upon us. The dominant platform for applications is not the web anymore. It's the native apps on Mobile.
And just like that, we're free of the shackles of HTTP and even TCP. We, as app developers and their supporters, are free to invent protocols that make sense for this spottily connected, packet lossy, high latency world. Give us a way to get packets from one place to another and get out of our way. We want to treat a mobile device as one entity no matter how many times it changes IP addresses. We want to use the fact that we KNOW the difference between 2g, 3g and LTE networks. We even know how the same network type might vary between carriers and locations. We understand that a packet drop on a noisy mobile network doesn't have to spell doom for our throughput. We are mad as hell and we're not going to take it anymore. Well ok, we'll take it from our web browser (because... uh... what choice do we have) but not from our mobile apps.
So how will we do all this? Well, to start with, how about some of the stuff we describe here. We're proud to have taken the first step in a long journey. We hope it'll culminate in the entire ecosystem of protocol bodies, carriers and device vendors seeing the light. And maybe finally ditch the legacy that's holding us back. Yes, it might take years or even decades, but we have to start somewhere. In the meantime, PacketZoom is available today for those developers who'd rather not wait that long.
See what I did there?