On Thu, 3 Dec 2009, Arnd Hannemann wrote:

Ilpo Järvinen wrote:

[snipped]

quoted

Also, we have the another mystery to be solved, the fast retransmission is 
not triggered for some reason (or alternatively not captured in to a 
log), even in the working .9. case. It would be easy to see whether it 
works at all from TCP point of view by looking into mibs once you have 
have some transfers in a working configuration:

grep -A1 TCP /proc/net/netstat

...luckily this fast retransmit issue is less crucial as almost all people 
are pretty happy already if their RTO-based recovery works even if the 
fast recovery would not. So figuring it out can be postponed (if one has 
to prioritize) until the silent death issue is out of the way.

I looked at the working .9 case stream from 192.168.1.15 to 192.168.1.19.
I don't think it is a mystery that fast retransmit does not trigger.
The condition SACKED_DATA > 3* SMSS is simply not fulfilled.
Neither are there 3 non-continuous SACK sequences.
The segments sent are too small :-(
Interesting though, seems to me in this case non-SACK would be better than SACK.
Or did I miss something?

Yes, a particularly big one, linux does not count SACKs bytes but packets. 
In the first recovery, plenty of packets are SACKed:

    135 sack 1 {2598:2646}>
    108 sack 1 {2598:2694}>
    121 sack 1 {2598:2742}>
     95 sack 1 {2598:2790}>
    426 sack 1 {2598:2838}>

fackets_out should be 6 now which is way more than 3 which is the 
default tp->reordering.

Hey we could cook up a draft for this problem ;-)

Anyway, real problem is, RTO does not trigger...

There are two problems. ...Both are real. ;-) But significance of the 
other is much worse than the other.

-- 
 i.