Re: [PATCH mptcp-next v2 5/6] mptcp: pm: in-kernel: add 'address' endpoints

[Matthieu Baerts <matttbe@kernel.org>]

24 Sept 2025 23:51:04 Mat Martineau <martineau@kernel.org>:

> On Wed, 24 Sep 2025, Matthieu Baerts wrote:
>
>> On 24/09/2025 10:33, Matthieu Baerts wrote:
>>> Hi Mat,
>>>
>>> Thank you for your reply!
>>>
>>> On 24/09/2025 00:35, Mat Martineau wrote:
>>>> On Tue, 23 Sep 2025, Matthieu Baerts (NGI0) wrote:
>>>>
>>>>> Currently, upon the reception of an ADD_ADDR (and when the fullmesh flag
>>>>> is not used), the in-kernel PM will create new subflows using the local
>>>>> address the routing configuration will pick.
>>>>>
>>>>> It would be easier to pick local addresses from a selected list of
>>>>> endpoints, and use it only once, than relying on routing rules.
>>>>>
>>>>> Use case: both the client (C) and the server (S) have two addresses (a
>>>>> and b). The client establishes the connection between C(a) and S(a).
>>>>> Once established, the server announces its additional address S(b). Once
>>>>> received, the client connects to it using its second address C(b).
>>>>> Compared to a situation without the 'address' endpoint for C(b), the
>>>>> client didn't use this address C(b) to establish a subflow to the
>>>>> server's primary address S(a). So at the end, we have:
>>>>>
>>>>>   C        S
>>>>>  C(a) --- S(a)
>>>>>  C(b) --- S(b)
>>>>>
>>>>> In case of a 3rd address on each side (C(c) and S(c)), upon the
>>>>> reception of an ADD_ADDR with S(c), the client should not pick C(b)
>>>>> because it has already been used. C(c) should then be used.
>>>>>
>>>>> Note that this situation is currently possible if C doesn't add any
>>>>> endpoint, but configure the routing in order to pick C(b) for the route
>>>>> to S(b), and pick C(c) for the route to S(c). That doesn't sound very
>>>>> practical because it means knowing in advance the IP addresses that
>>>>> will be used and announced by the server.
>>>>>
>>>>> In the code, the new endpoint type is added. Similar to the other
>>>>> subflow types, an MPTCP_INFO counter is added. While at it, hole are now
>>>>> commented in struct mptcp_info, to remember next time that these holes
>>>>> can no longer be used.
>>>>>
>>>>
>>>> I definitely agree that this is a very worthwhile use case. As we
>>>> discussed in the v1 thread, the API in-kernel PM is leading to some
>>>> complexity when mixing endpoint types but this step seems manageable. I
>>>> don't think we should continue adding endpoint types after this.
>>>
>>> Agreed!
>>>> Before sending to net-next I would really like to hear from either Paolo
>>>> or Geliang to see if they concur on this one additional in-kernel PM
>>>> endpoint!
>>>
>>> Sure!
>>>
>>>>> Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/503
>>>>> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
>>>>> ---
>>>>> v2:
>>>>> - rename var and function names to state 1 address will be filled (Mat)
>>>>> ---
>>>>> include/uapi/linux/mptcp.h |  6 +++-
>>>>> net/mptcp/pm_kernel.c      | 82 ++++++++++++++++++++++++++++++++++++++
>>>>> ++++++++
>>>>> net/mptcp/protocol.h       |  1 +
>>>>> net/mptcp/sockopt.c        |  2 ++
>>>>> 4 files changed, 90 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/include/uapi/linux/mptcp.h b/include/uapi/linux/mptcp.h
>>>>> index
>>>>> 5ec996977b3fa2351222e6d01b814770b34348e9..65dc069e9063325ad2e1ffb1da21cc4a4b6efd32 100644
>>>>> --- a/include/uapi/linux/mptcp.h
>>>>> +++ b/include/uapi/linux/mptcp.h
>>>>> @@ -39,6 +39,7 @@
>>>>> #define MPTCP_PM_ADDR_FLAG_BACKUP        _BITUL(2)
>>>>> #define MPTCP_PM_ADDR_FLAG_FULLMESH        _BITUL(3)
>>>>> #define MPTCP_PM_ADDR_FLAG_IMPLICIT        _BITUL(4)
>>>>> +#define MPTCP_PM_ADDR_FLAG_ADDRESS        _BITUL(5)
>>>>
>>>> I do think we can come up with a better word - "address" applies equally
>>>> to all types of endpoints and doesn't describe the feature.
>>>>
>>>> So, let's brainstorm some options here. To start with, I want to give
>>>> "no" votes to "single" (too much like "signal") and "address".
>>>>
>>>> Some ideas -
>>>>
>>>> * singleton: seems different enough from "signal" :)
>>>>
>>>> * parallel: the subflows are like lines that never cross
>>>>
>>>> * laminar: like the idea of https://en.wikipedia.org/wiki/Laminar_flow,
>>>> the different subflows don't mix with each other on an interface (unlike
>>>> the "turbulent" way traffic is mixed by fullmesh). Naming collides with
>>>> some academic TCP work however.
>>>>
>>>> * sspi: just because we already used this for "single subflow per
>>>> interface" in mptcpd.
>>> Note about sspi: with the new type introduced here, we can still have
>>> more than one subflow per interface if you have different families:
>>> v4/v6. We might need a new "global" option in the future (not a type) to
>>> ensure that, see:
>>>
>>>   https://github.com/multipath-tcp/mptcp_net-next/issues/542
>>>
>>>> Anything there sound good, or helpful in inspiring better ideas?
>>>
>>> Funny, your words are mostly describing the "end result" -- using one
>>> endpoint once -- while I was more trying to find a word describing the
>>> "action" -- this endpoint is used when an ADD_ADDR is received. That's
>>> maybe because I had my mind in the code and tests at that time :)
>>>
>>> I *think* it might be easier to describe the "action", and document the
>>> "end result" that can be achieved with that. That would also be closer
>>> to the current "signal" and "subflow" we have, and maybe people will use
>>> this new type for a different "end result". WDYT?
>>>
>>> Having said that, I'm still struggling to find a good word!
>>>
>>> Maybe we should use multiple words? 'add_addr_accept' so it is linked to
>>> the 'add_addr_accepted' limit?
>>>
>>> Or 'laminar', but mostly because the word is "complex" and might push
>>> people to read the doc :)
>>
>> Or 'sspe': "single subflow per endpoint"? But still, I think it might be
>> easier to focus on the "action". But I'm still open to the "end result"
>> if we cannot find a good word for the "action".
>>
>
> The action vs. result framing is helpful, thanks. While the details of the implementation are clear to you (the author) and us (maintainers), nearly all *users* of the feature never look at kernel code or protocol details and will be approaching it thinking of the "end result" they want to achieve. So that's where my thought process has been with this naming exercise.
>
> 'sspe' or 'laminar' are tied for my top choice at this point.
>
> I tried to come up with multi-word ideas yesterday (since "fullmesh" is a compound word too!) and nothing seemed quite right. "oneconn"/"oneconnect"/"oneflow" is the closest I got.

Thank you for having thought about that!

I'm then going to use "laminar", and first explain it should be used in
combination with "subflow", then the behaviour when only this flag is set.

Cheers,
Matt