This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
software:mptcp [2022/07/26 07:38] – [What is this?] chris | software:mptcp [2024/03/03 11:37] (current) – chris | ||
---|---|---|---|
Line 1: | Line 1: | ||
+ | ===== What is this? ===== | ||
+ | I [[https:// | ||
+ | * [[https:// | ||
+ | * [[https:// | ||
+ | * [[https:// | ||
+ | * [[https:// | ||
+ | * [[https:// | ||
+ | * Besides QUIC (protocol ontop if UDP, includes TLS1.3), [[https:// | ||
+ | * Seems like [[https:// | ||
+ | * A [[https:// | ||
+ | |||
+ | ===== Other protocols which can be considered ===== | ||
+ | Depending on the goal, also other protocols besides MPTCP can be considered: | ||
+ | |||
+ | * SMB3 support multiple streams, of could quite pinned down to just file sharing | ||
+ | * QUIC: It's a next level protocol, and the spec includes that it can survive IP changes. | ||
+ | * con: as I see it, combining throughput of multiple media is not possible, just switching | ||
+ | * con: the involved client/ | ||
+ | |||
+ | ===== Scenario: laptop switching between ethernet/ | ||
+ | Considering here the several ways for that scenario: I have a laptop from which I access the internet, and I want to freely move that laptop between ethernet and wifi, without applications noticing. So this solution considers a further system (laptop, raspi etc.) on your LAN, as helper. The ways below are so far mostly theoretical and should be tried out one by one (please beat me in trying them before I find the time ;). | ||
+ | |||
+ | The 'real world' scenario from the article linked above has already a part of this setup, but **a)** it is just terminating the network connections on the other laptop, in real world one wants to connect to plain TCP servers on the internet. Having the MPTCP endpoint doing NAT could help. **b)** we still need to make all applications on the mobile laptop MPTCP capable, i.e. with ' | ||
+ | |||
+ | So ideally, below options get researched, and easy to use howto gets created. From the below approaches, the first one is recommended as it enables MPTCP usage in the most transparent way for applications. The bonding approach is also nice and needs no helper system on the internet. | ||
+ | |||
+ | Collection of some approaches. ' | ||
+ | |||
+ | - **Use MPTCP, and shadowsocks** | ||
+ | * [[https:// | ||
+ | * pro: Running shadowsocks as transparent proxy enables applications opening normal TCP connections, | ||
+ | * con: One needs 2 helper systems which span up the MPTCP connection. | ||
+ | * con: shadowsocks is not packaged in many Linux distros, consider to use https:// | ||
+ | - **Using classic bonding** | ||
+ | * I tried this approach out. You likely won't be able to use bond modes which combine bandwidth, and you are probably pinned down to Linux on both systems. | ||
+ | * pro: easy to setup, as plain TCP/UDP can run over the bond | ||
+ | * con: you need control over link layer of both systems, for all of the underlying media (i.e. wireless, ethernet) | ||
+ | * con: works just with devices speaking the bonding dialect, i.e. 2 Linux devices. | ||
+ | - **Span VPN with Tailscale** | ||
+ | * I tried this approach out. Tailscale is for this purpose a really bad choice, because it's designed to have at all times a working upstream route to the Tailscale servers on the internet. | ||
+ | * pro: tailscale does failover to other underlying media (wifi) after 5sec | ||
+ | * con: Tailscale can not combine multiple media for throughput | ||
+ | * con: a TCP socket over the Tailscale connection stays open/up when the underlying media gets unavailable, | ||
+ | - **Span VPN with Nebula** | ||
+ | * I tried this approach out. Nebula is for this purpose a really bad choice, because it's designed to have at all times a working upstream route to the lighthouse system on the internet, for our scenario that is not always the case. To solve that, maybe you can run the companion system on your LAN as lighthouse.. but then still all the other downsides stay. | ||
+ | * pro: nebula does failover to other underlying media (wifi) after 15sec | ||
+ | * con: a TCP socket over the Nebula connection stays open/up when the underlying media gets unavailable, | ||
+ | * con: Nebula is not combining the bandwidth of multiple available underlying media | ||
+ | - **Use MPTCP, and mptcpize an OpenVPN, which by itself is spanning up a VPN where your applications route to** | ||
+ | * I tried this approach out, did not get it to work: OpenVPN can be mptcp' | ||
+ | * pro: the applications themself would then just do normal routing into the tunnel | ||
+ | * con: I did not get multiple subflows utilized, with TCP traffic over the OpenVPN tunnel. Only when I MPTCP' | ||
+ | - **Use MPTCP, and use systemtap** | ||
+ | * This is quite similar to wrapping ' | ||
+ | * pro/con: all created TCP sockets will then become MPTCP sockets. Transparent for the ones you want to route to the internet, but also 'ssh localhost' | ||
+ | - **Use [[https:// | ||
+ | * Thanks to Saulius Krasuckas for the hint | ||
+ | * ' | ||
+ | |||
+ | ===== Scenario: multiple internet uplinks ===== | ||
+ | So with this scenario, we have a home with multiple uplinks to the internet, let's say fiber and 5G. MPTCP or something else would then help to combine throughput of both, and to survive one of the uplinks breaking down. For this scenario, we will need one system on the LAN (might be the router) running i.e. MPTCP, and a counterpart on the internet. |