mptcp.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
* [PATCH mptcp-next v4 0/2] mptcp: improve ADD_ADDR timeout handling
@ 2025-08-12  8:39 Geliang Tang
  2025-08-12  8:39 ` [PATCH mptcp-next v4 1/2] mptcp: make ADD_ADDR retransmission timeout adaptive Geliang Tang
                   ` (3 more replies)
  0 siblings, 4 replies; 8+ messages in thread
From: Geliang Tang @ 2025-08-12  8:39 UTC (permalink / raw)
  To: mptcp; +Cc: Geliang Tang

From: Geliang Tang <tanggeliang@kylinos.cn>

v4:
 - rollback to v2, just use icsk->icsk_rto.

Depends on:
 - mptcp: disable add_addr retrans, v2

Based-on: <cover.1754534416.git.tanggeliang@kylinos.cn>

v3:
 - a new patch, remove duplicate sk_reset_timer call
 - use __tcp_set_rto() * 2 instead of icsk->icsk_rto
 - update selftests.
 - https://patchwork.kernel.org/project/mptcp/cover/cover.1754449947.git.tanggeliang@kylinos.cn/

v2:
 - do not rename add_addr_timeout
 - use icsk->icsk_rto instead of tp->srtt_us
 - increase the time after each retransmission
 - https://patchwork.kernel.org/project/mptcp/patch/40706ad511220729207ccd7cf48e320e4d0d7dea.1754028199.git.tanggeliang@kylinos.cn/

v1:
 - https://patchwork.kernel.org/project/mptcp/cover/cover.1753777199.git.tanggeliang@kylinos.cn/

Geliang Tang (2):
  mptcp: make ADD_ADDR retransmission timeout adaptive
  selftests: mptcp: remove add_addr_timeout settings

 Documentation/networking/mptcp-sysctl.rst     |  4 +--
 net/mptcp/pm.c                                | 28 ++++++++++++++++---
 .../testing/selftests/net/mptcp/mptcp_join.sh |  3 --
 3 files changed, 26 insertions(+), 9 deletions(-)

-- 
2.48.1


^ permalink raw reply	[flat|nested] 8+ messages in thread

* [PATCH mptcp-next v4 1/2] mptcp: make ADD_ADDR retransmission timeout adaptive
  2025-08-12  8:39 [PATCH mptcp-next v4 0/2] mptcp: improve ADD_ADDR timeout handling Geliang Tang
