<cransom>
those patches are supposed to land upstream at some point too (mptcp)
<hexa->
steveeJ: yeah, but with that kind of setup you basically tunnel all your traffic through a SPOF remote server
<hexa->
so your failover goes boom to some degree
<sphalerite>
haven't they already landed upstream?
<hexa->
they were pretty close last I looked
<hexa->
anyway, a pretty simple solution could be based on the `weight`attribute on your two default routes
<hexa->
but you'd probably want something more elaborate, like sending the same flow always the same way etc. :D
<hexa->
I guess I'd try out mptcp first
<cransom>
mptcp only works though if the end point is also mptcp aware. if you were to tcp proxy all your traffic somewhere though that was faster than your uplinks, that works. i was reading that was how the super dense korean markets provide crazy high speed devices, balancing wifi+cellular traffic through socks proxies
<cransom>
siri uses it, which is also interesting.
<gchristensen>
whoa cool
<steveeJ>
cransom: so for generic use you'd need a proxy similar to the architecture shown on the mlvpn example?
<cransom>
yes, you'd need another machine upstream that you control. each likely has trade offs for their specific magic.
<cransom>
doing link load balancing on a home/small office setup is more cumbersome than if you were to have business providers that would chat bgp with you, have your own subnet, etc. soho requires lots of bandaids.
<hexa->
true
<teto>
you can check openmptcprouter.com for some explanation. I've written https://github.com/teto/mptcpanalyzer to help with traffic analysis (can be hard otherwise)
<steveeJ>
teto: can you outline what's currently working with linuxPackages_latest on 20.09?
<teto>
steveeJ I haven't followed what was released recently, MPTCP has been available for single path (sic) for quite some time, I am not sure the support for multiple paths has been merged yet. It's something I want to look into to updat https://github.com/NixOS/nixpkgs/pull/59342 but I've beenbusy lately