Re: Bug report: tcp staled when send-q != 0, timers == 0.

Hello!

>  Im my case P-MTU discovery

Sorry, I lied. Not pmtu discovery but exaclty opposite effect
is important here: collapsing of small frames to larger ones.
Each such merge results in loss of 1 "sack" in 2.2.

>  I only wrote that it was active when got stuck. It may be idle before -
>  I do not remember, but have a habit to keep connections for weeks. :)

Good. 8)

>  As my experiments show, any connection, entering keepalive once,
>  have lose its ability to send zero probes - forever.

Exactly.

>  OK. Let us return to the "mss/mtu bug". The most mystifying thing for
>  me is the dependance of the MTU threshold on the kernel version, etc.

Well, you can reinvestigate this to get more reliable results...

Actually, this problem is so difficult that the study would be purely
academical; there is no hope to fix it in 2.2. It is partially
repaired during 2.3 and completely resolved only in 2.4.4.

>  But the question is what the minimum "reliable" MTU. There are lots of
>  situations when data comes rapidly in small packets (say, monitoring logs).
>  Is there a danger to lose such connections on a heavily loaded host?

There is no real danger. Bad things can happen only when receiver does not
read data for very long time, in this case connection times out not
receiving any acks.

What's about minimum/maximum mtu... it does not exist. F.e. if sender floods
1 byte frames in TCP_NODELAY mode and receiver does not read them, 2.2 will
fail not depending on mtu. See? Even 40 bytes of IP+TCP headers (not counting
for additional overhead) guarantee that memory will exhaust by order earlier
than receiver can close window.

Alexey