Re: TCP IPv4 strange retransmits

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

Hi,

Ilpo Järvinen wrote:
> On Tue, 4 Mar 2008, Arnd Hannemann wrote:
> 
>> 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.
> 
> They don't correspond to each other?

Hmm, they should.

> 
>> 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?
> 
> With FACK it's enough that you have fackets_out > tp->reordering 
> (=dupThresh).

If it is FACK shouldn't it be accounted for LINUX_MIB_TCPFORWARDRETRANS
instead of LINUX_MIB_TCPFASTRETRANS?

> 
>> Also interesting all retransmits happen _after_ those segments were
>> already acked and sacked, internal queuing or latency issues?
> 
> I think your viewer is doing something wrong, sender.dump is not giving 
> such information (or you draw that from wrong end?). Or it just draws
> DSACK like that?

Viewer is tcptrace and xplot. So nothing special at all.
You see it also in wireshark, if you draw a sequence diagram.
You also see it in wireshark if you sort by capture timestamp. I always thought
that capture timestamp order is correct and not dump order, but maybe I'm wrong?

Tcpdump:

12:08:20.667538 IP 192.168.0.7.33824 > 192.168.0.5.50139: . ack 23485 win 22720 <nop,nop,timestamp 969759 972885,nop,nop,sack 2 {24905:26325}{27745:29165}>
^^^^^ got acked at .667538

12:08:20.646749 IP 192.168.0.5.50139 > 192.168.0.7.33824: . 22065:23485(1420) ack 1 win 2864 <nop,nop,timestamp 972885 969754>
^^^^^ got retransmitted at .646749

> 
>> It would be great if somebody could shed some light on this,
>> why those segments are retransmitted.
>> Dumps and xplots are available here[5].
> 
> ...I quickly glanced over it and found no strange behavior in
> the sender.dump.

Best regards,
Arnd