@ 2025-08-12  8:39 ` Geliang Tang
  2025-08-15 15:29   ` Matthieu Baerts
  2025-08-12  8:39 ` [PATCH mptcp-next v4 2/2] selftests: mptcp: remove add_addr_timeout settings Geliang Tang
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 8+ messages in thread
From: Geliang Tang @ 2025-08-12  8:39 UTC (permalink / raw)
  To: mptcp; +Cc: Geliang Tang, Christoph Paasch

From: Geliang Tang <tanggeliang@kylinos.cn>

Currently the ADD_ADDR option is retransmitted with a fixed timeout. This
patch makes the retransmission timeout adaptive by using the maximum RTO
among all the subflows, while still capping it at the configured maximum
value (add_addr_timeout_max). This improves responsiveness when
establishing new subflows.

Specifically:
1. Adds mptcp_adjust_add_addr_timeout() helper to compute the adaptive
timeout.
2. Uses maximum subflow RTO (icsk_rto) when available.
3. Applies exponential backoff based on retransmission count.
4. Maintains fallback to configured max timeout when no RTO data exists.

Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/576
Reviewed-by: Christoph Paasch <cpaasch@openai.com>
Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
---
 Documentation/networking/mptcp-sysctl.rst |  4 ++--
 net/mptcp/pm.c                            | 28 +++++++++++++++++++----
 2 files changed, 26 insertions(+), 6 deletions(-)

diff --git a/Documentation/networking/mptcp-sysctl.rst b/Documentation/networking/mptcp-sysctl.rst
index 1683c139821e..2b8e8fb99ee2 100644
--- a/Documentation/networking/mptcp-sysctl.rst
+++ b/Documentation/networking/mptcp-sysctl.rst
@@ -8,8 +8,8 @@ MPTCP Sysfs variables
 ===============================
 
 add_addr_timeout - INTEGER (seconds)
-	Set the timeout after which an ADD_ADDR control message will be
-	resent to an MPTCP peer that has not acknowledged a previous
+	Set the maximum value of timeout after which an ADD_ADDR control message
+	will be resent to an MPTCP peer that has not acknowledged a previous
 	ADD_ADDR message.
 
 	Do not retransmit if set to 0.
diff --git a/net/mptcp/pm.c b/net/mptcp/pm.c
index e6dcc5b62645..02dfb379417e 100644
--- a/net/mptcp/pm.c
+++ b/net/mptcp/pm.c
@@ -268,6 +268,27 @@ int mptcp_pm_mp_prio_send_ack(struct mptcp_sock *msk,
 	return -EINVAL;
 }
 
+static unsigned int mptcp_adjust_add_addr_timeout(struct mptcp_sock *msk)
+{
+	const struct net *net = sock_net((struct sock *)msk);
+	unsigned int rto = mptcp_get_add_addr_timeout(net);
+	struct mptcp_subflow_context *subflow;
+	unsigned int max = 0;
+
+	mptcp_for_each_subflow(msk, subflow) {
+		struct sock *ssk = mptcp_subflow_tcp_sock(subflow);
+		struct inet_connection_sock *icsk = inet_csk(ssk);
+
+		if (icsk->icsk_rto > max)
+			max = icsk->icsk_rto;
+	}
+
+	if (max && max < rto)
+		rto = max;
+
+	return rto;
+}
+
 static void mptcp_pm_add_timer(struct timer_list *timer)
 {
 	struct mptcp_pm_add_entry *entry = timer_container_of(entry, timer,
@@ -292,7 +313,7 @@ static void mptcp_pm_add_timer(struct timer_list *timer)
 		goto out;
 	}
 
-	timeout = mptcp_get_add_addr_timeout(sock_net(sk));
+	timeout = mptcp_adjust_add_addr_timeout(msk);
 	if (!timeout)
 		goto out;
 
@@ -307,7 +328,7 @@ static void mptcp_pm_add_timer(struct timer_list *timer)
 
 	if (entry->retrans_times < ADD_ADDR_RETRANS_MAX)
 		sk_reset_timer(sk, timer,
-			       jiffies + timeout);
+			       jiffies + (timeout << entry->retrans_times));
 
 	spin_unlock_bh(&msk->pm.lock);
 
@@ -348,7 +369,6 @@ bool mptcp_pm_alloc_anno_list(struct mptcp_sock *msk,
 {
 	struct mptcp_pm_add_entry *add_entry = NULL;
 	struct sock *sk = (struct sock *)msk;
-	struct net *net = sock_net(sk);
 	unsigned int timeout;
 
 	lockdep_assert_held(&msk->pm.lock);
@@ -374,7 +394,7 @@ bool mptcp_pm_alloc_anno_list(struct mptcp_sock *msk,
 
 	timer_setup(&add_entry->add_timer, mptcp_pm_add_timer, 0);
 reset_timer:
-	timeout = mptcp_get_add_addr_timeout(net);
+	timeout = mptcp_adjust_add_addr_timeout(msk);
 	if (timeout)
 		sk_reset_timer(sk, &add_entry->add_timer, jiffies + timeout);
 
-- 
2.48.1


^ permalink raw reply related	[flat|nested] 8+ messages in thread

* [PATCH mptcp-next v4 2/2] selftests: mptcp: remove add_addr_timeout settings
  2025-08-12  8:39 [PATCH mptcp-next v4 0/2] mptcp: improve ADD_ADDR timeout handling Geliang Tang
  2025-08-12  8:39 ` [PATCH mptcp-next v4 1/2] mptcp: make ADD_ADDR retransmission timeout adaptive Geliang Tang
@ 2025-08-12  8:39 ` Geliang Tang
  2025-09-02 16:52   ` Matthieu Baerts
  2025-08-12 10:27 ` [PATCH mptcp-next v4 0/2] mptcp: improve ADD_ADDR timeout handling MPTCP CI
  2025-08-15 15:24 ` Matthieu Baerts
  3 siblings, 1 reply; 8+ messages in thread
