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

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

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

quoted

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.

Actual 6 SYN frames are sent. The initial one and 5 retries.

The kernel is waiting another 32 seconds for a SYN+ACK and then gives 
the ETIMEDOUT back to userspace.

Do you mean that we have to send another SYN packet after the 3 minutes?