Re: [BUG] tcp : how many times a frame can possibly be retransmitted ?

On Thu, 25 Aug 2011, Eric Dumazet wrote:

Le jeudi 25 août 2011 à 01:44 +0300, Ilpo Järvinen a écrit :

quoted

On Wed, 24 Aug 2011, Eric Dumazet wrote:

quoted

On one dev machine running net-next, I just found strange tcp sessions
that retransmit a frame forever (The other peer disappeared)

# ss -emoi dst 10.2.1.1
State      Recv-Q Send-Q      Local Address:Port          Peer Address:Port   
ESTAB      0      816              10.2.1.2:37930             10.2.1.1:ssh      timer:(on,630ms,246) ino:60786 sk:ffff8801189aa400
	 mem:(r0,w3776,f320,t0) ts sack ecn cubic wscale:8,6 rto:1680 rtt:16.25/7.5 ato:40 ssthresh:7 send 1.4Mbps rcv_rtt:10 rcv_space:16632


You can see the retransmit count : 246 

What possibly can be going on ?

What happened to backoff ?

But RTO (even without any backoffs) should be lower bounded to some not so 
zeroish value?

Apparently not.

The only thing that protect us from a flood is that ip_error() uses
inetpeer cache to ratelimit the icmp_send(ICMP_DEST_UNREACH)

This is why we get retransmit period >= 1 sec

vi +432 net/ipv4/tcp_ipv4.c

                icsk->icsk_backoff--;
                inet_csk(sk)->icsk_rto = (tp->srtt ? __tcp_set_rto(tp) :
                        TCP_TIMEOUT_INIT) << icsk->icsk_backoff;
                tcp_bound_rto(sk);

and __tcp_set_rto() uses : return (tp->srtt >> 3) + tp->rttvar;

So you think that this is not true: ?

        /* NOTE: clamping at TCP_RTO_MIN is not required, current algo
         * guarantees that rto is higher.
         */

...it would still be smaller than 1sec though, but certainly not going to 
cause flooding either. Default tcp_rto_min should be 200ms so it's 
5pkts+5ICMP sent, received and processed per second. Which doesn't sound 
that bad CPU load?!?

It is unclear to me how tp->rttvar could become smaller than 
tcp_rto_min().

-- 
 i.