From: Geliang Tang @ 2025-08-12  8:39 UTC (permalink / raw)
  To: mptcp; +Cc: Geliang Tang

From: Geliang Tang <tanggeliang@kylinos.cn>

Now that add_addr_timeout can be dynamically adjusted, there is no need
to set specific timeout values in the mptcp_join.sh tests. This patch
removes the explicit sysctl settings for net.mptcp.add_addr_timeout
from the test scripts.

The change simplifies the test setup and ensures the tests work with
the default or dynamically adjusted timeout values.

Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
---
 tools/testing/selftests/net/mptcp/mptcp_join.sh | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/tools/testing/selftests/net/mptcp/mptcp_join.sh b/tools/testing/selftests/net/mptcp/mptcp_join.sh
index 82cae37d9c20..e85bb62046e0 100755
--- a/tools/testing/selftests/net/mptcp/mptcp_join.sh
+++ b/tools/testing/selftests/net/mptcp/mptcp_join.sh
@@ -347,8 +347,6 @@ reset_with_add_addr_timeout()
 		tables="${ip6tables}"
 	fi
 
-	ip netns exec $ns1 sysctl -q net.mptcp.add_addr_timeout=1
-
 	if ! ip netns exec $ns2 $tables -A OUTPUT -p tcp \
 			-m tcp --tcp-option 30 \
 			-m bpf --bytecode \
@@ -2183,7 +2181,6 @@ signal_address_tests()
 		pm_nl_add_endpoint $ns2 10.0.4.2 flags signal
 
 		# the peer could possibly miss some addr notification, allow retransmission
-		ip netns exec $ns1 sysctl -q net.mptcp.add_addr_timeout=1
 		speed=slow \
 			run_tests $ns1 $ns2 10.0.1.1
 
-- 
2.48.1


^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: [PATCH mptcp-next v4 0/2] mptcp: improve ADD_ADDR timeout handling
  2025-08-12  8:39 [PATCH mptcp-next v4 0/2] mptcp: improve ADD_ADDR timeout handling Geliang Tang
  2025-08-12  8:39 ` [PATCH mptcp-next v4 1/2] mptcp: make ADD_ADDR retransmission timeout adaptive Geliang Tang
  2025-08-12  8:39 ` [PATCH mptcp-next v4 2/2] selftests: mptcp: remove add_addr_timeout settings Geliang Tang
@ 2025-08-12 10:27 ` MPTCP CI
  2025-08-15 15:24 ` Matthieu Baerts
  3 siblings, 0 replies; 8+ messages in thread
From: MPTCP CI @ 2025-08-12 10:27 UTC (permalink / raw)
  To: Geliang Tang; +Cc: mptcp

Hi Geliang,

Thank you for your modifications, that's great!

Our CI did some validations and here is its report:

- KVM Validation: normal: Unstable: 1 failed test(s): packetdrill_add_addr 🔴
- KVM Validation: debug: Success! ✅
- KVM Validation: btf-normal (only bpftest_all): Success! ✅
- KVM Validation: btf-debug (only bpftest_all): Success! ✅
- Task: https://github.com/multipath-tcp/mptcp_net-next/actions/runs/16904044239

Initiator: Patchew Applier
Commits: https://github.com/multipath-tcp/mptcp_net-next/commits/9cc8618373f4
Patchwork: https://patchwork.kernel.org/project/mptcp/list/?series=990438


If there are some issues, you can reproduce them using the same environment as
the one used by the CI thanks to a docker image, e.g.:

    $ cd [kernel source code]
    $ docker run -v "${PWD}:${PWD}:rw" -w "${PWD}" --privileged --rm -it \
        --pull always mptcp/mptcp-upstream-virtme-docker:latest \
        auto-normal

For more details:

    https://github.com/multipath-tcp/mptcp-upstream-virtme-docker


Please note that despite all the efforts that have been already done to have a
stable tests suite when executed on a public CI like here, it is possible some
reported issues are not due to your modifications. Still, do not hesitate to
help us improve that ;-)

