Re: [PATCH] tcp: Don't fast re-transmit if only our FIN is outstanding

[Stefano Brivio <sbrivio@redhat.com>]

On Mon, 28 Sep 2026 13:31:20 +0300
Aris Konstantoulas <arist.kon@gmail.com> wrote:

> [...]
>
> Don't consider a duplicate ACK as a fast re-transmit trigger if the
> only outstanding sequence number is the FIN, and leave it to the timer.
> Fast re-transmit of data is unaffected, with or without a FIN queued
> after it.

Thanks for the investigation and for the patch, I'll review it in a bit!

Just a couple of quick (hopefully helpful) remarks for now:

> [...]
>
>     - Open question: I haven't established how a real flow first reaches
>       the state where the peer ACKs exactly up to, but not past, our FIN.

If I recall correctly, a while ago, I managed to make this happen with
a Linux kernel as peer, under memory pressure, with the receiver
updating the remaining buffer estimation right after processing a large
segment (the last data segment) that's assembled from smaller segments.

You would need a slow userspace receiver as well (maybe reading exactly
one byte after accepting the connection and then nothing else...
something like that).

In any case, I don't think it really matters to find a "natural"
reproducer of this case, I wouldn't go crazy with it, your patch looks
obviously correct to me anyway.

>	[...] This patch breaks the loop in either
>       case, but not that possible entry path. I'm happy to look into it
>       further, possibly as part of bug 125.

Wow, yes, if you could also tackle bug #125, or even a part of it, that
would be very warmly appreciated!

-- 
Stefano