Hello,
is there a chance to add Multipath TCP according to RFC 6824 in a future version?
There is already a linux kernel refernce implementation available: see http://multipath-tcp.org/ and https://github.com/multipath-tcp 
Best regards,
bronco
MPTCP is pretty much an end-to-end technology. Is there anything in the specification that allows a NAT router to silently create multi-path TCP sessions to some remote host which supports it, but bond them back into a single vanilla TCP stream for clients?
I’ve thought that this would be an excellent “multiple ISP load balancing/failover” solution in the NAT-free world of IPv6.
The cool thing is, the Mikrotik wouldn’t even need to support MPTCP itself - so long as it can give two public prefixes to clients on the LAN. The clients themselves could negotiate the multiple connections using their two prefixes. The Mikrotik would just need to use route marking to force the public prefix1 via ISP1 and prefix2 via ISP2.
MPTCP handles TCP connections transparently, the application using the TCP stream doesn’t even know that there’s MPTCP working in the background.
One of the cool features of MPTCP is its dynamic behaviour - without any complexity in configuration. E.g. add two outbound connections via Ethernet and three LTE usb sticks and as long as each individual connection itself is configured correctly, MPTCP will do the rest including failover between links, bandwidth aggregation and so on. Cool stuff! 
Greets,
bronco
its nicely working together with active queues.
also STCP variants support may be handy too.
Are you sure?
Everything you mentioned would be true for connections originating from the Mikrotik itself - say if it is going to execute a fetch or maintain an ssh connection to a remote host.
Unless I’ve skimmed over it, the RFC says nothing about a middlebox participating in the task.
In fact, the RFC calls for cryptographic handshaking on each subflow to authenticate the endpoints, and uses tokens in order to be able to detect and penetrate a nat.
MPTCP is a layer 4 protcol, which is end-to-end.
What you’re thinking about is pretty much an entirely new thing which would use MPTCP as part of its solution - namely, that it would silently terminate a tcp socket locally in order to originate a new mptcp stream outbound, and then forward the data between the two sockets transparently.
In fact, the Mikrotik would be forced NOT to break into mp-capable handshakes going through it. (what if the internal host has another link that doesn’t go through the mikrotik, and it’s already started an MPTCP session- the 'tik won’t have the right cryptokey for adding/removing sub-flows.)
EDIT: Don’t take this post to mean that I’m against MPTCP - I think it’s awesome. I just don’t think this is how it works.
Yes, I agree with you - I’m thinking of some kind of “transparent MPTCP proxy”, so that the 'tik tries to establish MPTCP connections for internal hosts that are not capable of MPTCP. In case that some internal host would like to create a MPTCP connection by itself the 'tik would have to detect, that there’s already a MPTCP connection comming from an internal host an just let is pass accordingly to all other configuration options. I’ve not checked the RFC if this is fully possible… 
I wonder which set is smaller:
MPTCP-enabled sites
IPv6-enabled sites
(probably the first one)
You’re probably right, but I think the comparison doesn’t really match, since MPTCP’s goals are in parts different from IPv6’…
I second this request - having the support in router would be a huge benefit to anyone using a [mtcp supported] vpn with load balancing. With iOS and MacOS supporting it, and having patches available for the linux kernel - Mikrotik should add its support.
yep, it would be cool. even in separate(initially)package.
its not matured to 1.0 version yet, but even 0.9 code seems stable enough.
http://www.multipath-tcp.org/
and wiki as intro of course https://en.wikipedia.org/wiki/Multipath_TCP
aside initial-design aimed benefits - its also help combat some specific to RF link issues with TCP traffic, ie congestion combating aswell as simple/transparent/soft handover of TCP for mobile subscribers/consumers.
combined with HWMP or OLSR, cjdns - its may be quite interesting for new horizons of mesh networks and networking “in general”.
+1
The fact it is still fairy new is not a reason not to consider. RouterOS team is working hard to solve (all) stability, compatibility and performance issues. Adding top notch features will be the next logical step in order to gain traction in enterprise.
Just adding a +1 to say that I would be delighted to see MPTCP support added to RouterOS.
Just also adding a +1 to say that I would be happy to see MPTCP support added to RouterOS.
Just also adding a +1 as well to see MPTCP support added to RouterOS…please
+1.
It is very necessary to implement Multipath TCP to implement aggregation of two LTE channels in the router RBM33, the other router Mikrotik (hap ac2) will work as a server that aggregates the channels. This is a great solution for online broadcasting. Cheap replacement for LiveU.
Thank you chaos74, that was one of my intetions when starting this thread.
And MultipathTCP is of course not limited to LTE use only, you can use it for any kind of network media link.
Unfortunately it seems that nobody at MikroTik takes any feature requests seriously (as we can see e.g. in the OpenVPN thread).
Okay, we will wait for RouterOS v9 BETA, maybe something will show up then…
+1.
+1
(long term stream but that would be so nice to have…)
+1.