Short talk by Tsahi Levent-Levi explaining available bandwidth (the true, time-varying network capacity) versus bandwidth estimation (WebRTC's estimate of that capacity). He outlines two error types: underestimation (missed opportunities for higher bitrate and video quality) and overestimation (causes packet loss, latency, poorer video and oscillation). The goal is accurate, dynamic estimation that avoids overshoot. External links for testing/learning (testrtc.com, webrtccourse.com) are mentioned.
Chapters
Here are some thoughts about bandwidth estimation. And to start, I'm going to look at available bandwidth and bandwidth estimation. Available bandwidth is the amount of bandwidth that we have over time in our network to be able to either send or receive data. This changes over time and it's dynamic in nature. We don't know what it is going to be. It is affected by whoever is using the network, what happens along the routes and many other parameters. Bandwidth estimation or the estimated bandwidth is what we think or what WebRTC thinks the available bandwidth is. It isn't exactly the available bandwidth because we don't really know that. That's a kind of a theoretical value, but it's an estimation of that. Now, what happens if we estimate less than what is available? Okay, so what happens is that we become inefficient in what it is that we're doing. In the chart here, what you see is an estimated bandwidth that is less than what the available bandwidth is. The yellow areas indicate exactly where you could have used more bandwidth to send our data or receive our data, especially video. So what happened is that this is a missed opportunity. We have more bandwidth than we've estimated, which means that we can send more bitrate, which means that we can have a higher video quality. So this is a missed opportunity. By estimating less than what is available, we're inefficient here. What happens if the opposite is what's occurring? We're overestimating the bandwidth that we have. In this case, this is detrimental. Okay. The red areas indicate areas where we think there is more bandwidth than there really is. So we're going to send more, more data. We're going to try and encode more in the bitrate or receive more within the network, but we don't have the capacity in the network for that. And the result is going to be packet losses and latencies. These packet losses immediately indicate that there is going to be poor video quality. And we're going to also oscillate if the estimation algorithm that we have is not good enough, which means that we're going to estimate too much, get into packet losses, then drop the bitrate or the bandwidth estimation, get to a point where we're estimating too little. Again, lost opportunity of being able to use more of the network, and we're going to go back to our estimation gaze. So we're going to oscillate from too low to too high. So what is it that we exactly want? We want to estimate as close as possible to the available bandwidth to the actual bandwidth. That we have, and we need to do it dynamically across the session. We want to estimate in a way that doesn't overshoot or overestimate the available bandwidth so that we use the network in a very efficient way and without causing any issues to our media. If you want to learn more, check out testrtc.com for testing and monitoring your WebRTC applications. Your you can check your bandwidth estimation, for example there and webrtccourse.com we can learn more about WebRTC itself. Thank you.
