[PATCH packetdrill] mptcp: dss: validate tcp_rto_max_ms on DATA_FIN retransmissions

Kalpan Jani posted 1 patch 1 week, 3 days ago
Failed in applying to current master (apply log)
gtests/net/mptcp/dss/dss_fin_retrans_established.pkt | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
[PATCH packetdrill] mptcp: dss: validate tcp_rto_max_ms on DATA_FIN retransmissions
Posted by Kalpan Jani 1 week, 3 days ago
The kernel patch "mptcp: honour configured min/max RTO in retransmit
paths" makes the MPTCP-level DATA_FIN retransmission backoff follow
the tcp_rto_min_us / tcp_rto_max_ms sysctls instead of the hard-coded
TCP_RTO_MIN / TCP_RTO_MAX constants.

Validate it in dss_fin_retrans_established.pkt: set tcp_rto_max_ms to
its minimum (1000ms). With the default 200ms rto_min, the backoff
shift is then capped at ilog2(1000 / 200) = 2, so the retransmission
intervals stop doubling at 200ms << 2 = 800ms. Add two more expected
DATA_FIN retransmissions at that capped interval.

Without the kernel change, the backoff keeps doubling and the 5th
retransmission arrives after ~1.6s instead of ~800ms, making the test
fail.

Link: https://lore.kernel.org/all/20260805063956.3052563-1-kalpan.jani@mpiricsoftware.com/
Signed-off-by: Kalpan Jani <kalpan.jani@mpiricsoftware.com>
---
Notes:
- This depends on the kernel patch linked above: the test fails on
  kernels without it (5th DATA_FIN retransmission at ~1.6s instead
  of ~800ms).
- Validated with the mptcp-upstream-virtme-docker environment:
  passes on a patched kernel (ipv4/ipv6/ipv4-mapped-v6), fails
  without the patch as described.

 gtests/net/mptcp/dss/dss_fin_retrans_established.pkt | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/gtests/net/mptcp/dss/dss_fin_retrans_established.pkt b/gtests/net/mptcp/dss/dss_fin_retrans_established.pkt
index d394775..73f3647 100644
--- a/gtests/net/mptcp/dss/dss_fin_retrans_established.pkt
+++ b/gtests/net/mptcp/dss/dss_fin_retrans_established.pkt
@@ -2,6 +2,10 @@
 --tolerance_usecs=200000
 `../common/defaults.sh`
 
+// tcp_rto_max_ms (set to its minimum) caps the MPTCP-level backoff at
+// rto_min << ilog2(rto_max / rto_min) = 200ms << 2 = 800ms
++0     `sysctl -wq net.ipv4.tcp_rto_max_ms=1000`
+
 +0     socket(..., SOCK_STREAM, IPPROTO_MPTCP) = 3
 +0     setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
 
@@ -16,10 +20,12 @@
 +0     close(4) = 0
 +0       >   .  1:1(0)  ack 1             <dss dack4=1 dsn8=1 ssn=0 dll=1 nocs fin, nop, nop>
 
-// wait for retransmissions
+// wait for retransmissions: the interval stops doubling at 800ms
 +0.2~+0.3 >  .  1:1(0)  ack 1             <dss dack4=1 dsn8=1 ssn=0 dll=1 nocs fin, nop, nop>
 +0.2~+0.3 >  .  1:1(0)  ack 1             <dss dack4=1 dsn8=1 ssn=0 dll=1 nocs fin, nop, nop>
 +0.4~+0.5 >  .  1:1(0)  ack 1             <dss dack4=1 dsn8=1 ssn=0 dll=1 nocs fin, nop, nop>
++0.8~+0.9 >  .  1:1(0)  ack 1             <dss dack4=1 dsn8=1 ssn=0 dll=1 nocs fin, nop, nop>
++0.8~+0.9 >  .  1:1(0)  ack 1             <dss dack4=1 dsn8=1 ssn=0 dll=1 nocs fin, nop, nop>
 
 // ACK the data_fin
 +0       <   .  2:2(0)  ack 1  win 450    <dss dack4=2 dsn8=1 ssn=0 dll=1 nocs fin, nop, nop>
-- 
2.43.0
Re: [PATCH packetdrill] mptcp: dss: validate tcp_rto_max_ms on DATA_FIN retransmissions
Posted by Matthieu Baerts 1 week, 3 days ago
Hi Kalpan,

(Note: no need to add Mat, Paolo and myself in cc: only the MPTCP ML is
enough)

