upstream support for adding/removing subflow

[nsdyoshi]

Hi,
As far as I've check the code, I think the current code doesn't support features to add or remove subflows on upstream code.
It would also be great if we can support ndiffport style subflow creation for upstream versions

[ossama-othman]

Draft support for addition and removal of subflows is available in pull request #199. Testing is still in progress.

[nsdyoshi]

Thanks for the updates. In order to use this feature, do we need to apply https://lore.kernel.org/mptcp/[email protected]/T/#t to the kernel code?

[ossama-othman]

To make sure I understand, are you seeking to create and remove subflows through user space based path management? If so, you would need those kernel patches. Otherwise, you could leverage the existing in-kernel path manager to create subflows. From <mptcpd/path_manager.h>:

/**
 * @brief Advertise new network address to peers.
 *
 * @param[in] pm    The mptcpd path manager object.
 * @param[in] addr  Local IP address and port to be advertised
 *                  through the MPTCP protocol @c ADD_ADDR
 *                  option.  The port is optional, and is
 *                  ignored if it is zero.
 * @param[in] id    MPTCP local address ID.
 * @param[in] flags Bitset of MPTCP flags associated with the network
 *                  address, e.g. @c MPTCPD_ADDR_FLAG_SUBFLOW @c |
 *                   @c MPTCPD_ADDR_FLAG_BACKUP.  Optional for
 *                  upstream kernel (e.g. set to zero).
 * @param[in] index Network interface index.  Optional for upstream
 *                  Linux kernel (e.g. set to zero).
 *
 * @return @c 0 if operation was successful. @c errno otherwise.
 */
MPTCPD_API int mptcpd_kpm_add_addr(struct mptcpd_pm *pm,
                                   struct sockaddr const *addr,
                                   mptcpd_aid_t id,
                                   mptcpd_flags_t flags,
                                   int index);

Related information is available in the ip-mptcp(8) man page.

[nsdyoshi]

Thanks for the comment. Yes, that's what I want. It seems to me that there's less flexibility for path management in upstream kernel. So, I'm interested in implementing it in userland.

[matttbe]

Hi @nsdyoshi

Please note that the patches you mentioned depend on another series: https://patchwork.kernel.org/project/mptcp/list/?series=610910&state=7

The patches are going in the right direction but they will be modified after having rework how the listening sockets are handled, see: https://patchwork.kernel.org/project/mptcp/list/?series=617636

(discussions are still in progress)

[nsdyoshi]

Thanks @matttbe. Thanks for the info.
I also tried the approach that uses mptcpd_kpm_add_addr(), but this doesn't work on my upstream kernel.
It seems that we need to implement upstream_cmd_announce() so that we can have a new destination address to create a subflow. Please let me know if I miss something.

[ossama-othman]

I also tried the approach that uses mptcpd_kpm_add_addr(), but this doesn't work on my upstream kernel. It seems that we need to implement upstream_cmd_announce() so that we can have a new destination address to create a subflow. Please let me know if I miss something.

Assuming a subflow is not created, you may need to update the subflow limits through mptcpd_kpm_set_limits(). See the addr_adv_new_local_address() function in the mptcpd addr_adv plugin for an example.

The subflow limits for the in-kernel path manager may also be updated on the command line, e.g.:

$ sudo ip mptcp limits set subflow 3

[nsdyoshi]

Hi @ossama-othman, thanks for the comments.
I tried mptcpd_kpm_set_limits(), but it didn't work.
In my understanding, in order to create a subflow with upstream kernel, we need to have more than 1 IP address on both sides. Also, one side needs to signal the address so that the other side can have the destination IP for a subflow.
Because of this, without processing signaled addresses from the peer (I guess by using upstream_cmd_announce()), I am guessing we cannot create a subflow.

[vandit86]

Hello,
I have a similar question.. As I see , the current version of mptcpd v.0.10 does not allow to create or remove subflows on upstream kernel. There is no MPTCP_CMD_SUB_CREATE, MPTCP_CMD_SUB_DESTROY command in mptcp_upstream.h ..
Now, the support for the user space MPTCP path manager was added in the latest 5.19 kernel release. So I'm bit confused, on the best way to control subflows with upstream kernel..

[ossama-othman]

@vandit86: Support for those user space path management netlink subflow commands was added in pull request #199, which was merged to the master branch yesterday. If you get a chance please pull the code and give it a try. We're expecting to cut a major release of mptcpd with these changes in September, with possibly another minor release before then.

[vandit86]

@vandit86: Support for those user space path management netlink subflow commands was added in pull request #199, which was merged to the master branch yesterday. If you get a chance please pull the code and give it a try. We're expecting to cut a major release of mptcpd with these changes in September, with possibly another minor release before then.

@ossama-othman I'ts a very good news =) I'll try to compile and test ..

[ossama-othman]

@vandit86 I appreciate that. The code could definitely use more testing. Thanks!

[ossama-othman]

The set_backup command (see #237) is still unimplemented but it should be done soon.

[ossama-othman]

set_backup is now implemented in #254.

[vandit86]

Hello,
All the new commands work well in my emulation setup. 👍

[ossama-othman]

That's great news! Any objections to closing this issue?

[ossama-othman]

Fixed by #199.

[vandit86]

@ossama-othman,
could you please explain briefly what mptcpd_pm_remove_subflow should do?
Should it send some info (flag) to the peer, or just remove the selected subflow from the internal kernel subflow list??
I didn't notice any changes in the data flow when trying to remove subflow from the plugin.
the mptcpd_pm_add_subflow and mptcpd_pm_set_backup functions acts as expected.