Cheers,
MPTCP GH Action bot
Bot operated by Matthieu Baerts (NGI0 Core)

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH mptcp-next v4 0/2] mptcp: improve ADD_ADDR timeout handling
  2025-08-12  8:39 [PATCH mptcp-next v4 0/2] mptcp: improve ADD_ADDR timeout handling Geliang Tang
                   ` (2 preceding siblings ...)
  2025-08-12 10:27 ` [PATCH mptcp-next v4 0/2] mptcp: improve ADD_ADDR timeout handling MPTCP CI
@ 2025-08-15 15:24 ` Matthieu Baerts
  2025-08-18 10:52   ` Matthieu Baerts
  3 siblings, 1 reply; 8+ messages in thread
From: Matthieu Baerts @ 2025-08-15 15:24 UTC (permalink / raw)
  To: Geliang Tang, mptcp; +Cc: Geliang Tang

Hi Geliang,

On 12/08/2025 10:39, Geliang Tang wrote:
> From: Geliang Tang <tanggeliang@kylinos.cn>
> 
> v4:
>  - rollback to v2, just use icsk->icsk_rto.

Thank you for the v4. Thanks to the previous measurements you did, the
new version looks good to me:

Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>

I have one small comment in patch 1/2, but that's not blocking.

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


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH mptcp-next v4 1/2] mptcp: make ADD_ADDR retransmission timeout adaptive
  2025-08-12  8:39 ` [PATCH mptcp-next v4 1/2] mptcp: make ADD_ADDR retransmission timeout adaptive Geliang Tang
@ 2025-08-15 15:29   ` Matthieu Baerts
  0 siblings, 0 replies; 8+ messages in thread
From: Matthieu Baerts @ 2025-08-15 15:29 UTC (permalink / raw)
  To: Geliang Tang, mptcp; +Cc: Geliang Tang, Christoph Paasch

Hi Geliang,

On 12/08/2025 10:39, Geliang Tang wrote:
> From: Geliang Tang <tanggeliang@kylinos.cn>
> 
> Currently the ADD_ADDR option is retransmitted with a fixed timeout. This
> patch makes the retransmission timeout adaptive by using the maximum RTO
> among all the subflows, while still capping it at the configured maximum
> value (add_addr_timeout_max). This improves responsiveness when
> establishing new subflows.
> 
> Specifically:
> 1. Adds mptcp_adjust_add_addr_timeout() helper to compute the adaptive
> timeout.
> 2. Uses maximum subflow RTO (icsk_rto) when available.
> 3. Applies exponential backoff based on retransmission count.
> 4. Maintains fallback to configured max timeout when no RTO data exists.

I might be good to add a note about the behavioural change:

  This slightly change the behaviour of the MPTCP "add_addr_timeout"
  sysctl knob to be used as a maximum instead of a fixed value, but this
  is seen as an improvement: the ADD_ADDR might be sent quicker than
  before to improve the overall MPTCP connection. Also, the default
  value is set at 2 min, which was way too big, and caused the ADD_ADDR
  not to be retransmitted for connections shorter than 2 minutes.

> Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/576
> Reviewed-by: Christoph Paasch <cpaasch@openai.com>
> Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
> ---
>  Documentation/networking/mptcp-sysctl.rst |  4 ++--
>  net/mptcp/pm.c                            | 28 +++++++++++++++++++----
>  2 files changed, 26 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/networking/mptcp-sysctl.rst b/Documentation/networking/mptcp-sysctl.rst
> index 1683c139821e..2b8e8fb99ee2 100644
> --- a/Documentation/networking/mptcp-sysctl.rst
> +++ b/Documentation/networking/mptcp-sysctl.rst
> @@ -8,8 +8,8 @@ MPTCP Sysfs variables
>  ===============================
>  
>  add_addr_timeout - INTEGER (seconds)
> -	Set the timeout after which an ADD_ADDR control message will be
> -	resent to an MPTCP peer that has not acknowledged a previous
> +	Set the maximum value of timeout after which an ADD_ADDR control message
> +	will be resent to an MPTCP peer that has not acknowledged a previous
>  	ADD_ADDR message.

I suggest adding this at the end:

  A dynamically estimated retransmission timeout based on the estimated
  connection round-trip-time is used if this value is lower than the
  maximum one.

