MPTCP Linux Development
 help / color / mirror / Atom feed
From: Mat Martineau <martineau@kernel.org>
To: "Matthieu Baerts (NGI0)" <matttbe@kernel.org>
Cc: mptcp@lists.linux.dev
Subject: Re: [PATCH RFC mptcp-net 7/7] mptcp: pm: nl: announce deny-join-id0 attribute
Date: Thu, 4 Sep 2025 17:54:16 -0700 (PDT)	[thread overview]
Message-ID: <c0361d0e-bbe8-d04b-2afd-4f27c3d30546@kernel.org> (raw)
In-Reply-To: <20250829-mptcp-pm-user-c-flag-v1-7-78b25dda7708@kernel.org>

On Fri, 29 Aug 2025, Matthieu Baerts (NGI0) wrote:

> During the connection establishment, a peer can tell the other that it
> cannot establish new subflows to the initial IP address and port by
> setting the 'C' flag [1]. Doing so makes sense when the sender is behind
> a strict NAT, operating behind a legacy Layer 4 load balancer, or using
> anycast IP address for example.
>
> When this 'C' flag is set, the path-managers must then not try to
> establish new subflow to the other peer's initial IP address and port.
> The in-kernel PM has access to this info, but the userspace PM didn't.
>
> When a new connection is created and established, the Netlink events
> will now contain a new deny-join-id0 attribute. When set to 1, it means
> no other subflow to the initial IP address and port -- which is part of
> the event -- can be established.
>
> Link: https://datatracker.ietf.org/doc/html/rfc8684#section-3.1-20.6 [1]
> Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/532
> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
> ---
> This patch is marked as an RFC, just so we can agree on the attribute
> type: should we use a new dedicated attribute, or start using flags? It
> even looks like we have defined a "flags" attribute, but it is currently
> not used. Using "flags" would allow us to save some bytes, and in this
> case, 'server-side' should have used "flags" too. The problem with the
> flags is that the userspace cannot tell if a new flag is unset because
> the kernel doesn't support it, or because it doesn't need to be set. But
> is it really an issue? If the kernel doesn't support it, the userspace
> will probably not know what to do anyway. So fine to use flags? Or not
> needed, because it is unlikely to add new attributes later on?
>
> If yes, I suggest:

Hi Matthieu -

I do prefer 'flags' for this. It is the "C flag" after all :)

> - switching 'flags' to u32 instead of u16 because it doesn't change
>  anything, and it is currently not used

There is already iproute2 code that references the 16-bit flags, even if 
it is just for 'ip mptcp monitor'. Better to not alter the existing 
userspace API here, especially in a -net patch.

> - deprecating the 'server-side' attribute, and adding it in the flags
>  (but keeping it for the moment, maybe we can remove it in a few
>  versions?)

Good idea, can duplicate the information between the server-side attribute 
and flag for now. Then update mptcpd to prefer the flag version and remove 
from the kernel sometime after that.

> - adding deny-join-id0 as a flag: MPTCP_PM_EVENT_FLAG_DENY_JOIN_ID0

Sounds like a good plan!


- Mat


