Loss-based bandwidth estimation

🎻 June 2023 fiddle

Want to learn more about WebRTC?

Look us up here for the WebRTC Fiddle of the Month, created… once a month.

Or just enroll to one of our excellent WebRTC training courses.

Resources

• The fiddle: https://jsfiddle.net/fippo/d5o391s7/6

Transcription

Tsahi: Hi, and welcome everyone to another WebRTC Fiddle of the Month. This time, we’re going to talk about loss-based bandwidth estimation. And what exactly does that mean? We have this nice slide here for you. Essentially, when we talk about loss-based bandwidth estimation, the thing that we care about is shoving as much as possible into the network. We want to do that anyway with bandwidth estimation to understand how much there is. But here, it’s like luggage. We’re going to shove in as much as we can until we can’t shove anymore because things start spewing out of the luggage and we can’t close it anymore. How does it work exactly? First of all, we send out media because this is what we’re trying to do. We send media, the receiver looks at that and says, Well, was there any packet lost? Did I lose anything in the process? If the answer is yes, we’re going to decrease the bandwidth. It means that if there is packet loss, we can reduce bandwidth estimation for what we think we can send over the network. If the answer is no, there is no packet loss, we can increase our bandwidth estimation values. So that’s a bit what’s going on.

Now, the good thing about it, it’s really simple to implement. The slightly bad thing about it is that once there is packet loss, it already means that there is a problem, and we’re trying to solve the problem after it happens. Now, what we want to focus in this fiddle is how exactly that looks like on the network itself. And this is where you come in, Philipp.

Philipp: Yes. So we have a fiddle that needs to do a lot of extra work to disable the smarter universe information, the delay-based information in WebRTC. We start simple. If you run it yourself, I recommend running it with these Chrome settings because that gives you a connection which is a bit delayed, which makes it a bit more realistic. Then we do have a nice graph here, which you can see on the right. This part is our normal local peer connection exchange. But we do a little bit of SDP manipulations here. We place the transport wide-cc bandwidth estimation algorithm, just replacing it in the SDP with something that is not understood on purpose. This removes the header extension in the RTCP feedback transport-cc. This removes the feedback for REMB, the other bandwidth estimation mechanism in WebRTC. This removes two header extensions that are used for REMB.

Tsahi: Essentially, what we’re doing is we’re saying we want to see how RTCP would work without anything smart taking place. We’re not going to say much about have packets been lost, when exactly what we think the bandwidth is going to be. We’re just going to force WebRTC to work blind.

Philipp: Well, not blind. It is still getting the RTCP feedback about the loss. That’s what we’re making it focused on. That’s the only thing that’s left.

Tsahi: The most naive approach, the one that you would expect to see 20 years ago in implementations.

Philipp: Yes. If you actually look at the libWebRTC implementation, we’re filling a code that which has not maintained for 10 years. If we run it, you can see here is that the start, it’s 300 kilobit per second estimate. Then it increases. You see, well, now it doesn’t increase, but it increases again. You can see it increases exponentially. I think it’s roughly 8% per iteration. You can see it goes slowly, it starts going up more steeply. That’s the factor by which it increases always around it. One of the other tools you can use to look at this is the WebRTC internals event log dump. I have the dump importer for that, and I did this fiddle with a graph, or with a dump from it. We can see it shows things like loss-based state and delay-based data. We can see that it starts at 300 kilobits per second, and then it slowly goes up in a step-wise fashion. So it always increases 8%, 8%, and so on. Usually, when you use WebRTC, you also have the delay-based state. But since we disabled all the delay-based stuff in this fiddle, we don’t see that. One of the interesting things we found here is that even though we don’t negotiate REMB (remote bandwidth estimator in WebRTC), it is still being sent by the remote, which is a bug.

Tsahi: Nobody cares about it because why would you be failing?

Philipp: Yes. It doesn’t hurt because it has given you roughly the same values as you get from the other side, caps on the different point, but it works. This bandwidth estimation mechanism is really primitive compared to what you have with some more modeling transport-cc and later.

Tsahi: okay. I guess that’s the end for this time. See you next time in WebRTC Fiddle of the month.