I can do that when applying the patch. I can update the text if needed
later on.

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


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH mptcp-next v4 0/2] mptcp: improve ADD_ADDR timeout handling
  2025-08-15 15:24 ` Matthieu Baerts
@ 2025-08-18 10:52   ` Matthieu Baerts
  0 siblings, 0 replies; 8+ messages in thread
From: Matthieu Baerts @ 2025-08-18 10:52 UTC (permalink / raw)
  To: Geliang Tang, mptcp; +Cc: Geliang Tang

Hi Geliang,

On 15/08/2025 17:24, Matthieu Baerts wrote:
> Hi Geliang,
> 
> On 12/08/2025 10:39, Geliang Tang wrote:
>> From: Geliang Tang <tanggeliang@kylinos.cn>
>>
>> v4:
>>  - rollback to v2, just use icsk->icsk_rto.
> 
> Thank you for the v4. Thanks to the previous measurements you did, the
> new version looks good to me:
> 
> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
> 
> I have one small comment in patch 1/2, but that's not blocking.

Now in our tree (with this suggestion ↑ -- feat. for -next):

New patches for t/upstream:
- 34c96ea5123b: mptcp: make ADD_ADDR retransmission timeout adaptive
- 5d56ac514943: selftests: mptcp: remove add_addr_timeout settings
- Results: d89b1338067d..de0b36f41cae (export)

Tests are now in progress:

- export:
https://github.com/multipath-tcp/mptcp_net-next/commit/b44eb4c28d8623dfa68674caab04d9f7f07846ef/checks

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


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH mptcp-next v4 2/2] selftests: mptcp: remove add_addr_timeout settings
  2025-08-12  8:39 ` [PATCH mptcp-next v4 2/2] selftests: mptcp: remove add_addr_timeout settings Geliang Tang
@ 2025-09-02 16:52   ` Matthieu Baerts
  0 siblings, 0 replies; 8+ messages in thread
From: Matthieu Baerts @ 2025-09-02 16:52 UTC (permalink / raw)
  To: Geliang Tang, mptcp; +Cc: Geliang Tang

Hi Geliang,

On 12/08/2025 10:39, Geliang Tang wrote:
> From: Geliang Tang <tanggeliang@kylinos.cn>
> 
> Now that add_addr_timeout can be dynamically adjusted, there is no need
> to set specific timeout values in the mptcp_join.sh tests. This patch
> removes the explicit sysctl settings for net.mptcp.add_addr_timeout
> from the test scripts.

I don't think we should remove them: when looking at mptcp_join.sh, I
see that chk_add_nr() and chk_add_tx_nr() are more tolerant with
retransmissions.

Linked to that, I see that some tests are failing because too many
ADD_ADDR are seen:

https://github.com/multipath-tcp/mptcp_net-next/actions/runs/17391054770
https://netdev-3.bots.linux.dev/vmksft-mptcp-dbg/results/280241/1-mptcp-join-sh/stdout
https://netdev-3.bots.linux.dev/vmksft-mptcp-dbg/results/279881/1-mptcp-join-sh/stdout

I wonder if it would not be better to always check for fewer ADD_ADDR
than expected.

Also, for this one:

https://netdev-3.bots.linux.dev/vmksft-mptcp-dbg/results/277181/1-mptcp-join-sh/stdout

Probably we should mark the test as "slow".

I will try to look at that.

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


^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2025-09-02 16:52 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-08-12  8:39 [PATCH mptcp-next v4 0/2] mptcp: improve ADD_ADDR timeout handling Geliang Tang
2025-08-12  8:39 ` [PATCH mptcp-next v4 1/2] mptcp: make ADD_ADDR retransmission timeout adaptive Geliang Tang
2025-08-15 15:29   ` Matthieu Baerts
2025-08-12  8:39 ` [PATCH mptcp-next v4 2/2] selftests: mptcp: remove add_addr_timeout settings Geliang Tang
2025-09-02 16:52   ` Matthieu Baerts
2025-08-12 10:27 ` [PATCH mptcp-next v4 0/2] mptcp: improve ADD_ADDR timeout handling MPTCP CI
2025-08-15 15:24 ` Matthieu Baerts
2025-08-18 10:52   ` Matthieu Baerts

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).