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]
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)

Powered by blists - more mailing lists