What we have so far
After lots of experiments, I figured out the way which enables the transparent MPTCP operation for both the client and the server (with the regular kernel).
I tested the configurations at my virtualized environment, check the video below. For configuration infos, please read the video description. (the post continues)
On the other track, I researched and experimented with the LEDE environment. Its basically all about RTFM, the documentation about building and working with patches are very straightforward. What was very difficult for me, is figuring out how can I create the MPTCP patches for the latest stable LEDE 17.01. After some experiments I succeeded with the following commands:
#Clone the latest stable branch (which is the v0.92 now, but check the latest version on GitHub) git clone mptcp_v0.92 https://github.com/multipath-tcp/mptcp.git #Set the vanilla mainline kernel as upstream git remote add upstream git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git #Fetch the commits and modifications from the upstream git fetch upstream #Merge it to a tag (this maybe differ, You can use the following command to list all possible tags: #git for-each-ref refs/tags | sed -r "s/.*refs\/tags\/(.*)/\1/" #You might need to resolve the conflict manually! git merge v4.4.74 #Make the diff file #Check LEDE patching docs for naming conventions git diff v4.4.74 mptcp_v0.92 > ~/690-mptcp_v0.92_e1243fb.patch #Copy the patch file to your LEDE patches folder cp ~/690-mptcp_v0.92_e1243fb.patch /home/USER/YOUR_LEDE_ROOTDIR/target/linux/generic/patches-4.4/
The results available in my LEDE fork on GitHub: https://github.com/spyff/lede-mptcp
I compiled that and tried out on my Netgear R7000 router: it works fine. If You want to try out, just clone the repo and follow the regular LEDE building guide, and enable the MPTCP support in the kernel menuconfig before the building.
What next
After some experiments a few problem surfaced. Two methods possible for getting the gains of the two paths at the client side:
1. Transparent SOCKS proxy.
The two router communicating on SOCKS protocol to setup and tear-down TCP connections. Works for UDP too. Many industrial strength application exists like redsocks. SOCKS6 will solve the additional delay with TCP fast-open but we lack implementation yet.
2. Transparent TCP redirector.
Simply terminate and redirect every TCP flow. Like ss-redir. No additional signaling overhead.
For this reason, I prefer ss-redir. Unfortunately, the mainstream version which is available in LEDE repo-s has required lots of computing resources: because of the encryption. Reimplementations in Go and Rust languages are available, but it’s unofficial and hard to compile to LEDE. In those versions the encryption is mandatory, we can able to turn it off. The regular ss-redir peak iperf3 throughput is 80 Mbps between the R7000 router and my notebook. Without ss-redir its about 750 Mbps. So there is two way to finish my work: using a router board with a stronger CPU or use SOCKS5 server approach. The unofficial solution might be fork ss-redir and disable the encryption in the source code.
I don’t know which approach will be the winner in performance but at least the software part of the work is promising.