Codavel Mobile CDN is built on top of our core technology, Bolina: a mobile-first protocol that outperforms HTTP, including its latest version, HTTP3 (based on QUIC). Bolina is capable of handling the worst network conditions, presenting robustness against latency and packet loss, regardless of the user’s network, device, or location.
Speed matters, a lot. How fast content is delivered to a mobile app has a tremendous impact on user engagement, with faster apps getting an advantage over their competitors in relevant KPIs:
• More Daily Active Users
• More Sessions per User
• Longer User Sessions
• Higher User Retention
• Higher Conversion Rate
• Higher ARPU
In case you are curious to learn more about the impact of performance on mobile apps’ KPIs, check our Performance Bookshelf. You can find there more than 200 curated articles on why and how much speed matters for delivering a successful mobile app. And you can also contribute with your own suggestions!
The impact of content delivery speed on user engagement is the reason why the industry has been investing heavily in optimizing mobile app performance and improving user experience. Optimizing content size, improving network call management, and, most notoriously, using Content Delivery Networks (CDNs) are among the most common approaches.
Why are CDNs so widely used these days? The speed at which content is delivered is highly impaired by latency and packet loss and, by placing content closer to the end-users, CDNs enable a significant reduction of latency and, therefore, higher content delivery speeds.
However, at least for mobile apps, these approaches are not enough. Recent data from Uber shows a dramatic picture: the latency experienced by mobile app users is high and highly unstable, across the globe.
This is causing video startup times and buffering to worsen for mobile devices. According to NPAW, in just one semester, smartphones experienced an 8% increase in join time when streaming linear video content. Meanwhile, buffering for VoD jumped up by 16%. Higher waiting times have a great impact on viewer engagement, with NPAW data showing that more users drop off before the video starts and consume less content overall.
In a nutshell, while optimization focus is on the cloud and on the app, more than 90% of latency and packet loss happen over the wireless link, i.e. over WiFi, 3G, 4G, or even 5G.
The root of the problem lies in the fact that the protocol being used to deliver content, HTTP, is not suited for the high instability of wireless links. HTTP relies on another protocol, TCP, which is the foundation for today’s reliable internet communication. The problem is that TCP was designed for a wired world, not dealing well with the inherent instability of wireless links. For example, just 0.1% of packet loss brings speed down by 5 times.
TCP has been revisited several times over the years, in particular with respect to its congestion control mechanisms. More recently, QUIC (which works over UDP transport) has been proposed as an alternative to TCP and is the foundation of HTTP3. With a cross-layer approach to transport and security, by combining TCP and TLS roles, QUIC enables significant improvements in connection establishment.
Nevertheless, both these protocols take the same approach to handle packet loss: relying on feedback to recover from losses. In other words, TCP and QUIC are both ARQ-based protocols.
The problem with ARQ protocols is the fact that, to recover from a lost packet, the receiver needs to detect it, the receiver needs to inform the sender of the loss, and then the sender has to retransmit the lost packet. All of this is highly impaired by latency.
Consequently, all versions of HTTP, including HTTP3, are highly impaired by the latency of the link, in particular in lossy links. And that’s precisely what characterizes wireless links (like WiFi, 3G, 4G, or even 5G): significantly higher latency and packet loss.
In contrast with ARQ-based protocols, like TCP or QUIC, Bolina relies on Network Coding techniques to overcome packet loss, which makes it more robust to packet loss and latency. In a single word: faster.
Network coding, very simply, consists of mixing original data packets into coded transmissions. This enables overcoming packet loss without the need for feedback or retransmissions. It also enables revisiting the role of feedback information.
In a nutshell, Bolina relies on two fundamental principles:
1) feedback is not necessary for packet loss recovery
2) feedback is used to assess link quality.
• Standard protocols recover from packet loss by using feedback. This means that the sender needs to wait for feedback (ACK) before sending new data.
• Highly impaired by the time it takes to receive thatfeedback (~latency)
Mixing original data packets into coded transmissions to overcome losses enables the following:
• Recover from packet loss independent from feedback
• No need to wait for feedback before sending new data
This allows higher robustness to latency
• Standard protocols recover from packet loss by using feedback. This means that the sender needs to wait for feedback (ACK) before sending new data.
• Highly impaired by the time it takes to receive thatfeedback (~latency)
Mixing original data packets into coded transmissions to overcome losses enables the following:
• Recover from packet loss independent from feedback
• No need to wait for feedback before sending new data
This allows higher robustness to latency
Remark: Network coding techniques enable live link assessment, which means that no pre-established redundancy is necessary (in contrast with standard Forward Error Correction techniques). This translates into no useless transmissions. Bolina’s overhead is below 0.1%.
Standard protocols can’t understand the nature of packet loss. The sender always assumes losses happen only due to congestion. This is not always true, especially in wireless. This is why standard protocols decrease speed when it is not necessary.
Coded transmissions solve the losses, feedback is only used for link quality evaluation, in particular, to evaluate loss nature. This way, the sender is capable of distinguishing losses due to congestion from other losses.
Standard protocols can’t understand the nature of packet loss. The sender always assumes losses happen only due to congestion. This is not always true, especially in wireless. This is why standard protocols decrease speed when it is not necessary.
Coded transmissions solve the losses, feedback is only used for link quality evaluation, in particular, to evaluate loss nature. This way, the sender is capable of distinguishing losses due to congestion from other losses.
The number of simultaneous connections affects how your system handles scalability. Bolina Client efficiently groups multiple requests to the same server within the same connection to avoid the unnecessary increase of the server load.
Client and Server run at the application layer. No special permissions are required. This is possible because Bolina uses UDP to have full control of the link. Bolina also makes use of TCP in links where UDP flows are impaired for network policy reasons.
Bolina is implemented as a socket, with the same features as a regular TCP socket, but at a higher speed: reliable and ordered delivery, and congestion control. Therefore, it can be integrated with any application layer protocol, such as HTTP, SCP and FTP.
Bolina enables a zero round trip time handshake. Similar to TLS 1.3, with this feature the client does not waste time establishing a connection to an already known server.
With end-to-end security enabled by default, the privacy of your data is guaranteed with well-known standards for encryption and authentication (ChaCha2020 and Poly1305).
Codavel SDK allows you to deploy Bolina without having to modify your app architecture, with off-the-shelf integration with AFNetworking, Alamofire and OkHttp. Codavel SDK also works with any other HTTP/HTTPS library.
Frequently Asked Questions
No. We have built Bolina on top of UDP sockets precisely to avoid any modifications in operating systems. Bolina transport decisions are all performed at userspace.
Yes. Although the core benefit of Bolina is obtained with UDP sockets, in case of a UDP blocked or UDP throttled network, Bolina has mechanisms to detect this behavior and fall back to TCP without jeopardizing user experience.
Not yet. Bolina requires software to be running on the client-side to manipulate traffic and sockets. For the case of native mobile apps, that’s achieved via Codavel SDK. For anything running on a browser, the ability to access and manipulate sockets on the client-side is limited, at least for the time being.
No. Bolina does not compress, neither alters, tampers, or modifies the payload. Not even Codavel has access to the payload that is being transmitted via Bolina.
No. Using Bolina and Network Coding doesn’t hurt anyone’s flows. Everyone who uses Bolina benefits from Network Coding, and those who don’t use Bolina can co-exist in the network with those who do without seeing any negative consequences. Learn more here.
No. As both TCP and QUIC make use of ARQ to overcome packet loss, they are limited by design and their performance is suboptimal, as described above.
We hear this a lot. That’s why we made it possible for you to test it for yourself, with no costs, no strings attached. Learn how here.
No, Bolina does not bring any additional security vulnerabilities. Bolina follows state-of-the-art guidelines. Please learn more about Bolina’s security aspects here.
Studies show that Network Coding techniques use 2 to 3 orders of magnitude (100 to 1000 times) less energy than WiFi transmission. This small encoding cost reduces download delays by 4x in real-world wireless scenarios, hence offsetting the processing, latency, and energy involved in retrieving the missing data without coding. A mobile device using Network Coding uses less energy and therefore has greater battery life. Learn more here.
Yes. You can find the list of patents being used in Bolina below on this page, under resources.
Resources