> If no, we can use what is proposed here.
>
> In any cases, I would like to add a test. I initially added one in
> userspace_pm.sh, but due to "mptcp: pm: userspace: respect deny_join_id0
> attr", it is no longer possible to set allow_join_initial_addr_port
> sysctl knob to 0 there, as the value is no longer ignored by the
> userspace PM. Probably best to add a test in mptcp_join.sh.
> ---
> Documentation/netlink/specs/mptcp_pm.yaml | 7 +++++--
> include/uapi/linux/mptcp_pm.h             | 5 +++--
> net/mptcp/pm_netlink.c                    | 4 ++++
> 3 files changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/netlink/specs/mptcp_pm.yaml b/Documentation/netlink/specs/mptcp_pm.yaml
> index d15335684ec3d6256505f2b3887ce5818eb57462..0b53d8b5b4524b6026009cfa4510e7a6e141acf1 100644
> --- a/Documentation/netlink/specs/mptcp_pm.yaml
> +++ b/Documentation/netlink/specs/mptcp_pm.yaml
> @@ -28,13 +28,13 @@ definitions:
>           traffic-patterns it can take a long time until the
>           MPTCP_EVENT_ESTABLISHED is sent.
>           Attributes: token, family, saddr4 | saddr6, daddr4 | daddr6, sport,
> -          dport, server-side.
> +          dport, server-side, deny-join-id0.
>       -
>         name: established
>         doc: >-
>           A MPTCP connection is established (can start new subflows).
>           Attributes: token, family, saddr4 | saddr6, daddr4 | daddr6, sport,
> -          dport, server-side.
> +          dport, server-side, deny-join-id0.
>       -
>         name: closed
>         doc: >-
> @@ -266,6 +266,9 @@ attribute-sets:
>       -
>         name: server-side
>         type: u8
> +      -
> +        name: deny-join-id0
> +        type: u8
>
> operations:
>   list:
> diff --git a/include/uapi/linux/mptcp_pm.h b/include/uapi/linux/mptcp_pm.h
> index 6ac84b2f636ca22935c191c645449fb62b673899..6c751c488e51d6ab711607189041d5e2ea222e4e 100644
> --- a/include/uapi/linux/mptcp_pm.h
> +++ b/include/uapi/linux/mptcp_pm.h
> @@ -16,10 +16,10 @@
>  *   good time to allocate memory and send ADD_ADDR if needed. Depending on the
>  *   traffic-patterns it can take a long time until the MPTCP_EVENT_ESTABLISHED
>  *   is sent. Attributes: token, family, saddr4 | saddr6, daddr4 | daddr6,
> - *   sport, dport, server-side.
> + *   sport, dport, server-side, deny-join-id0.
>  * @MPTCP_EVENT_ESTABLISHED: A MPTCP connection is established (can start new
>  *   subflows). Attributes: token, family, saddr4 | saddr6, daddr4 | daddr6,
> - *   sport, dport, server-side.
> + *   sport, dport, server-side, deny-join-id0.
>  * @MPTCP_EVENT_CLOSED: A MPTCP connection has stopped. Attribute: token.
>  * @MPTCP_EVENT_ANNOUNCED: A new address has been announced by the peer.
>  *   Attributes: token, rem_id, family, daddr4 | daddr6 [, dport].
> @@ -126,6 +126,7 @@ enum mptcp_event_attr {
> 	MPTCP_ATTR_RESET_REASON,
> 	MPTCP_ATTR_RESET_FLAGS,
> 	MPTCP_ATTR_SERVER_SIDE,
> +	MPTCP_ATTR_DENY_JOIN_ID0,
>
> 	__MPTCP_ATTR_MAX
> };
> diff --git a/net/mptcp/pm_netlink.c b/net/mptcp/pm_netlink.c
> index 50aaf259959aeaf36e7ab954c6f7957eaf2bc390..93455b63ef80395ff19f40d84cd28438a3578b98 100644
> --- a/net/mptcp/pm_netlink.c
> +++ b/net/mptcp/pm_netlink.c
> @@ -415,6 +415,10 @@ static int mptcp_event_created(struct sk_buff *skb,
> 	if (nla_put_u8(skb, MPTCP_ATTR_SERVER_SIDE, READ_ONCE(msk->pm.server_side)))
> 		return -EMSGSIZE;
>
> +	if (nla_put_u8(skb, MPTCP_ATTR_DENY_JOIN_ID0,
> +		       READ_ONCE(msk->pm.remote_deny_join_id0)))
> +		return -EMSGSIZE;
> +
> 	return mptcp_event_add_subflow(skb, ssk);
> }
>
>
> -- 
> 2.50.1
>
>
>

  reply	other threads:[~2025-09-05  0:54 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-29 20:33 [PATCH mptcp-net 0/7] mptcp: pm: nl: announce deny-join-id0 attribute Matthieu Baerts (NGI0)
2025-08-29 20:33 ` [PATCH mptcp-net 1/7] mptcp: set remote_deny_join_id0 on SYN recv Matthieu Baerts (NGI0)
2025-08-29 20:33 ` [PATCH mptcp-net 2/7] mptcp: pm: userspace: respect deny_join_id0 attr Matthieu Baerts (NGI0)
2025-08-29 20:54   ` Christoph Paasch
2025-08-30  0:58     ` Mat Martineau
2025-09-01 10:08       ` Matthieu Baerts
2025-09-02 16:43         ` Christoph Paasch
2025-09-02 16:58           ` Matthieu Baerts
2025-08-29 20:33 ` [PATCH mptcp-net 3/7] mptcp: tfo: record 'deny join id0' info Matthieu Baerts (NGI0)
2025-09-06 14:05   ` Geliang Tang
2025-09-06 14:19     ` Matthieu Baerts
2025-09-10  3:56       ` Geliang Tang
2025-08-29 20:33 ` [PATCH mptcp-net 4/7] netlink: specs: mptcp: fix if-idx attribute type Matthieu Baerts (NGI0)
2025-09-06 14:16   ` Geliang Tang
2025-09-08 17:16     ` Matthieu Baerts
2025-09-06 14:18   ` Geliang Tang
2025-09-06 14:19   ` Geliang Tang
2025-08-29 20:33 ` [PATCH mptcp-net 5/7] doc: mptcp: net.mptcp.pm_type is deprecated Matthieu Baerts (NGI0)
2025-08-29 20:33 ` [PATCH mptcp-net 6/7] selftests: mptcp: shellcheck: support v0.11.0 Matthieu Baerts (NGI0)
2025-08-29 20:33 ` [PATCH RFC mptcp-net 7/7] mptcp: pm: nl: announce deny-join-id0 attribute Matthieu Baerts (NGI0)
2025-09-05  0:54   ` Mat Martineau [this message]
2025-09-08 17:17     ` Matthieu Baerts
2025-08-29 23:18 ` [PATCH mptcp-net 0/7] " MPTCP CI
2025-09-08 17:22 ` Matthieu Baerts

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c0361d0e-bbe8-d04b-2afd-4f27c3d30546@kernel.org \
    --to=martineau@kernel.org \
    --cc=matttbe@kernel.org \
    --cc=mptcp@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox