Re: [PATCH net] tcp: Fix dup-ack detection on non-SACK bidirectional data transfer.

[Guillaume Nault <gnault@redhat.com>]

On Fri, Oct 23, 2026 at 09:10:13AM -0700, Neal Cardwell wrote:
> From: Neal Cardwell <ncardwell@google.com>
> 
> I asked two different frontier LLMs to take a look at this thread, and they
> both pointed out an intertwined issue we haven't noted yet, which is that when
> an ACK advances tp->snd_una by less than 1 whole segment of the head skb in the
> retransmit queue, tcp_clean_rtx_queue() breaks out early without setting
> FLAG_ACKED. Previously, such a pure ACK relied on FLAG_WIN_UPDATE being set in
> order to have FLAG_NOT_DUP set and avoid being treated as dubious by
> tcp_ack_is_dubious() in TCP_CA_Open, and thus avoid calling
> tcp_fastretrans_alert(). If we fix the FLAG_WIN_UPDATE code in this way, then
> FLAG_WIN_UPDATE does not get set on sub-MSS ACKs, and such cases will make
> tcp_ack_is_dubious() true and we'll call tcp_fastretrans_alert().  AFAICT
> nothing serious should happen, since FLAG_SND_UNA_ADVANCED should be true and
> so num_dupack should be 0 and nothing should happen to the connection state,
> and nothing spurious should be sent. But it's performance overhead, and a
> confusing dynamic that might lead to bugs down the road.
> 
> Below is a proposed patch, cooked by a frontier LLM and lightly edited by me,
> that should factor in all these considerations. This is compiled but not yet
> tested. I will kick off some tests for it.
> 
Thanks, I've integrated this in v2.