I have been doing some testing with these settings and it looks like there is no “easy button” for what I wanting to do.
Obviously, the best approach would be to have smoothing and FEC enabled in the tunnel, but then the DSL link becomes saturated and starts dropping packets. The excessive packet loss/congestion causes an unpleasant user experience.
So, the DSL link is the “weak” spot for throughput. To mitigate this, I am going to limit what all traffic can go down the tunnel. Rather than all UDP from that source address, I will only send the game data through the tunnel. Discord chat can go directly to WAN. So two outbound policies – one for UDP 50K-60K (game data) and the other for 37K to 40K (discord chat).
Now that I have offloaded some data out of the tunnel, I can enable wan smoothing to Normal. Without WAN smoothing – it looks like the tunnel is using packet based round robin – which results in the LAST packet making it to the speed fusion hub is what is forwarded.
My current setup is for the tunnel to include all 3 WAN links, with Normal WAN Smoothing, No FEC, set with the default “bonding”, maximum level on the same link is off, and I am using TCP for the data port.
The StarLink connection suffers from lots of packet loss on the uplink. I switched from UDP to TCP to try to mitigate this. I have seen better results for TCP flows opposed to UDP flows. I think the built in retransmissions will keep data from dropping out of the data stream. The game data is a UDP stream, so the TCP encapsulation to the SFC is worth the additional overhead (I think).
So, in summary – WAN smoothing is a requirement for what we are wanting to accomplish. WAN Smoothing increases the bandwidth used which can cause congestion on low throughput links. Very specific isolation of the gaming traffic is required to keep the overall usage of the DSL link low.
The end result (as best I can tell thus far) is that the maximum latency should ALWAYS be the DSL line - which is typically around 60-70ms. But, there are two chances for a packet to make it there in less time - one on the microwave link (20-30ms), and one on the StarLink (40-60ms). During non-peak hours, the fastest route will be the microwave link, and then every now and again the StarLink will be the fastest; and during times of local LAN usage - the DSL link will be the path that gets it there the quickest.
Now, after setting all of this up and testing it – I got to my computer this morning and sometime during the night - the StarLink WAN link was removed from the tunnel. The UI indicated that “no data was received” (or something like that). I had to manually disconnect/reconnect the WAN to get it to rejoin the tunnel. Anyone know what that is all about? The even log didn’t even pick up on the fact it was removed from the tunnel…
Thanks for taking this journey with me. I hope you brought snacks to share with the group