search

zehome / MLVPN

Multi-link VPN (ADSL/SDSL/xDSL/Network aggregation / bonding)
http://www.mlvpn.fr/
BSD 2-Clause "Simplified" License
521 stars 129 forks source link

Q about use case for latency sensitive gaming over UDP #140

Closed Strykar closed 3 years ago

Strykar commented 3 years ago

My games uses two UDP ports. I expect to use MLVPN exclusively when gaming, with no encryption.

I have two ISPs, one is wired, 50 Mbit symmetric up/down fiber, the other is 4G with high latency. My current failover setup (bash script, ping test, no aggregation) takes 3 to 5 seconds to move ISPs in case one goes down.

Would I experience faster failover with MLVPN, I'm unclear how seamless this would be? Is there an advantage for my use-case with MLVPN?

Thank you!

markfoodyburton commented 3 years ago

The 'timeout' config variable can be used to determine how long to wait till a link is marked failed. You'll see that by default this is 30 seconds.

I worked hard on failover. Its really not an easy problem to crack and also depends on what you mean by 'fail'. I have a similar setup as you, for me, I see links 'stall' rather than 'fail' as the physical link dies, but the link between the MLVPN client and the modem remains up.

This can be detected using RRT measurements in MLVPN but for me, I never got MLVPN to perform too well on failover. HOWEVER,I know @zehome has put some work in recently - so thinks may be better now.

I tried a different approach, where I detect failed packets on the receiver and re-request them on a different tunnel (and, in so doing, downgrade the erroneous tunnel). For me, I am happy with the results, but my fork is not as complete as MLVPN and doesn't support some of the features (notably I broke openBSD etc). You can find it here, https://github.com/markfoodyburton/ubond, if it helps.

ghost commented 3 years ago

The 'timeout' config variable can be used to determine how long to wait till a link is marked failed. You'll see that by default this is 30 seconds.

I worked hard on failover. Its really not an easy problem to crack and also depends on what you mean by 'fail'. I have a similar setup as you, for me, I see links 'stall' rather than 'fail' as the physical link dies, but the link between the MLVPN client and the modem remains up.

This can be detected using RRT measurements in MLVPN but for me, I never got MLVPN to perform too well on failover. HOWEVER,I know @zehome has put some work in recently - so thinks may be better now.

I tried a different approach, where I detect failed packets on the receiver and re-request them on a different tunnel (and, in so doing, downgrade the erroneous tunnel). For me, I am happy with the results, but my fork is not as complete as MLVPN and doesn't support some of the features (notably I broke openBSD etc). You can find it here, https://github.com/markfoodyburton/ubond, if it helps.

Hello, I've been closely following your progress on the issue pages and I'm interested in replicating your setup. Can you kindly post your configuration? Should I follow MLVPN's docs with your fork?

Good work and thank you.

markfoodyburton commented 3 years ago

Yes, mostly the setup is the same as for MLVPN, but this issue should be on ubond, not MLVPN.