netdev - TCP not triggering a fast retransmit?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTinJC6uS1GTbKJWL9AlEs2e5GleQvJbTUZrsQHaE@mail.gmail.com>
Date:	Wed, 30 Jun 2010 11:04:18 -0700
From:	Ivan Novick <novickivan@...il.com>
To:	netdev@...r.kernel.org
Cc:	jmatthews@...enplum.com, Tim Heath <theath@...enplum.com>
Subject: TCP not triggering a fast retransmit?

Hello all,

Attached is a packet capture from my application that is running on
RedHat Enterprise Linux 5.4

I am seeing a Retransmission timeout but I was hoping this case would
go into fast retransmit and not RTO.

I am wondering why did the sender not send more data?  If the sender
was to send more data and extend the window then it would seem the
duplicate acks or SACKS should trigger fast retransmit.

The application does not constantly send data, but data should arrive
to be sent before 200 milliseconds that it takes for the RTO.

Is it possible that there was no data to send and the window is not
advanced and the sender is waiting for an ACK.  Then data arrives half
way into the RTO 200 milliseconds while waiting for an outstanding ACK
but the window is not advanced?

You can see right after the RTO and retransmission additional data is
sent, so there is additional data.  In theory that additional data
could be arriving right at the 200 milliseconds point, but we see this
pattern in the dump regularly and I believe data is there before the
end of the 200 milliseconds RTO.

As a related point the advertised window from the receiver seems to be
a constant value of 22060, so either the receiver is handling its data
fast enough to never have to reduce its window... or this number is
really not used to indicate space available currently in the receive
window?

Any feedback to help understand why we are not doing fast retransmit
and or why the sender is not extending the window would be greatly
appreciated.

Cheers,
Ivan Novick

Download attachment "sender_backoff.cap" of type "application/octet-stream" (3076 bytes)