[Question] Bi-directional MPTCP (signal endpoints on both ends)

[asirir]

Hello,

I have a simple setup where two hosts are connected through multiple network paths (multi-homed). Let's call these A and B. I have a client/server application where client is on host A and server on host B - both of these applications use MPTCP sockets. If I statically configure host B to advertise two signal endpoints (and configure appropriate limits on both hosts), everything work fine - I can see the client application establishing multiple subflows to the server application as expected.

However, my problem is, if I then introduce two signal endpoints to host A (i.e. where the client application reside), those subflows (described earlier) don't establish - tcpdump shows subflows being reset. The reason I want signal endpoints on both hosts is because my applications (client and server) can establish connections both ways - i.e. each application is both a client and a server - so I would like to use MPTCP working both ways.

Is this a known limitation and/or unsupported? I can provide more detailed information (how to reproduce) if necessary, at this point just wanna find out if I'm doing something trivially wrong. I'm on Ubuntu 22 (kernel: 5.15).

Many thanks!

[daire-byrne]

For what it's worth, I am actually using this setup in production. I found that the key is to get your routing in both directions right between the endpoints.

I am having some issues with this setup mind and it's not entirely clear if having signal endpoints on both hosts is "correct" or well tested. See #501 (comment) for my current issue.

[asirir]

Hi Daire,

That is interesting - I'll have a read through your issue. A moment ago I noted something interesting:

• If I announce N endpoints at each of the hosts and set my mptcp limits to subflow N add_addr_accepted N (again, at each host) - this issue manifests.
• If I announce N endpoints at each of the hosts and set my mptcp limits to subflow 2*N add_addr_accepted N - the issue does not manifest.

Discovered the latter mostly by luck, so I'm not even sure if this is a fix or some fluke. I'm going to run some more tests and verify things. If I have to deal with dropped subflows (at runtime, like in your issue), then that adds another layer of complexity on top of this :(

Cheers,

[asirir]

Closing this as I've found an answer to my original query.