gtests/net/mptcp/dss/dss_fin_retrans_established.pkt | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
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
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.
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. > >
© 2016 - 2026 Red Hat, Inc.