Octo with SplitBridgeSelectionStrategy, probability

kkd · February 6, 2022, 2:34pm

I am studying possibility of increasing number of participants to say 300 per conference. I understand that I must use SplitBridgeSelectionStrategy.
All users are in same region, and I will have only one shard serving only one conference at any given time. Any suggestions how to go about it?

I really don’t understand what is meaning of probability?

github.com

jitsi/jitsi-videobridge/blob/master/doc/octo.md#jitsi-meet-configuration

# Setting up Octo (cascaded bridges)

## Jitsi Videobridge
Add these properties to `/etc/jitsi/videobridge/sip-communicator.properties` to
enable support for Octo:
```
# the address to bind to locally
org.jitsi.videobridge.octo.BIND_ADDRESS=10.0.0.1
# the address to advertise (in case BIND_ADDRESS is not accessible)
org.jitsi.videobridge.octo.PUBLIC_ADDRESS=1.2.3.4
# the port to bind to
org.jitsi.videobridge.octo.BIND_PORT=4096
# the region that the jitsi-videobridge instance is in
org.jitsi.videobridge.REGION=region1
```

You need to make sure that all of the bridges can communicate via the socket
addresses described in the properties above, and that the network is secure.

## Jicofo configuration

This file has been truncated. show original

Freddie · February 6, 2022, 2:55pm

Isn’t this already possible with the introduction of the pagination feature? AFAIK, the default deployment now supports up to 500 participants per conference, assuming the underlying infrastructure is sufficient, of course. In which case, Octo is not necessary if it’s just for the sole purpose of hosting that number of participants on a call.

kkd · February 6, 2022, 3:00pm

Thanks Freddie for quick response. If you are right then I don’t need to do anything. In any case as next step, I will try test my single server with Jitsi torture with selenium grid.

Freddie · February 6, 2022, 3:01pm

Yes, you shouldn’t have to do anything extra for your intended use case. Run a torture test as planned to confirm your deployment is able to support the load. Other than that, I believe you’ll be fine.

damencho · February 6, 2022, 6:05pm

What you can do is have multiple bridges in the region and octo configured and use

github.com

jitsi/jicofo/blob/daabcd941eb529314196042a39f9c258a7e70e17/src/main/resources/reference.conf#L40

      
        
            participant-rampup-interval = 20 seconds
            // The stress level above which a bridge is considered overstressed.
            stress-threshold = 0.8
            // The amount of to wait before retrying using a failed bridge.
            failure-reset-threshold = 1 minute
            // The bridge selection strategy. The built-in strategies are:
            // SingleBridgeSelectionStrategy: Use the least loaded bridge, do not split a conference between bridges (Octo).
            // SplitBridgeSelectionStrategy: Use a separate bridge for each participant (for testing).
            // RegionBasedBridgeSelectionStrategy: Attempt to put each participant in a bridge in their local region (i.e. use
            //    Octo for geo-location).
            // IntraRegionBridgeSelectionStrategy: Use additional bridges when a bridge becomes overloaded (i.e. use Octo for
            //    load balancing).
            //
            // Additionally, you can use the fully qualified class name for custom BridgeSelectionStrategy implementations.
            selection-strategy = SingleBridgeSelectionStrategy
            health-checks {
              // Whether jicofo should perform periodic health checks to the connected bridges.
              enabled = true
              // The interval at which to perform health checks.
              interval = 10 seconds
              // When a health checks times out, jicofo will retry and only consider it fail after the retry fails. This

To add new bridge in the conference if the one used is becoming overloaded.

To calculate overload with machine specs you use though you need some experiments. Need to monitor the bridge rtp delay stats and rtp packet rate and find the values for the vms you use.

github.com

jitsi/jitsi-videobridge/blob/e4ae71b9897f26a637843b676ba4136827f2ee08/jvb/src/main/resources/reference.conf#L172

      
        
              #   100pps for low-definition and 50pps for audio, this queue is fed
              #   650pps, so its size in terms of millis is 1024/650*1000 ~= 1575ms.
              send-queue-size=1024
            }
            load-management {
              # Whether or not the reducer will be enabled to take actions to mitigate load
              reducer-enabled = false
              load-measurements {
                packet-rate {
                  # The packet rate at which we'll consider the bridge overloaded
                  load-threshold = 50000
                  # The packet rate at which we'll consider the bridge 'underloaded' enough
                  # to start recovery
                  recovery-threshold = 40000
                }
              }
              load-reducers {
                last-n {
                  # The factor by which we'll reduce the current last-n when trying to reduce load
                  reduction-scale = .75
                  # The factor by which we'll increase the current last-n when trying to recover

kkd · February 7, 2022, 7:18am

Thank you. Is there a way I can split traffic on 2 video bridges without actually checking load. I tried with both vb marked as region1 with splitBridgeSelection but all traffic is routed only to one bridge.

kkd · February 7, 2022, 12:43pm

Thank you everyone. I have managed to use splitBridgeSelection.
Although I have only one JMS + 2 jvbs ( which i marked as region1 & region2 )
Can it be used in production? Are there any downside?
I see some users connected to region1, some region 2 and some region2 from region1. What does region2 from region1 means?
I also tested IntraRegionBridgeSelectionStrategy with stress-threshold = xx which seems to work.

jbg · February 8, 2022, 4:50am

SplitBridgeSelectionStrategy is mostly for testing, it tries to spreads participants across many bridges without regard to region. You use it to test Octo easily even if you only have participants in one region. It isn’t appropriate for production use.

If you want to spread participants across multiple bridges within in a single region then use IntraRegion.

If you want to spread participants across multiple bridges in multiple regions, so that each participant connects to their nearest bridge, use RegionBased. For this you need to ensure you have secure, very good quality connectivity between the regions.

If neither of those suit then you can implement your own BridgeSelectionStrategy.