Re: Skyhigh retransmit times. Yearold problem still in 2.3.26

Jamie Lokier (lkd@tantalophile.demon.co.uk)
Sun, 14 Nov 1999 23:02:17 +0100

Andi Kleen wrote:
> > Not if TCP does not retry for the duration of your "connected" window,
> > say 5 minutes...
>
> It does. The retransmit timeout is clamped at 120s, when there is anything
> to send, and no timeout when there is nothing to send (except for keepalives,
> but these are only turned on by some applications)
>
> > Also, I'm not convinced TCP resets the timeouts when they are so large
> > so much as takes them back down slowly. This is useless if your
> > connection disappeared for a few minutes and then TCP takes longer than
> > you have left to recover.
>
> It does. The rtt estimate TCP keeps is independent from the retransmit
> timeout (tp->rto vs tp->srtt). The rtt estimate only changes based on
> new incoming acks, and only for ACKs where TCP knows that the packets
> causing them have not been retransmitted.

Hi Andi. Please can you explain the behaviour I get? I have a modem
which will connect for about 2 minutes at a time. Reconnecting takes
about 2 minutes also -- the callback PPP negotiation sequence is not
fast.

I connect and establish an ssh connection (which uses keepalives). All
goes well until the modem loses the connection. It always does this
just when I've typed something and the response hasn't come back. The
modem is back 2 minutes later. Of course, there is no hope of the
session continuing -- the retransmits are too far apart.

If they are clamped at 120s, should I expect to be able to continue a
session about half the time? I find about 1 in 30 sessions will
continue.

Thanks,
-- Jamie

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/