PacketZoom Blog Does Google Know Better?

As mobile networking enthusiast, we've championed Google's QUIC since its inception and have considered it a valuable peer in the transition from TCP to UDP for mobile content delivery. However, multiple inquiries led us to believe that some clarifications are needed regarding QUIC, PacketZoom and the similarities/differences between them. In this blog and the associated technical analysis I will try to address some of them.TCP is the underlying protocol that makes the Internet work and has been around for decades. The rapid adoption of mobile devices in the past few years highlighted its weaknesses when dealing with mobile network specific challenges.Today the majority of TCP requests are originated from WiFi and cellular networks. These networks behave fundamentally differently than wired networks (5-10x higher latency, 10-20x higher packet loss and frequent connection breaks) that results in a spectrum of poor user experiences - from mediocre (in developed countries) to catastrophic (in developing countries).Developing countries such as India, Brazil and Indonesia are somehow behind when it comes to wireless infrastructure investment - a void that is being amplified when combined with the dramatic surge in mobile usage. Even when a significant investment is made in LTE network (e.g. India's Reliance Jio case) the results are not identical to what the average American or European consumer is used and there is a long way to go in order to close the gap.Local brands in SEA, LATAM and Eastern Europe are struggling to deliver the same business results on their mobile apps comparing with similar brands in N. America, Canada and Western Europe. International companies such as Google, Facebook and Snapchat can no longer ignore the differences in user experience and adoption between these regions.QUIC (Quick UDP Internet Connections) is a new protocol that was originated by the Google Chromium group in 2012 and was designed to overcome some of these challenges and is attacking the problem at its core - the protocol level.QUIC is an open source protocol that requires control on both ends of the connection (i.e. both client and server should speak QUIC) to make it work, as dictated by the stack. In 2018, a research conducted by Cornell University made an effort to assess the adoption rate of QUIC globally. The research found that QUIC accounts for 2.6% - 9.1% of the current Internet traffic, depending on the vantage point. This lion share of this traffic is originated by Google that is pushing almost half of its traffic (including all YouTube) via QUIC.This begs the questions: 1. Does Google know better? 2. What's the stand of other tech giants on the subject?While QUIC was originally designed for web apps, there are multiple hints available online indicating that the large tech companies not only in agreement with Google regarding the need to improve TCP in a mobile first world, but they are also adopting it for mobile apps. These hints point back to companies such as Facebook, Snapchat, Lyft, Uber and others.While there seems to be a consensus that a UDP based network stack would enable faster and more reliable mobile content delivery the path to implementing a fully functional QUIC based service is not a simple one.Migrating a traditional HTTP(S) based mobile application to QUIC requires at a minimum: Setup QUIC server(s) and deploy globally per end user distribution. Add QUIC client code to the app * Since no official Mobile SDK is available developers must either build their own or rely on third party frameworks * Support multiple OS (iOS, Android, Windows) * Enable Http fallback since * Some assets might not benefit from QUIC and need Http * Some networks block QUIC * To avoid service interruptionNeedless to say that smaller enterprises with standard R&D budget and common constraints cannot afford to use QUIC at this point and have to compromise with the default dated protocol that legacy CDN solutions offer.Over the past four years, many app publishers have opted to use a new solution, designed specifically for mobile network optimization: a complete end-to-end UDP based solution, offered by PacketZoom, that can be easily integrated by any App developer.PacketZoom Mobile Expresslane platform was created by a team of mobile network experts. It's a turnkey solution for content delivery and mobile networking, so not really an apple to apple comparison to QUIC, but given popular inquiry, here are the main differences between the two:PacketZoom's transport protocol makes runtime transport decision based on the actual underlying network. This is made possible thanks to billions of network performance data points collected over the years.PacketZoom SDK is around 500KB in size and requires no application code changes.Server integration is seamless and requires no DNS changes. The service is live and operating hundreds of shared servers globally.PacketZoom service includes smart server discovery (per user geo), full redundancy and fail forward design.App developers can tune the protocol for speed or reliability without making any code changes.PacketZoom SDK can be integrated in hours in both iOS and Android, and offers a free usage tier (up to 1,000 DAUs) for an easy ramp up.To summarize, supporting your application with a UDP-based network stack is likely to result in faster content (images, assets and videos) download as well as more reliable API calls. If you have deep pocket, time and resources available you might be able to leverage the QUIC open source opportunity and build a fully operational service that you have complete control over. If this is not the case you might want to consider a turnkey solution from PacketZoom.