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 11:24, Anil Kaushik wrote:
> Hi Matt,
> 
>   Thanks for the review.
> 
> My response inline.
> 
> On Thu, Oct 22, 2026 at 1:02 PM Matthieu Baerts <matttbe@kernel.org> wrote:
>>
>> Hi Anil,
>>
>> Thank you for your reply.
>>
>> 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:
>>>>>>> Add a sensible default value (what do you recommend?)
>>>>>>
>>>>>> 15 SYN retries: about 20 minutes with the 120s max RTO.
>>>>>
>>>>> I guess it could even be longer, no? With an exponential backoff, it's
>>>>> not spamming the network too much.
>>>>>
>>>>> I wonder if we shouldn't get something similar to tcp_retries2. But
>>>>> here, with the syn, we also need to tcp_syn_linear_timeouts into
>>>>> account. Either we keep it to 15 by default and, (if not 0), we add
>>>>> tcp_syn_linear_timeouts, or we initialise it to 19.
>>>>>
>>>
>>> tcp_write_timeout() already adds tcp_syn_linear_timeouts on top of
>>> icsk_syn_retries for SYN_SENT sockets. With the defaults, 15 gives 4
>>> linear + 15 exponential retries, about 20 minutes, close to
>>> tcp_retries2. I can make it longer if you prefer. Let me know please?
>>
>> It is always tricky to find a good default value. I guess 15-20 minutes
>> is fine for most people. Connections are usually not that long, but some
>> can be, e.g. ssh. But then, what do we loose to put it higher by default
>> to support more cases? Maybe environments with low memory could not like
>> that, but either they don't manage that many connections, or they don't
>> use MPTCP.
>>
>> When I look at nf_conntrack_tcp_timeout_established, it is set to 5 days
>> by default, so we shouldn't go higher than that. But maybe we should
>> target a few hours by default? e.g. using 20 (~10.5h?) or maybe better
>> to use 21 (~21h) or 22 to cover a WE (~42.5h?)?
>>
> The SYN RTO is capped at TCP_RTO_MAX (120s), so after the first
> doubling each retry only adds 2 minutes: 20 is about 30 minutes,and
> the maximum, 127 (MAX_TCP_SYNCNT), about 4 hours.
> Should I use 127 by default, to get a few hours? Covering a weekend
> would need something else, e.g. a new attempt once the SYN retries are
> used up, which would bring a timer back. Let me know what you think?

Ah yes, thank you, I remember something with the TCP_RTO_MAX. OK then
please use the maximum, and add "(127)" after mentionning MAX_TCP_SYNCNT
in the doc.

>>>>>>> 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?

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