Community discussions

MikroTik App
 
bronco
just joined
Topic Author
Posts: 16
Joined: Mon Dec 08, 2014 12:09 pm

Feature Request: Multipath TCP

Thu Mar 26, 2015 4:50 pm

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
 
User avatar
ZeroByte
Forum Guru
Forum Guru
Posts: 4051
Joined: Wed May 11, 2011 6:08 pm

Re: Feature Request: Multipath TCP

Thu Mar 26, 2015 5:02 pm

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.
When given a spoon,
you should not cling to your fork.
The soup will get cold.
 
bronco
just joined
Topic Author
Posts: 16
Joined: Mon Dec 08, 2014 12:09 pm

Re: Feature Request: Multipath TCP

Sun Apr 05, 2015 4:25 pm

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?
MPTCP handles TCP connections transparently, the application using the TCP stream doesn't even know that there's MPTCP working in the background. :)
... 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.
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! :D

Greets,
bronco
 
Zorro
Long time Member
Long time Member
Posts: 676
Joined: Wed Apr 16, 2014 2:43 pm

Re: Feature Request: Multipath TCP

Fri Apr 10, 2015 10:29 pm

its nicely working together with active queues.
also STCP variants support may be handy too.
 
User avatar
ZeroByte
Forum Guru
Forum Guru
Posts: 4051
Joined: Wed May 11, 2011 6:08 pm

Re: Feature Request: Multipath TCP

Fri Apr 10, 2015 11:28 pm

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! :D
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.
When given a spoon,
you should not cling to your fork.
The soup will get cold.
 
bronco
just joined
Topic Author
Posts: 16
Joined: Mon Dec 08, 2014 12:09 pm

Re: Feature Request: Multipath TCP

Fri Apr 10, 2015 11:58 pm

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.)
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... ;-)
 
User avatar
ZeroByte
Forum Guru
Forum Guru
Posts: 4051
Joined: Wed May 11, 2011 6:08 pm

Re: Feature Request: Multipath TCP

Sat Apr 11, 2015 1:23 am

I wonder which set is smaller:
MPTCP-enabled sites
IPv6-enabled sites

(probably the first one)
When given a spoon,
you should not cling to your fork.
The soup will get cold.
 
bronco
just joined
Topic Author
Posts: 16
Joined: Mon Dec 08, 2014 12:09 pm

Re: Feature Request: Multipath TCP

Sat Apr 11, 2015 11:37 am

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'...
 
f03nix
just joined
Posts: 1
Joined: Wed Dec 30, 2015 8:57 am

Re: Feature Request: Multipath TCP

Wed Dec 30, 2015 9:44 am

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.
 
Zorro
Long time Member
Long time Member
Posts: 676
Joined: Wed Apr 16, 2014 2:43 pm

Re: Feature Request: Multipath TCP

Thu Dec 31, 2015 1:24 am

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".
 
netflow
Frequent Visitor
Frequent Visitor
Posts: 85
Joined: Sat Oct 01, 2016 3:53 pm

Re: Feature Request: Multipath TCP

Sat Mar 11, 2017 3:17 pm

+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.
 
doctorrock
just joined
Posts: 20
Joined: Fri Mar 17, 2017 11:08 am

Re: Feature Request: Multipath TCP

Fri Mar 17, 2017 11:24 am

Just adding a +1 to say that I would be delighted to see MPTCP support added to RouterOS.
 
hkaiser
newbie
Posts: 41
Joined: Fri Feb 04, 2005 11:11 am

Re: Feature Request: Multipath TCP

Wed Feb 12, 2020 7:48 pm

Just also adding a +1 to say that I would be happy to see MPTCP support added to RouterOS.
 
MichaelDC
just joined
Posts: 5
Joined: Mon May 22, 2017 2:40 pm

Re: Feature Request: Multipath TCP

Sat May 23, 2020 9:34 pm

Just also adding a +1 as well to see MPTCP support added to RouterOS....please
 
alex32c
just joined
Posts: 15
Joined: Tue Apr 07, 2020 1:53 am

Re: Feature Request: Multipath TCP

Tue May 26, 2020 1:35 am

+1.
 
chaos74
just joined
Posts: 1
Joined: Mon Jul 20, 2020 3:14 pm

Re: Feature Request: Multipath TCP

Mon Jul 20, 2020 8:35 pm

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.
 
bronco
just joined
Topic Author
Posts: 16
Joined: Mon Dec 08, 2014 12:09 pm

Re: Feature Request: Multipath TCP

Wed Jul 29, 2020 12:53 am

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...

Who is online

Users browsing this forum: Baidu [Spider], mbethers and 130 guests