Receive the latest in our newsletter. More
Receive the latest in our newsletter. Less
Something went horribly wrong with your application submission. Please try again later.

Bolina: newer, faster protocol to overcome wireless instability

Codavel Performance Service 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. 

Why our tech
Legacy approach
Bolina at work
What to expect
FAQs & Resources

Why our technology?

Do we need to ensure fast content delivery over wireless links?

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 Knowledge Base. 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!

Legacy approaches

Why these approaches fall short

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. That is why video startup time is getting worse (11% worse according to Conviva). Also from Conviva’s data, a staggering 5.1B viewing hours were lost due to buffering. To add to this dramatic scenario, Mux’s data shows that half of the video sessions suffer from buffering, whereas almost half the users have to wait for more than 11s to start a video, at least once.

Why is user experience failing, despite all the optimization efforts done so far?

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.

ARQ-based protocols behave poorly over wireless links

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.

Bolina Protocol at work

Network Coding for packet loss recovery

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.

Network Coding for packet loss recovery

1. Feedback is not necessary for packet loss recovery

Standard Protocols

• 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

• 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%.

2. Feedback is used to assess link quality

Standard Protocols

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

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.

Deploying Bolina in a mobile app: UDP

Bolina is not a new improvement to TCP, it is an entirely new protocol. Therefore, in order to deploy Bolina in a mobile app, it is necessary to be able to do it at user space. That’s why Bolina protocol is deployed on top of native UDP sockets, ensuring that you can benefit from Bolina in any mobile app, in any mobile device, in any network. In other words, we use UDP as the underlying protocol to avoid requiring changes to operating systems and middleboxes. Bolina is also capable of detecting if UDP is blocked on the users’ network, or if UDP links are throttled down by the network operator. In these cases, Bolina will make use of TCP, ensuring that the end-user experience is not affected.

Inside Bolina

Multiplexing

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.

No OS modifications

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.

Compatibility with any app layer protocol

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.

0-RTT handshake

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.

State-of-the-art security

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).

Seamless integration via Codavel SDK

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.

What to expect from Bolina’s Performance

Time to start a video

AVERAGE

5.050 ms
Usual CDN
3.420 ms
-32%
Codavel

90TH-PERCENTILE

11.300 ms
Usual CDN
5.910 ms
-48%
Codavel

Time spent on  buffering

AVERAGE

6.762  ms
Usual CDN
3.046 ms
-55%
Codavel

90TH-PERCENTILE

40.724 ms
Usual CDN
10.886 ms
-73%
Codavel

Video quality per session

AVERAGE

2060 Kbps
Usual CDN
2470 Kbps
+20%
Codavel

90TH-PERCENTILE

589 Kbps
Usual CDN
1140 Kbps
+91%
Codavel

Time to start a video

AVERAGE

5.050 ms
Usual CDN
3.420 ms
-32%
Codavel

90TH-PERCENTILE

11.300 ms
Usual CDN
5.910 ms
-48%
Codavel

Time spent on  buffering

AVERAGE

6.762  ms
Usual CDN
3.046 ms
-55%
Codavel

90TH-PERCENTILE

40.724 ms
Usual CDN
10.886 ms
-73%
Codavel

Video quality per session

AVERAGE

2060 Kbps
Usual CDN
2470 Kbps
+20%
Codavel

90TH-PERCENTILE

589 Kbps
Usual CDN
1140 Kbps
+91%
Codavel

Get more details in our

video streaming report

Image Loading Time

AVERAGE

2.110 ms
Usual CDN
1.380 ms
-35%
Codavel

90TH-PERCENTILE

5460 ms
Usual CDN
4090 ms
-25%
Codavel

Nº of Images Delivered Per Second

AVERAGE

2,84 images
Usual CDN
4,34 Images
+34%
Codavel

90TH-PERCENTILE

1,1 images
Usual CDN
1,47 images
+25%
Codavel

Image Loading Time

AVERAGE

2.110 ms
Usual CDN
1.380 ms
-35%
Codavel

90TH-PERCENTILE

5460 ms
Usual CDN
4090 ms
-25%
Codavel

Nº of Images Delivered Per Second

AVERAGE

2,84 images
Usual CDN
4,34 Images
+34%
Codavel

90TH-PERCENTILE

1,1 images
Usual CDN
1,47 images
+25%
Codavel

Time to start a video

AVERAGE

5.050 ms
Usual CDN
3.420 ms
-32%
Codavel

90TH-PERCENTILE

11.300 ms
Usual CDN
5.910 ms
-48%
Codavel

Get more details in our

media delivery report

Detailed comparison with QUIC

Image Loading Time

AVERAGE

2.110 ms
Usual CDN
1.380 ms
-35%
Codavel

90TH-PERCENTILE

5460 ms
Usual CDN
4090 ms
-25%
Codavel

Nº of Images Delivered Per Second

AVERAGE

2,84 images
Usual CDN
4,34 Images
+34%
Codavel

90TH-PERCENTILE

1,1 images
Usual CDN
1,47 images
+25%
Codavel

Time to start a video

AVERAGE

5.050 ms
Usual CDN
3.420 ms
-32%
Codavel

90TH-PERCENTILE

11.300 ms
Usual CDN
5.910 ms
-48%
Codavel

Packet Loss Rate = 0.1% | Request size = 250 Kbytes

check bolina vs quic

Time to start a video

AVERAGE

5.050 ms
Usual CDN
3.420 ms
-32%
Codavel

90TH-PERCENTILE

11.300 ms
Usual CDN
5.910 ms
-48%
Codavel

Get more details in our

video streaming report

Time spent on  buffering

AVERAGE

6.762  ms
Usual CDN
3.046 ms
-55%
Codavel

90TH-PERCENTILE

40.724 ms
Usual CDN
10.886 ms
-73%
Codavel

Get more details in our

video streaming report

Video quality per session

AVERAGE

2060 Kbps
Usual CDN
2470 Kbps
+20%
Codavel

90TH-PERCENTILE

589 Kbps
Usual CDN
1140 Kbps
+91%
Codavel

Get more details in our

video streaming report

Image Loading Time

AVERAGE

2.110 ms
Usual CDN
1.380 ms
-35%
Codavel

90TH-PERCENTILE

5460 ms
Usual CDN
4090 ms
-25%
Codavel

Get more details in our

media delivery report

Nº of Images Delivered Per Second

AVERAGE

2,84 images
Usual CDN
4,34 Images
+34%
Codavel

90TH-PERCENTILE

1,1 images
Usual CDN
1,47 images
+25%
Codavel

Get more details in our

media delivery report

Nº of Images DDetailed comparison with QUIC

GePacket Loss Rate = 0.1% | Request size = 250 Kbytes

check bolina vs quic

Frequently Asked Questions

Does Bolina require modifications to operating systems?

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.

Does Bolina work on any network, on any device?

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.  

Can Bolina be used on web apps or websites?

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.

Does Bolina rely on data compression? Does it alter, tamper or modify the payload?

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.

Does Bolina hurt non-Bolina traffic flows?

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.

Is there a way to optimize TCP or QUIC to get the same benefits as Bolina?

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.

Is Network Coding just another form of Forward Error Correction (FEC)?

No. From our technology partner Code On, here’s a list of core differences:

Don’t Bolina performance numbers look too good to be true?

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

Are there any security vulnerabilities by using Bolina?

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.

What is the processing cost of Bolina and Network Coding?

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.

Is Bolina a proprietary technology?

Yes. You can find the list of patents being used in Bolina below on this page, under resources.

Resources

Talks & Videos
Articles & White Papers

We will help you find out from where you are getting the most harm, and fix it

learn more