> -----Original Message----- > From: Neal Cardwell <[email protected]> > Sent: Tuesday, January 20, 2026 8:35 PM > To: Jakub Kicinski <[email protected]> > Cc: Chia-Yu Chang (Nokia) <[email protected]>; > [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; Koen De Schepper (Nokia) > <[email protected]>; [email protected]; > [email protected]; [email protected]; cheshire > <[email protected]>; [email protected]; [email protected]; Vidhi Goel > <[email protected]> > Subject: Re: [PATCH v9 net-next 15/15] selftests/net: packetdrill: add TCP > Accurate ECN cases > > > CAUTION: This is an external email. Please be very careful when clicking > links or opening attachments. See the URL nok.it/ext for additional > information. > > > > On Tue, Jan 20, 2026 at 1:53 PM Jakub Kicinski <[email protected]> wrote: > > > > On Mon, 19 Jan 2026 19:58:52 +0100 [email protected] > > wrote: > > > Linux Accurate ECN test sets using ACE counters and AccECN options > > > to cover several scenarios: Connection teardown, different ACK > > > conditions, counter wrapping, SACK space grabbing, fallback schemes, > > > negotiation retransmission/reorder/loss, AccECN option drop/loss, > > > different handshake reflectors, data with marking, and different sysctl > > > values. > > > > Thank you for closing the packetdrill side, and big thanks to Neal for > > prioritizing getting it reviewed and merged! > > > > I updated the packetdrill build in netdev CI and looks like one of the > > cases is flaking a little. Since it looks like you'll have to respin, > > please try to fix: > > > > # 1..2 > > # tcp_accecn_client_accecn_options_lost.pkt:32: error handling packet: > > timing error: expected outbound packet in relative time range > > +0.020000~+0.500000 sec but happened at +0.015816 sec # script packet: > > 0.181936 .5 1:1013(1012) ack 1 <ECN e1b 1 ceb 0 e0b 1,nop> # actual > > packet: 0.177752 .EA 1:1013(1012) ack 1 win 1050 <ECN e1b 1 ceb 0 e0b > > 1,nop> # not ok 1 ipv4 # tcp_accecn_client_accecn_options_lost.pkt:32: > > error handling packet: timing error: expected outbound packet in > > relative time range +0.020000~+0.500000 sec but happened at +0.015800 > > sec # script packet: 0.181952 .5 1:1013(1012) ack 1 <ECN e1b 1 ceb 0 > > e0b 1,nop> # actual packet: 0.177752 .EA 1:1013(1012) ack 1 win 1050 > > <ECN e1b 1 ceb 0 e0b 1,nop> # not ok 2 ipv6 # # Totals: pass:0 fail:2 > > xfail:0 xpass:0 skip:0 error:0 > > > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnetd > > ev-ctrl.bots.linux.dev%2Flogs%2Fvmksft%2Fpacketdrill%2Fresults%2F48220 > > 1%2F115-tcp-accecn-client-accecn-options-lost-pkt%2Fstdout&data=05%7C0 > > 2%7Cchia-yu.chang%40nokia-bell-labs.com%7Cf125ccafc7134b620bad08de585b > > 1a35%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C639045345459758258%7 > > CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlA > > iOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=kn3Pb > > VXw%2Bkznnf7VaYzwP%2FL3IO2LYGYQzZOWS3HRZ6w%3D&reserved=0 > > Probably this is happening because the SRTT is around 56ms: > > .050 * 7/8 + 1/8 * .1 = .05625 sec > > So the RACK fast recovery starts afte rabout 15ms due to .25 * srtt being > about 14ms: > (.050 * 7/8 + 1/8 * .1) * .25 = .0140625 sec > > If we make the SRTT 100ms then the fast retransmit should be around: > > (.1 * 7/8 + 1/8 * .1) * .25 = .025 sec > > So I'd suggest changing the timing of the SYNACK from 50ms to 100ms: > > old: > +0.05 < [ect0] SW. 0:0(0) ack 1 win 32767 <mss 1024,ECN e0b 1 ceb 0 > e1b 1,nop,nop,nop,sackOK,nop,wscale 8> > > new: > +.1 < [ect0] SW. 0:0(0) ack 1 win 32767 <mss 1024,ECN e0b 1 ceb 0 e1b > 1,nop,nop,nop,sackOK,nop,wscale 8> > > neal
Thanks Neal and Eric, I've fixed this issue as well as the concerned raised in patch 10 of listen socket. All AccECN packetdrill still pass from my end, so I will submit v10. Thanks. Chai-Yu
