Currently, the MPTCP ADD_ADDR notifications are retransmitted after a
fixed timeout controlled by the net.mptcp.add_addr_timeout sysctl knob,
if the corresponding "echo" packets are not received before. This can be
too slow (or too quick), especially with a too cautious default value
set to 2 minutes.
- Patch 1: make ADD_ADDR retransmission timeout adaptive, using the
TCP's retransmission timeout. The corresponding sysctl knob is now
used as a maximum value.
- Patch 2: now that these ADD_ADDR retransmissions can happen faster,
all MPTCP Join subtests checking ADD_ADDR counters accept more
ADD_ADDR than expected (if any). This is aligned with the previous
behaviour, when the ADD_ADDR RTO was lowered down to 1 second.
- Patch 3: Some CIs have reported that some MPTCP Join signalling tests
were unstable. It seems that it is due to the time it can take in slow
environments to send a bunch of ADD_ADDR notifications and wait each
time for their echo reply. Use a longer transfer to avoid such errors.
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
Notes:
- Patch 1 has already been sent before, but the selftests had to be
adapted differently, see:
https://lore.kernel.org/d5397026-92eb-4a43-9534-954b43ab9305@kernel.org
---
Geliang Tang (1):
mptcp: make ADD_ADDR retransmission timeout adaptive
Matthieu Baerts (NGI0) (2):
selftests: mptcp: join: tolerate more ADD_ADDR
selftests: mptcp: join: allow more time to send ADD_ADDR
Documentation/networking/mptcp-sysctl.rst | 8 ++++---
net/mptcp/pm.c | 28 +++++++++++++++++++++----
tools/testing/selftests/net/mptcp/mptcp_join.sh | 25 ++++++++++------------
3 files changed, 40 insertions(+), 21 deletions(-)
---
base-commit: c6142e1913de563ab772f7b0e4ae78d6de9cc5b1
change-id: 20250905-net-next-mptcp-add_addr-retrans-adapt-565b9973acfd
Best regards,
--
Matthieu Baerts (NGI0) <matttbe@kernel.org>