Re: [PATCH] tcp: fixing TLP's FIN recovery

[Per Hurtig <per.hurtig@kau.se>]

On mån  9 jun 2014 17:04:19, Eric Dumazet wrote:
> On Mon, 2014-06-09 at 16:42 +0200, Per Hurtig wrote:
>> Tried to run the script, but I don't have the "common/defaults" and the
>> test scripts from the git repository fails on all TCP tests for Linux.
>> The results I listed in the enclosed packet traces are from two real
>> machines communicating with each other (with fresh net-next kernels and
>> TLP without the zero probe check), so I tend to rely more on those
>> results.
>
> Do not top post on netdev.
>
> We at Google run about 1000 packet drill tests for any functional change
> in TCP stack. This is the only way we can scale.
>
> We are not 'studying by hand' various tcpdumps when a tool can do it
> properly.
>
> Nandita asked you give a pointer to the source code explaining how fast
> retransmit was done for this specific case, but you provided a tcpdump,
> which hardly can be reproduced and be the answer to the question.
>
> So now, we are trying to have a test to reproduce the issue and check
> the fix is complete.
>
> So far, I am not really convinced. It seems the FIN _is_ retransmitted,
> but I do not see the SACK for this RTX is properly handled in time.
>
> Its one thing checking the FIN is retransmitted, its another to check
> that the SACK will trigger sensible behavior.
>
> If you carefully check your tcpdump, you'll see there is the same
> problem, and you missed it, while packetdrill exactly pointed it.
>
> Thanks
>
>

Ok, I guess you mean that the retransmission was not fast enough? But 
will the same not happen if the original FIN is not lost and triggers a 
SACK (i.e., if the two last data segments are still lost)?

Cheers,
Per