Re: [RFC PATCH mptcp-next v3 2/3] mptcp: pm: kernel: retry subflows closed after an error

[Matthieu Baerts <matttbe@kernel.org>]

On 22/10/2026 16:31, Anil Kaushik wrote:
> Hi Matt,
> 
>  Sorry my earlier response had html content.
> 
> Resending my response again. Couple of more points too.
> 
> On Thu, Oct 22, 2026 at 7:00 PM Matthieu Baerts <matttbe@kernel.org> wrote:
>>
>> On 22/10/2026 13:04, Anil Kaushik wrote:
>>> On Thu, Oct 22, 2026 at 3:58 PM Matthieu Baerts <matttbe@kernel.org> wrote:
>>>> On 22/10/2026 11:24, Anil Kaushik wrote:
>>>>> On Thu, Oct 22, 2026 at 1:02 PM Matthieu Baerts <matttbe@kernel.org> wrote:
>>>>>> On 21/10/2026 20:20, Anil Kaushik wrote:
>>>>>>> On Wed, Oct 21, 2026 at 11:18 PM Matthieu Baerts <matttbe@kernel.org> wrote:
>>>>>>>> On 16/10/2026 10:43, Matthieu Baerts wrote:
>>>>>>>>> On 16/10/2026 07:49, Anil Kaushik wrote:
>>
>> (...)
>>
>>>>>>>>>>> modify icsk_syn_retries instead [...] WDYT?
>>>>>>>>>>
>>>>>>>>>> Good idea, I will do that: one new subflow per failure, with its SYN
>>>>>>>>>> retries set from the new netlink limit, 0 = disabled. It also removes
>>>>>>>>>> the socket reuse, the retries counter and the 60s check.
>>>>>>>>>>
>>>>>>>>>> One point to think though, If ICMP unreachable stops the SYN at once.
>>>>>>>>>> I would not retry
>>>>>>>>>> again then. Is that OK?
>>>>>>>>>
>>>>>>>>> Good point. In your specific case, what do you observe?
>>>>>>>
>>>>>>> In my tests, the fiber outage is a silent drop: the SYNs just time
>>>>>>> out, and the subflow comes back once the path is up again.
>>>>>>
>>>>>> Interesting. Out of curiosity, how long are these outages typically?
>>>>>> Less than ~20 minutes I suppose?
>>>>>>
>>>>> It varies. Short ones are a few minutes, but when the fiber is cut, the
>>>>> repair can take several hours. So a longer default would help.
>>>>
>>>> When the "fiber is cut", do you still have an IP address or is the
>>>> connection still up?
>>>>
>>>> To me, if there is an issue in the network, we generally have two cases:
>>>> either we are closed to an end (client / server) and the host should be
>>>> disconnected from that network, or it is happening in the "middle" of
>>>> the network where BGP will reroute the traffic.
>>>> In case of disconnection, I would guess the IP is lost and the
>>>> corresponding MPTCP endpoint is removed. The userspace will try to
>>>> reconnect, then re-add the MPTCP endpoint, and the PM can restart the
>>>> subflows.
>>>>
>>>> But that doesn't seem to be the case on your side :)
>>>> Do you know why?
>>>>
>>> Yes. MPTCP runs on a gateway in front of the fiber and Starlink
>>> routers, connected to each of them over Ethernet. The fiber cut is
>>> between the fiber router and the ISP, so the gateway keeps its link and
>>> its IP address on that side, nothing removes the MPTCP endpoint, and
>>> the packets on that path are just dropped. There will be mix of
>>> deployments like this.
>>>
>>> Any thoughts?
>>
>> So when you have an issue between the fiber router and the ISP, the
>> fiber router keeps its connection up to the ISP, and no ICMP network
>> unreachable are sent?
>>
>> In such setup, and if the fiber router gets a notification somehow in
>> case of issue, I would find it better to forward this notification to
>> the gateway to disable the MPTCP endpoint. An alternative is to have a
>> simple service monitoring the links, and removing/re-adding endpoints: a
>> simple "echo" service in TCP (or ICMP echo) with a server somewhere, one
>> per link. With that, you have more control and can eventually ack quicker.
>>
> 
> Yes. The router still has its default route, so it does not send ICMP
> unreachable, it just drops the packets. And when its WAN link really goes
> down, it has no way to tell the gateway.

It could eventually turn off the link to the gateway.

> Agreed on the link monitoring. A small probe per link, removing and
> re-adding the endpoint, is a good idea and I will send a separate RFC.
> Let me know what you think?

That's something that should be done in userspace, no?

>> Yet, the series you are suggesting here still makes sense because that
>> would help people, or in case of issues not detected by the network manager.
>>
> I will send v8 with the default set to the maximum, 127.

Thank you, I will try to have a look.

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