TCP IPv4 strange retransmits

[Arnd Hannemann <hannemann@nets.rwth-aachen.de>]

Hi,

I'm observing some retransmits with kernel 2.6.24.2, which I don't understand.
For instance in this cutout[1] of a sequence diagram which was captured[2]
on the TCP sender, 4 retransmits are made.
According to netstat -st output[3][4] all those 4 retransmits were "fast retransmit".
But there are no three DUPACKs which I expected would be needed for fast retransmit?

Also interesting all retransmits happen _after_ those segments were
already acked and sacked, internal queuing or latency issues?

It would be great if somebody could shed some light on this,
why those segments are retransmitted.
Dumps and xplots are available here[5].

Scenario details:

192.168.0.5 <---------------\ /------------------> 192.168.0.7
	                     |
   [ tc qdisc add dev wldev root netem delay 10ms reorder 25% ]
                             |
                             |
                         192.168.0.6

192.168.0.5 establishes connection to 192.168.0.7 via 192.168.0.6.
Then bulk tcp transfer was performed from 192.168.0.5 to 192.168.0.6 for 500 ms.
Default tcp configuration of 2.6.24.2 was used (cc=cubic).


Best regards,
Arnd

[1] http://www.umic-mesh.net/~hannemann/strange-reorder/strange_reorder.png
[2] http://www.umic-mesh.net/~hannemann/strange-reorder/sender.dump
[3] http://www.umic-mesh.net/~hannemann/strange-reorder/netstat-sender.before
[4] http://www.umic-mesh.net/~hannemann/strange-reorder/netstat-sender.after
[5] http://www.umic-mesh.net/~hannemann/strange-reorder/