Re: [PATCH mptcp-net v2 1/2] mptcp: pm: avoid sending RM_ADDR over same subflow

[Matthieu Baerts <matttbe@kernel.org>]

Hi Mat,

Thank you for the review!

On 25/02/2026 05:12, Mat Martineau wrote:
> On Fri, 20 Feb 2026, Matthieu Baerts (NGI0) wrote:
> 
>> RM_ADDR are sent over an active subflow, the first one in the subflows
>> list. There is then a high chance the initial subflow is picked. With
>> the in-kernel PM, when an endpoint is removed, a RM_ADDR is sent, then
>> linked subflows are closed. This is done for each active MPTCP
>> connection.
>>
>> MPTCP endpoints are likely removed because the attached network is no
>> longer available or usable. In this case, it is better to avoid sending
>> this RM_ADDR over the subflow that is going to be removed, but prefer
>> sending it over another active and non stale subflow, if any.
>>
>> This modification avoids situations where the other end is not notified
>> when a subflow is no longer usable: typically when the endpoint linked
>> to the initial subflow is removed, especially on the server side.

(...)

> This is definitely an improvement over the older code, thanks! It does
> still send RM_ADDR exactly once. It could also RM_ADDR using *all*
> active non-stale subflows (any that are delivered after the first would
> be ignored). In terms of interoperability there is the risk of confusing
> the peer's path manager if it doesn't handle RM_ADDR for a non-existant
> subflow.
> 
> Maybe that's more of a mptcp-next feature (if it makes sense to do at all).

I think implementing this would definitively be mptcp-next material. If
we want this, we will also need to change the way the option is added:
for the moment, the rm_list is copied in the msk, and a bit is set
before triggering the ACK, and when sending the ACK, the bit is reset.
So we would need to also record the subflow IDs that should send the
RM_ADDR, and only remove the main bit when all of subflows have sent it.

Now regarding the behaviour, I think it more likely to have concurrent
issues: maybe a subflow could be re-created or an ADD_ADDR could be
received before all RM_ADDR are transmitted, e.g. in case of bufferbloat
on one path?

> The v2 patch here is closer to the existing behavior so I'm ok with
> approving it:
> 
> Reviewed-by: Mat Martineau <martineau@kernel.org>

Thanks! Is this tag also covering patch 2/2?

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.