[jitsi-dev] Videobridge negotiating artificially low bandwidth


#1

Hello,

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!

Thanks,
Luke
Luke
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)


#2

Hey Luke,

In short, none of the termination fully make sense without simulcast,
so you should only use pass through until simulcast stabilizes (which
should be this week).

Emil

···

On Tue, Dec 8, 2015 at 7:44 AM, Luke Evans <luke.evans@readytalk.com> wrote:

Hello,

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!

Thanks,
Luke
Luke
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.

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
https://jitsi.org


#3

Hi Luke,

ditto what Emil said; but your observations might indicate a problem
with the RTCP termination, because normally you should observe better
bandwidth estimations with termination enabled. Which JVB version are
you using? If it's not the latest one, please try again with that. Could
you also please share your sip-communicator.properties file with us?

If you think that you've setup everything correctly, and still you
experience problems, could you please capture a decrypted packet dump +
the graphs and share everything with us so that we can have a better
look at what's going on? You can send the dumps to my personal address
if you don't want them to be publicly available.

I hope this helps.

Best,
George

···

On Tue, Dec 08, 2015 at 05:04:40PM +1100, Emil Ivov wrote:

Hey Luke,

In short, none of the termination fully make sense without simulcast,
so you should only use pass through until simulcast stabilizes (which
should be this week).

Emil

On Tue, Dec 8, 2015 at 7:44 AM, Luke Evans <luke.evans@readytalk.com> wrote:
> Hello,
>
> 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!
>
> Thanks,
> Luke
> Luke
> 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.
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev

--
https://jitsi.org

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev