SRT 1.5 bonding or is it just seamless fail over

Hi, I have been testing real work preformance and use of SRT 1.5 bonding.
I can successfully implemement both "broadcast"and "Backup" modes.
However when testing a 20Mbit/s CBR mux stream with 3x 8Mbit/s connections in the group, the stream fails. This is under broadcast mode. If I increase 1 of the WAN connections to say 25Mbit/s, then all is ok and stats suggest this link is utilised.

I confirm that with 2 or more >20Mb/s connections, seamless failover can be obtained under broadcast mode.
Where you can intentionally interupt/bandwidth limit the 1 WAN link at a time and it will seamlessely failover with zero impact.

So is SRT bonding(broadcast mode) actual aggregate bonding, where 3x 8Mb/s WAN links can allow you to send a 20Mb/s service? The real world testing here suggests its not possible and its really just seamless failover.

Before I investigate if I have a config issue, can someone please explain the true expectation.

Many thanks

Hello, Will.

No, that's link aggregation, no load balancing. Each link has to be at least equal to the stream's bitrate (plus some control overhead on one of the single links).
It basically sends equal streams by all interfaces participating in bonding.

Please also refer to https://github.com/Haivision/srt/blob/master/docs/features/bonding-quick-start.md

Thank you for your feedback.

Very good and this makes sense to the findings here.

The stats page in WMS also shows concurrent sends with only one send not being discarded on the drop packet counter. Although was not sure if there were some additional aggregation smarts down stream, which would make a dramatic difference between the two modes - broadcast and backup.

The issue is there are some other SRT 1.5 forums out there that have diagrams that show link aggregation for SRT bonding, sadly people use bonding and aggregation terms loosely, which cloud expectation!
The diagram I refer to would be more suited for OpenMPTCP.

I see in SRT bonding backup mode one link is primary, while the others are idle and awaiting failover. Although not as seamless as broadcast mode in practice.

Thanks for your quick reply, I will stop thinking there is a problem with my setup.