Re: [PATCH 1/1] tcp: Wrong timeout for SYN segments

On Wed, 2012-08-22 at 10:48 +0200, Alex Bergmann wrote:

On 08/22/2012 10:06 AM, Eric Dumazet wrote:

quoted

quoted

Prior to 9ad7c049 the timeout was defined with 189secs. Now we have only
a timeout of 63secs.

         ((2 << 5) - 1) * 3 secs = 189 secs
         ((2 << 5) - 1) * 1 secs = 63 secs

Strange maths ... here I have :

(1+2+4+8+16) * 3 = 93 secs
vs
(1+2+4+8+16) * 1 = 31 secs

So even before said commit, we were not rfc1122 compliant.

Using 7 retries would give 127 seconds, still not rfc compliant.

You're missing the timeout after the 5th SYN packet was sent. This 
would result in another 32 seconds (96 seconds).

The timeout is calculated here:

net/ipv4/tcp_timer.c(146:150)

	if (boundary <= linear_backoff_thresh)
		timeout = ((2 << boundary) - 1) * rto_base;
	else
		timeout = ((2 << linear_backoff_thresh) - 1) * rto_base +
			(boundary - linear_backoff_thresh) * TCP_RTO_MAX;

Thats the code yes but you miss the fact that last occurence of the
timer doesnt send a frame on the _network_

R2 is derived from the last frame sent.

Fact that the connect() is a bit long to return to user space is not
relevant. We could block the task for 2 hours and still be non RFC
compliant.

Actual 5 frames are sent, so the effective global timeout is the one I
quoted.

1 + 2 + 4 + 8 + 16   and its 31 

Just do a tcpdump and you can see it.