What will do the TCP stack in the described scenario?

[Heinz Knocke]

Hi!

I see that I didn't explain everything clearly, and made some mistakes
so let me get through it again :))
You're right about the segment numers, but I use the same packet
numeration as tcpdump, so the last segment of the previous packet and
the first segment of the following one have the same number.

Actually I DO have such situation that client (or I should rather
say - the TCP reciever) doesn't send dupack for the packet loss, so
the server (or rather - the TCP sender) doesn't know anything about
the packet being lost and waits the whole long RTO for retransmission.

I'll give you the exact tcpdump extract to see how it works. The
output is alittle processed to make it clear, 1.445 is the TCP sender,
2.49821 the reciever.

2.542532  1.445 > 2.49821: P 3807194718:3807198814(4096) ack
1971888923 win 32768 <timestamp 8099541 8263475>
2.542541  1.445 > 2.49821: P 3807198814:3807202910(4096) ack
1971888923 win 32768 <timestamp 8099541 8263475>
2.542872  2.49821 > 1.445: . ack 3807194718 win 31744 <timestamp
8263475 8099541>
....
2.635501  2.49821 > 1.445: . ack 3807198814 win 32768 <timestamp
8263485 8099541>
....
....
....
2.956050  1.445 > 2.49821: P 3807198814:3807202910(4096) ack
1971888923 win 32768 <timestamp 8099583 8263485>


As you can see the reciever doesn't ACK segments 3807198814 to
3807202910 which are the last sent by the sender (not like I
previously wrote - packet before the last one). Could you please
explain this behaviour?
I observe this kind of behaviour on many FreeBSD systems using Samba
(newest STABLE and CURRENT sys as well) , performance is very poor
probably because of the dropping cwnd caused by RTO.

hk