On 05/08/2026 08:47, Kalpan Jani wrote:
> The kernel patch "mptcp: honour configured min/max RTO in retransmit
> paths" makes the MPTCP-level DATA_FIN retransmission backoff follow
> the tcp_rto_min_us / tcp_rto_max_ms sysctls instead of the hard-coded
> TCP_RTO_MIN / TCP_RTO_MAX constants.
> 
> Validate it in dss_fin_retrans_established.pkt: set tcp_rto_max_ms to
> its minimum (1000ms). With the default 200ms rto_min, the backoff
> shift is then capped at ilog2(1000 / 200) = 2, so the retransmission
> intervals stop doubling at 200ms << 2 = 800ms. Add two more expected
> DATA_FIN retransmissions at that capped interval.
> 
> Without the kernel change, the backoff keeps doubling and the 5th
> retransmission arrives after ~1.6s instead of ~800ms, making the test
> fail.
> 
> Link: https://lore.kernel.org/all/20260805063956.3052563-1-kalpan.jani@mpiricsoftware.com/
> Signed-off-by: Kalpan Jani <kalpan.jani@mpiricsoftware.com>
> ---
> Notes:
> - This depends on the kernel patch linked above: the test fails on
>   kernels without it (5th DATA_FIN retransmission at ~1.6s instead
>   of ~800ms).
> - Validated with the mptcp-upstream-virtme-docker environment:
>   passes on a patched kernel (ipv4/ipv6/ipv4-mapped-v6), fails
>   without the patch as described.
Thank you, it looks good to me!

Do you mind opening a PR instead, please?

https://github.com/multipath-tcp/packetdrill/

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.
Re: [PATCH packetdrill] mptcp: dss: validate tcp_rto_max_ms on DATA_FIN retransmissions
Posted by Kalpan Jani 1 week, 3 days ago
Hi Matt,

Thank you for the review!

> Do you mind opening a PR instead, please?

Sure, here it is:

https://github.com/multipath-tcp/packetdrill/pull/204

Also noted for the cc list, I will only use the MPTCP ML next time.

Cheers,
Kalpan Jani


From: Matthieu Baerts <matttbe@kernel.org>
To: "Kalpan Jani"<kalpan.jani@mpiricsoftware.com>, <mptcp@lists.linux.dev>
Cc: <shardul.b@mpiricsoftware.com>, <janak@mpiric.us>, <kalpanjani009@gmail.com>
Date: Wed, 05 Aug 2026 15:00:19 +0530
Subject: Re: [PATCH packetdrill] mptcp: dss: validate tcp_rto_max_ms on DATA_FIN retransmissions

 > Hi Kalpan,
 > 
 > (Note: no need to add Mat, Paolo and myself in cc: only the MPTCP ML is
 > enough)
 > 
 > On 05/08/2026 08:47, Kalpan Jani wrote:
 > > The kernel patch "mptcp: honour configured min/max RTO in retransmit
 > > paths" makes the MPTCP-level DATA_FIN retransmission backoff follow
 > > the tcp_rto_min_us / tcp_rto_max_ms sysctls instead of the hard-coded
 > > TCP_RTO_MIN / TCP_RTO_MAX constants.
 > > 
 > > Validate it in dss_fin_retrans_established.pkt: set tcp_rto_max_ms to
 > > its minimum (1000ms). With the default 200ms rto_min, the backoff
 > > shift is then capped at ilog2(1000 / 200) = 2, so the retransmission
 > > intervals stop doubling at 200ms << 2 = 800ms. Add two more expected
 > > DATA_FIN retransmissions at that capped interval.
 > > 
 > > Without the kernel change, the backoff keeps doubling and the 5th
 > > retransmission arrives after ~1.6s instead of ~800ms, making the test
 > > fail.
 > > 
 > > Link: https://lore.kernel.org/all/20260805063956.3052563-1-kalpan.jani@mpiricsoftware.com/
 > > Signed-off-by: Kalpan Jani <kalpan.jani@mpiricsoftware.com>
 > > ---
 > > Notes:
 > > - This depends on the kernel patch linked above: the test fails on
 > >   kernels without it (5th DATA_FIN retransmission at ~1.6s instead
 > >   of ~800ms).
 > > - Validated with the mptcp-upstream-virtme-docker environment:
 > >   passes on a patched kernel (ipv4/ipv6/ipv4-mapped-v6), fails
 > >   without the patch as described.
 > Thank you, it looks good to me!
 > 
 > Do you mind opening a PR instead, please?
 > 
 > https://github.com/multipath-tcp/packetdrill/
 > 
 > Cheers,
 > Matt
 > -- 
 > Sponsored by the NGI0 Core fund.
 > 
 >