Userspace PM doesn't have access to allow_join_id0 / allow_join_initial_addr_port bit from the SYN-ACK

[majek]

Pre-requisites

• A similar idea has not been reported before.
• mptcp.dev website does not cover my case.
• The wiki doesn't cover my case.

Description

I'm pondering about writing an userspace Path Manager - for an MPTCP client case.

The server can report addresses in two ways:

• via ADD-ADDR - this is properly reported to userspace PM as a netlink message type 6
• via cleared "Do not attempt to establish new subflows to this address and port" flag on initial SYN-ACK

Typically, the "Do not attempt to establish new subflows to this address and port" flag is set, so a naive userspace PM can assume this. But this seems wrong. The "Do not attempt to establish new subflows to this address and port" flag is set as part of struct mptcp_subflow_request_sock allow_join_id0 member. Unless I read the code wrong, this struct is not passed to the netlink code that generates connected/established events.

I think access to this flag is necessary for any sane userspace PM. Unless I got something wrong and there maybe is a way to read it?

Marek

Solution

I guess another new netlink attribute on created/established message?

Considered alternatives

An alternative would be for userspace PM to do some kind of ss query and ping the socket state. But again - I don't think this is going to report much. The extreme hack would be to steal socket from userspace and query its state with MPTCP_FULL_INFO. (does this struct have info on whether server allowed the server address pair reuse?)

Additional context

No response

[matttbe]

Hi @majek,

Thank you for having reported this!

Typically, the "Do not attempt to establish new subflows to this address and port" flag is set, so a naive userspace PM can assume this.

(By default, servers allow new subflow to the same address and port, but I guess in your case, the servers set net.mptcp.allow_join_initial_addr_port, which probably makes sense in your case, for load balancing reasons I suppose)

I think access to this flag is necessary for any sane userspace PM.

Indeed, we missed that one for the userspace PM. (To be precise, the Netlink events were designed before the MPTCPv1 specs, and this flag was not in the v0 :) )

This info should be added in the CREATED and/or ESTABLISHED event I suppose, and it needs to expose msk->pm.remote_deny_join_id0.

Because you looked at the code, do you also plan to do this kind of modification?

[majek]

Does it need some specific new netlink message type?

[matttbe]

Does it need some specific new netlink message type?

By the look of it, another attribute should be exposed. Thinking about that, the MPTCP_ATTR_SERVER_SIDE attribute should have probably been a bit-field where we could have set server-side, but also deny-join-id0. I guess it is too late to change.

But then the new attribute should probably be flag not to re-do the same mistake. (We could deprecate MPTCP_ATTR_SERVER_SIDE and add the info in flag where the first bit could be server-side, and the second one deny-join-id0)