Date: Fri, 21 Oct 2022 08:58:47 +0000 From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 265588] [TCP] - tcp send a retransmission identical sequence number packet with different payload Message-ID: <bug-265588-7501-Tys8P5v2OG@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-265588-7501@https.bugs.freebsd.org/bugzilla/> References: <bug-265588-7501@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D265588 --- Comment #22 from Richard Scheffenegger <rscheff@freebsd.org> --- (In reply to Keyong from comment #21) Do you know, what devices are on the path between your fbds NFS server and = the Linux client? As you can see, the ACKs sent by the Linux client are correct: #41 ack 109097 #44 ack 111993 #45 ack 114889 #49 ack 129369=20 #52 ack 129369 sack 132265-135161 #53 ack 129369 sack 132265-139505 #54 NFSv4 READ, ack 129369 sack 132265-139505 On the FreeBSD server, we observe: #54 ack 111993 #56 ack 129369 sack 132265-135161 #58 ack 129369 sack 132265-139505 #59 ack 109097 #60 ack 114889 #61 ack 129369=20 #64 NFSv4 READ, ack 129369 sack 132265-139505 So there is significant reordering of the ACKs going on here, with the bug being triggered by the (server) #61 ACK. I wonder if this reordering is due to a middlebox, or perhaps some Queue reordering inside of the linux box, expediting "critical" ACKs (with SACK) = over normal ACKs... --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-265588-7501-Tys8P5v2OG>