PM: create new subflow after one got closed

[matttbe]

It looks interesting to have the in-kernel PM checking if we need to create a new subflow once one has been closed.

A few reasons for that:

• maybe other subflows didn't get created in the past because we were at the limit (subflows_max)
• maybe the subflow can be re-established if it has been closed due to an error, after a NAT timeout
• (maybe we want to retry later, e.g. we got a RST and we might want to retry later → maybe more something for the userspace PM?)

This has been discussed on the ML with @pabeni, see: https://lore.kernel.org/mptcp/d4be3022ec8e5087a1a336e9c487aa4d3b045dfb.camel@redhat.com/T/#mcedd98703c3280f107f94f86ef8925441fcc1ede

[pgreenland]

Follow on from initial discussion on the mailing list: Original Mailing List Email, see extract below covering issue description.

Our current use case for MPTCP is relative simple. We have a limited number of connections originating from a client embedded system, destined for a server on the internet. The client has multiple WAN links, which go up and down periodically with network conditions. We were hoping to largely transparently maintain a logical link to our server, utilising any and all links when available.

Currently when subflows fail, they aren't re-established, which given our use-case is pretty important.

While it may be better suited for the userspace path manager, a separate application would be overkill for our initial plan. A simple strategy in the kernel would be preferred Potentially with a configurable delay between reconnection attempted and max count.

A related issue we noticed with subflow creation, is that it appears that after the initial connection subflow creation is chained. With the successful creation of one subflow triggering the creation of the next. Until all available endpoints (or subflow limit) is reached. If the first subflow creation fails, no further attempts will be made.

For this problem re-connection attempts would be good, possibly combined with a big bang, all subflows established at once, rather than one at a time.

[matttbe]

This has been fixed in our export branch thanks to the modifications done by @pabeni:

• 7dff646: mptcp: fix per socket endpoint accounting

• b3b3136: mptcp: clean-up MPJ option writing

• 93ddc71: mptcp: keep track of local endpoint still available foreach msk

• b3adca8: mptcp: do not block subflows creation on errors

• 0f4945b: selftests: mptcp: add tests for subflow creation failure

  • 07368dd: selftests: mptcp: apply Mat's comment

• 1d0e64a: mptcp: cleanup MPJ subflow list handling

• Results: 8c25dcd..c94ca03

• bcccc44: mptcp: avoid atomic bit manipulation when possible

• Results: c85bd12..1fdc9db

@pgreenland do you mind checking this new version? Please re-open this ticket if you still have issues.