This post looks at Google’s QUIC and the PacketZoom Mobile Expresslane and how its two protocols differ; after starting with a summary of the existing Internet protocols and why there is a need for change.
Challenges with packet delivery over existing Internet protocols in the Wifi and mobile network space are leading to new innovations in content delivery and the web’s underlying infrastructure. QUIC is a relatively new Internet protocol from Google that has been getting attention lately for its potential to speed up mobile delivery and PacketZoom has likewise been receiving a surge of interest in its Mobile Expresslane networking stack.
Existing Internet Protocols
TCP stands for Transmission Control Protocol and was built on top of the Internet protocol (IP), making it one of the main protocols on which the Internet was built. It is is a connection-oriented transport layer protocol. TCP establishes a set of rules that define how a device can establish and maintain a network conversation with other devices through the exchange of packets. TCP ensures that each packet is delivered (i) by numbering them and (ii) by having the recipient send a response back to the sender saying it has received the message. The connection is only closed following successful delivery of the packet (including after multiple attempts) or after an unrecoverable error condition has occurred.
The TCP Congestion Control Algorithm on servers works to reduce the impact of network congestion and minimize packet loss. It does this by adjusting the size of the packets and/or reducing the number of packets that are in-flight across the network – based on the amount of loss being detected.
Mobile Network Challenges with TCP
Mobile is radically changing congestion behavior on the Internet, however, and the default TCP response to congestion (that assumes a latent, longer-term problem) can be the wrong response to sporadic, random congestion and lead to serious performance degradation in wireless networks.
How does UDP Compare?
UDP stands for User Datagram Protocol and is an alternative transport layer protocol that is connectionless, and therefore deployed when the overhead of a connection isn’t necessary. Unlike TDP, UDP doesn’t guarantee that the packet will actually arrive at its destination. If a delivered packet doesn’t show up after a given amount of time, UDP will either send the packet again or give up. UDP is typically used when speed is desirable (it enables a faster stream of connection by doing away with error-checking) and when error correction is less important. Its main usage at the application level is for DNS.
Enter QUIC: A New Protocol for the Mobile Age?
QUIC is a new protocol, which stands for Quick UDP Internet Connections. It was begun as an experiment by the Google Chromium group in 2012 in order to attack the problems related to mobile network challenges at their core – the protocol level. An IETF working group was established in 2016, which now runs QUIC. It has not yet become an official standard.
QUIC supports a set of multiplexed connections over UDP and offers a reliable, connection-oriented low-latency and fully-encrypted transport.
Some of its key innovations include:
- Bandwidth estimation in each direction to anticipate congestion, meaning client and server should speak QUIC in order to control both ends of the connection
- Pacing packet transmissions evenly to reduce packet loss
- Packet-level error correction codes are used to reduce the need to retransmit lost data
- Cryptographic block boundaries are aligned with packet boundaries in order to further contain the impact of packet loss
In 2018, a team of researchers at Cornell University conducted a study into the global adoption rate of QUIC. They found that it accounts for 2.6% – 9.1% of all current Internet traffic (depending on the vantage point). Much of this is due to the fact that Google is pushing over 40% of its traffic (including YouTube) via QUIC.
QUIC was originally designed for web apps, but it appears as if several of the large tech companies, including Facebook and Uber, are considering adopting it for mobile network use. A consensus seems to be building that a UDP based network stack would enable quicker and more reliable mobile content delivery.
However, the path towards implementing a fully functional QUIC-based delivery mechanism is not straightforward and currently quite costly. At a minimum, migrating a traditional HTTP(S) based mobile application to QUIC requires the following:
- The set up of QUIC server(s) globally and their deployment per end user distribution
- Adding QUIC client code to the mobile app:
- As there is not an official mobile SDK, developers currently need to build their own or use third party frameworks
- QUIC client code needs to support multiple operating systems (iOS, Android, Windows)
- HTTP fallback must be enabled to avoid service interruptions as some networks may block QUIC and other assets might need to remain with HTTP.
Therefore, migration to QUIC (and the associated building of a fully operational service) is simply not a present-day option for most smaller businesses with standard R&D budgets.
PacketZoom Mobile Expresslane: a Turnkey Solution?
The PacketZoom (PZ) Mobile Expresslane platform is a turnkey end-to-end UDP based solution for content delivery and mobile networking.
The PZ platform is certainly not a direct comparison to QUIC; in many respects, the protocols are quite different. However, PacketZoom’s platform is a popular alternative for app publishers that are focused on mobile network optimization. It offers many of the same advantages as QUIC, but far less of a need for operational overhaul.
The main differences at a system level between the PZ transport protocol and the Google QUIC protocol are the following:
- The PacketZoom Mobile Expresslane makes runtime transport layer decisions founded on the performance of the actual underlying network, factoring in decisions such as network type, connection latency, throughput, signal strength and packet loss. The QUIC protocol meanwhile behaves the same on any network.
- PacketZoom SDK requires no application code changes to tune it for speed and reliability except for SDK initialization during setup; whereas QUIC demands the building of an entire client app logic, plus legacy HTTP support will likely still need maintaining.
- PacketZoom is only around 500K in SDK size for Android and 600K for iOS; QUIC is 1.5MB for libcronet Android.
- Server integration requires no DNS changes and automatically connects to the origin or server CDN with PZ; with QUIC, a new server (or proxy) must be developed.
- PZ is a live service operating hundreds of shared servers worldwide; for QUIC, the user has to set up and deploy new servers in the intended geographies.
- The PacketZoom Mobile Expresslane service includes a fail forward design whereas this needs to be developed from scratch for QUIC.
- PacketZoom’s platform includes Mobile IQ: a built-in on device analytics service. This is not currently an option with QUIC.