Date: Tue, 06 May 2025 14:54:00 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 286631] TCP SACK: CWND set to 2 MSS after successful SACK recovery Message-ID: <bug-286631-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D286631 Bug ID: 286631 Summary: TCP SACK: CWND set to 2 MSS after successful SACK recovery Product: Base System Version: 14.3-STABLE Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: yjaeyong@gmail.com We have observed multiple occurrences of CWND set to 2 after successful SACK recovery in the following condition - small number (2~4) of segment loss and recovered successfully with SACK - at the time of loss, CWND is limited by receiver-window - congestion-control algorithms: cubic, newreno After digging through the issue, we found the following potential issues resulting in CWND-1 issue. 1. too much shrunk pipe The issue is observed with patch: https://github.com/freebsd/freebsd-src/commit/0b3f9e435f2bde9e5be27030d9f57= 4a977a1ad47 Which makes calling post_recovery after updating snd_una to the latest ack which is very close to snd_max. And this leads to the pipe size shrunk too much as there is not much differ= ence between snd_una and snd_max. (Note that the CWND can't grow further during the recovery as the receiver-window limit which makes this pipe shrunk effect more dramatic) I understand the necessity of the patch but I think this corner case should= be addressed. Also during the investigation, I found couple more interesting observations: 2. negative value for pipe computation When calculating the pipe (tcp_compute_pipe), it takes the total-sack-rxt-b= ytes minus total-sacked-bytes.=20 For calculating the sacked-bytes in tcp_sack_doack, it actually tally up the total bytes acked from the receiver without checking if they are sack-xmit-recovered or just regular segments being delivered. When there are small number of segments loss with big inflight bytes, the s= ack block's right edge is increasing and makes sacked-bytes larger than sack-rxt-bytes which results in tcp_compute_pipe returning negative value. 3. The above negative pipe value actually impacts the post-recovery when it compares the pipe (signed) to the ssthresh (unsigned) in cubic and newreno. 4. Instable sacked-bytes calculation in tcp_sack_doack - when accounting DSACK blocks for moving snd_fack forward especially when this happens at the last packet of recovery --=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-286631-227>