MPTCP (RFC 8684) support

Product Discussion Feature Requests
, ,
1

It’d be great if the router could at least let clients make MPTCP connections (RFC 8684). Apple’s OS supports and uses MPTCP (for Siri notably).

And it would be beyond amazing if an outbound policy could upgrade TCP connections to MPTCP. :slight_smile:

2

So I’m not convinced this would work like this (please correct me if I am wrong though). MPTCP supported on Apple devices means it (creating the session) would be able to use the wifi connection to the peplink and one of the links to make an MPTCP session to a remote host along with the cellular connection (if the remote also supports this should work now).
For outbound policy to allow MPTCP it would need to proxy your connection to make the session with the remote on your behalf, meaning it would be encapsulating the traffic to a remote peer which can remove the encapsulation, this is essentially what speedfusion does, it creates a tunnel over multiple links, and all sessions (TCP, UDP etc) are passed over them. The actual TCP session though is between the source and destination, it isn’t affected as the encapsulation happens in the middle so is added and removed so the endpoints don’t see it.
MPTCP on openwrt (openmptcp) does exactly this in that it creates a TCP openvpn tunnel to a remote server and that TCP session is over MPTCP so it can bond links. The traffic from devices then gets encapsulated over the openvpn tunnel and thus bonded.

3

I’m talking about two different approaches to MPTCP and you’re talking about a third. Those three approaches are:

  1. Basic NAT support (support Siri, etc).
  2. Upgrading naive TCP sessions to MPTCP.
  3. Load-balanced tunneling.

What you’re talking about is the last one.

To me the most important support is the first one. And to the best of my knowledge, the NAT engine would need to implement some (all?) of the MPTCP state engine and replace the client’s endpoints with the NAT router’s endpoints. Hopefully it’s not too much work.

And on second thought, I think #2 might be better implemented as an option on existing dynamically balanced outbound policies (i.e. not weighted balance etc that are statically balanced).

4

  1. I expected that mptcp packets would be NAT’d without issue, as the mptcp part is just in the header and that would be passed through.

  2. I don’t know how this could work, the TCP session is between the 2 end devices, the router even with NAT plays no part in this session except for passing it, to “upgrade it” it would need to encapsulate it and pass it to another end point which removes the encapsulation before it gets to the end point.

  3. I believe this is the only way 2 works

5

Just to add to 1, I expect it would pass the packet on a single interface, the mptcp subflow data would be untouched by nat (it only changes source address, and port) the client device will still be able to use cellular with wifi if the other end also supports mptcp.
If you mean for 1. to be able to use the multiple connections of the peplink router then that would need the peplink to proxy the session, which I can’t see being an easy task.

Would be something like this