There is much talk in the industry right now on what is the best way to deliver content to mobile devices. In this detailed post, we will dive deeper into some of the mechanics of networking and what works best in different scenarios.
A crucial aspect of the mobile data infrastructure is the transport layer. It is the part of the software stack that is tasked with making sure our bytes are delivered reliably (i.e. not lost in transit), in the order they were expected, at a rate of transmission that the handset and network can handle without being overloaded. In short, reliability, in-order delivery, flow control and congestion control.
The “killer” apps today take many or all these capabilities for granted to satisfy use cases such as photos, messaging, video, document sharing etc. TCP, the transport protocol often used by HTTP and HTTPS, is designed to deliver all these functions and is now part of most operating systems. In that sense TCP fulfills the requirements for today’s apps. That said, it has been around since the beginning of the Internet. One could rightfully ask if TCP is still the best solution today or if a new transport protocol, such as a UDP-based approach would better fit our needs.
TCP has been designed to be very flexible — it anticipates the need to customize many aspects of data delivery and modern implementations demonstrate this flexibility. Even with these capabilities there are practical considerations that may make alternatives interesting. Here is where many solutions based on UDP appear. While TCP aims to deliver on all the requirements for a transport layer as discussed above, UDP aims to provide minimal functionality leaving key aspects to a higher software layer. Thus UDP does not solve for reliability, in-order delivery, flow control or congestion control. What it does provide is an ability to customize transport functions beyond even what TCP does since a solution on top of UDP would have to put together its own mechanisms for these key functions. The question then is, why do we need even more flexibility than what TCP provides?
There are certain specialized scenarios where not all features offered by TCP are needed or there needs to be a “mix-and-match”. An app may be loss-tolerant (e.g. losing some bytes in transit may be ok with certain live videos) and might wish to weaken reliability. There might be apps where the downloads are so short that the protocol mechanisms of TCP could become an overhead. Another scenario may be involving cross-layer techniques where an app wishes to hardwire choices across several layers such as security, transport and application.
Looking at the state of mobile today, such scenarios are certainly a niche. From an app’s perspective, a consumer enjoys rich experiences with downloads of dozens of files over the network from diverse sources to put together a visual. The physical network has also advanced rapidly to live up to these expectations — while LTE already delivered very low losses and good physical bandwidth, the upcoming upgrades are more promising. Thus in the context of mobile applications today, we do not see the specialized scenarios that demand a new protocol.
So why does mobile performance as perceived by the app continue to be a pressing issue? The gaps in the mobile performance armor really are in dealing with the entire gamut of variables that affect an app experience — API choices, concurrency, device & network technology variations and indeed the transport parameters as well. But the transport protocol is just one aspect of it and there is a lot of flexibility afforded by TCP that allows adaptations to most apps in the new mobile world.
What app owners need today is a disciplined approach to control all parameters across the mobile device, network and server to deliver the best performance. We have yet to fully leverage a whole host of facilities already available in popular operating systems before we jettison our current workhorses.
