We have some questions around termination strategies on the videobridge. Specifically, we're seeing the bridge negotiate low send bandwidths (< 100K) even in good network conditions.
If we set the bridge to use the Passthrough termination strategy and let the RTCP packets go from Chrome to Chrome, we see significantly better perfromance than with the Basic Termination strategy (on 3 wired connections with plenty of bandwidth)
One of our current theories is that something is tripping the overuse detector. We see the detector report "overuse" followed by a huge backoff of bandwidth and multiple repots of "underuse" as queues empty. However the detector doesn't go back to reporting "normal", and the senders get stuck in the "hold" state at a very low send rate. We're currently looking into a couple of potential causes:
- The timing of the overuse calculations. Would running this calculation more frequently than .5s lead to more accurate data?
- Tuning issues. Are there values that can be chaged that will limit how much to backoff on bandwidth in the event of an overuse detection (or how quickly to ramp back up)?
We've also been following the simulcast commits over the last week or so, and our suspicion is that the Basic strategy might be focused on use-cases where simulcast is turned on. Can anyone confirm this?
I’ve attached a graph that shows the discrepancy between what the receivers report about their available bandwidth and what the bridge tells them they can transmit.
Basically we just want to know if anyone is seeing similar behavior and if there are any immediate plans to fix this? We'd also be very interested in knowing if there's anything we can do to help here.
Any input would be greatly appreciated!
This email message is for the sole use of the intended recipient(s) and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. Any unauthorized review, use, copying, disclosure or dissemination is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
Foxden_Performance.pdf (78 KB)