5.3 Bandwidth Estimation

If I were to look at media quality and decide what goes into the equation of that, I would say, well, it’s a mixture of the device capabilities, the network conditions and user locations. Where the user is, how does it network behaves, and what his device can do. For device capabilities, that includes battery type, the battery life, the size of the battery, the display that he has hardware acceleration, the CPU, the camera, and all of these aspects of a device. From a network conditions perspective, that’s going to be things like bitrate, jitter, packet loss, latency, all of these metrics that we like to collect about media, user location, that’s going to be around the lighting, and the background noise of the person. These are all going to affect media quality. Now, the thing is that the only thing that we can control in a real-time engagement platform as the application is the bitrate. Once the session starts, the only thing we can control is, for example, let’s increase or reduce bitrate. Everything else is going to follow.  

So we need to decide on our target encoding bitrate—how much data we want to send, or what is the maximum data that we want to send over the network. This is going to be affected by the device CPU state and capability, both on the sender side and the receiver side. I don’t want to send more than the other side is able to decode and process or more than you can display on the screen. Then also by the bitrate is that is available on the network. If I tried to send more than the network can carry, I will have packet losses and that is going to affect badly in terms of media quality.  

To understand the available bitrate on the network, we need to understand that this is dynamic. Over the course of our session, over time, the available bandwidth is going to fluctuate, it’s going to go up and down based on a lot of different criteria. These can be local reasons that cause these fluctuations. Like someone using Google Drive, Dropbox, or other cloud storage to upload the non-download stuff at the same time that we’re running the session. It might be someone using Netflix to video stream TV shows on the same network, or it might be the use of an email application, Facebook, or the reception on the local network. A lot of things that go through the local environment of that device and the network that is on.  

Then there are external reasons. This might be server-side congestion and load. Just because the infrastructure wasn’t built or designed properly, or there are too many people that have joined above and beyond what we’ve planned and designed and designed for. Or also the traffic loads that we are sending. We’re sending them along different routes of the media, but because of other issues unrelated to our own service and infrastructure. So how do we know how much we’re allowed to send?  

We want to send data on the network. But when nobody tells us, “Well, you’ve got now half a megabit per second that you can send.”  This isn’t happening. So, what do we do? We estimate. The easiest way or the most naive way to estimate is to ask ourselves, was there packet loss? I sent packet to the other side. Did he receive everything or he’s easy complaining about packet loss? If there is no packet loss, well, we can increase the bitrate if we want to, and try to see what happens then. If there was packet loss, then we probably need to reduce the bitrate. Packet loss is usually an indication that we can’t send data over the network, and the network can’t allow it. So, we’ll try to send less then run this with the new value that we’ve got for the bitrate for the next couple of seconds and it should ask again. Was there a packet loss now? Yes? Then reduce bitrate. No? Then increase bitrate. The problem with this approach is that we wait for packet loss. And if there is packet loss, it means that we already have a problem. So, what we really want to do is to ask, do we expect packet loss? We’re going to do an estimation that is based on what we expect the network would do and how it will behave. 

There are two types of packet losses that we need to be able to model or we want to model. The first one congestion. If we reduce bitrate when there’s congestion, things aren’t going to improve. Why? Because we’re sending less and congestion is going to go down. Then there’s corruption. The network is just bad as it is and we’re going to have the same packet loss no matter what we’re sending, no matter what the bitrate is. So, let’s say, half a percent of a packet loss is static all the time no matter what we do. So, in this case, we might not want to reduce bitrate. So, we need to be able to understand or try to figure out what is the type of packet loss that we’re seeing. Is it congestion or corruption? And then act accordingly?  

You need to understand that estimation is hard. We need to decide how aggressive are we going to be with our estimations? Okay, do we want to quickly increase or decrease the bitrates based on what we see?  If we increase too fast, we will see that packet loss is too fast. If we increase too low, then media quality is going to suffer because we’re not using as much as we can out of the network. Then there’s the question of how do we distinguish congestion from corruption? Which for most intents and purposes, it’s still an open question with no specific answer in the industry of how to deal with that—only different types of heuristics of what to do in these cases.  

To summarize, bitrate is a very important factor in media quality. It’s the only one that we have any control of we can increase and decrease that and what we want to do is to place our estimated bitrate as close as possible to what the network can carry. Doing a very good work at estimating bitrate is key to increasing the quality of our service. Thank you.