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

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

[Alex Bergmann]

Hi David,

I'm not 100% sure, but it looks like I found an RFC mismatch with the 
current default values of the TCP implementation.

Alex

>From 8b854a525eb45f64ad29dfab16f9d9f681e84495 Mon Sep 17 00:00:00 2001
From: Alexander Bergmann <alex@linlab.net>
Date: Wed, 22 Aug 2012 00:29:08 +0200
Subject: [PATCH 1/1] tcp: Wrong timeout for SYN segments

Commit 9ad7c049 changed the initRTO from 3secs to 1sec in accordance to
RFC6298 (former RFC2988bis). This introduced a gap with RFC1122 that
defines a minimum retransmission window for SYN segments of at least
180secs.

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

To fulfill the MUST constraint in RFC1122 section 4.2.3.5 about R2 for
SYN segments, the values of TCP_SYN_RETRIES and TCP_SYNACK_RETRIES must
be changed to 7 reties.

        ((2 << 7) - 1) * 1 secs = 255 secs

This would result in an ETIMEDOUT of 4 minutes 15 seconds.

Signed-off-by: Alexander Bergmann <alex@linlab.net>
---
 include/net/tcp.h |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/net/tcp.h b/include/net/tcp.h
index 1f000ff..7eaae19 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -98,10 +98,10 @@ extern void tcp_time_wait(struct sock *sk, int state, int timeo);
                                 * 15 is ~13-30min depending on RTO.
                                 */
 
-#define TCP_SYN_RETRIES         5      /* number of times to retry active opening a
+#define TCP_SYN_RETRIES         7      /* number of times to retry active opening a
                                 * connection: ~180sec is RFC minimum   */
 
-#define TCP_SYNACK_RETRIES 5   /* number of times to retry passive opening a
+#define TCP_SYNACK_RETRIES 7   /* number of times to retry passive opening a
                                 * connection: ~180sec is RFC minimum   */
 
 #define TCP_TIMEWAIT_LEN (60*HZ) /* how long to wait to destroy TIME-WAIT
-- 
1.7.8.6

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

[Eric Dumazet]

On Wed, 2012-08-22 at 01:29 +0200, Alex Bergmann wrote:
> Hi David,
> 
> I'm not 100% sure, but it looks like I found an RFC mismatch with the 
> current default values of the TCP implementation.
> 
> Alex
> 
> From 8b854a525eb45f64ad29dfab16f9d9f681e84495 Mon Sep 17 00:00:00 2001
> From: Alexander Bergmann <alex@linlab.net>
> Date: Wed, 22 Aug 2012 00:29:08 +0200
> Subject: [PATCH 1/1] tcp: Wrong timeout for SYN segments
> 
> Commit 9ad7c049 changed the initRTO from 3secs to 1sec in accordance to
> RFC6298 (former RFC2988bis). This introduced a gap with RFC1122 that
> defines a minimum retransmission window for SYN segments of at least
> 180secs.
> 
> 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.

> 
> To fulfill the MUST constraint in RFC1122 section 4.2.3.5 about R2 for
> SYN segments, the values of TCP_SYN_RETRIES and TCP_SYNACK_RETRIES must
> be changed to 7 reties.
> 
>         ((2 << 7) - 1) * 1 secs = 255 secs
> 
> This would result in an ETIMEDOUT of 4 minutes 15 seconds.
> 
> Signed-off-by: Alexander Bergmann <alex@linlab.net>
> ---
>  include/net/tcp.h |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/include/net/tcp.h b/include/net/tcp.h
> index 1f000ff..7eaae19 100644
> --- a/include/net/tcp.h
> +++ b/include/net/tcp.h
> @@ -98,10 +98,10 @@ extern void tcp_time_wait(struct sock *sk, int state, int timeo);
>                                  * 15 is ~13-30min depending on RTO.
>                                  */
>  
> -#define TCP_SYN_RETRIES         5      /* number of times to retry active opening a
> +#define TCP_SYN_RETRIES         7      /* number of times to retry active opening a
>                                  * connection: ~180sec is RFC minimum   */
>  
> -#define TCP_SYNACK_RETRIES 5   /* number of times to retry passive opening a
> +#define TCP_SYNACK_RETRIES 7   /* number of times to retry passive opening a
>                                  * connection: ~180sec is RFC minimum   */
>  
>  #define TCP_TIMEWAIT_LEN (60*HZ) /* how long to wait to destroy TIME-WAIT

Nice catch !

I kind of disagree with the SYNACK part.

RFC 1122 says in 4.2.3.5 :

  However, the values of R1 and R2 may be different for SYN
  and data segments.  In particular, R2 for a SYN segment MUST
  be set large enough to provide retransmission of the segment
  for at least 3 minutes.  The application can close the
  connection (i.e., give up on the open attempt) sooner, of
  course.

I am not sure SYNACK segments were considered as a 'SYN segment' in this
section. (as the application cannot 'close' the connection on the passive
side, only kernel is aware of a SYN_RECV socket)

Increasing TCP_SYNACK_RETRIES from 5 to 7 or 8 amplifies the
SYN/synflood problem.

A valid client should retransmit its SYN packet for 180 seconds, I dont
believe we should make sure the SYNACK will be sent for 180 seconds as
well.

If we _really_ want to have a 3 minutes R2 for SYNACK, I suggest
changing things to that we dont send more than 5 SYNACKS, maybe using
RTO=6 after one retransmit

current situation :
1 sec
2 sec
4 sec
8 sec
16 sec
----
total of 31 seconds


1 sec
12 sec  // switch to RTO = 6
24 sec
48 sec
96 sec
-----
total of 181 seconds

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

[Alex Bergmann]

On 08/22/2012 10:06 AM, Eric Dumazet wrote:
>> 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;

> 
>>
>> To fulfill the MUST constraint in RFC1122 section 4.2.3.5 about R2 for
>> SYN segments, the values of TCP_SYN_RETRIES and TCP_SYNACK_RETRIES must
>> be changed to 7 reties.
>>
>>          ((2 << 7) - 1) * 1 secs = 255 secs
>>
>> This would result in an ETIMEDOUT of 4 minutes 15 seconds.
>>
>> Signed-off-by: Alexander Bergmann <alex@linlab.net>
>> ---
>>   include/net/tcp.h |    4 ++--
>>   1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/net/tcp.h b/include/net/tcp.h
>> index 1f000ff..7eaae19 100644
>> --- a/include/net/tcp.h
>> +++ b/include/net/tcp.h
>> @@ -98,10 +98,10 @@ extern void tcp_time_wait(struct sock *sk, int state, int timeo);
>>                                   * 15 is ~13-30min depending on RTO.
>>                                   */
>>   
>> -#define TCP_SYN_RETRIES         5      /* number of times to retry active opening a
>> +#define TCP_SYN_RETRIES         7      /* number of times to retry active opening a
>>                                   * connection: ~180sec is RFC minimum   */
>>   
>> -#define TCP_SYNACK_RETRIES 5   /* number of times to retry passive opening a
>> +#define TCP_SYNACK_RETRIES 7   /* number of times to retry passive opening a
>>                                   * connection: ~180sec is RFC minimum   */
>>   
>>   #define TCP_TIMEWAIT_LEN (60*HZ) /* how long to wait to destroy TIME-WAIT
> 
> Nice catch !
> 
> I kind of disagree with the SYNACK part.

I will look into this. 

> RFC 1122 says in 4.2.3.5 :
> 
>    However, the values of R1 and R2 may be different for SYN
>    and data segments.  In particular, R2 for a SYN segment MUST
>    be set large enough to provide retransmission of the segment
>    for at least 3 minutes.  The application can close the
>    connection (i.e., give up on the open attempt) sooner, of
>    course.
> 
> I am not sure SYNACK segments were considered as a 'SYN segment' in this
> section. (as the application cannot 'close' the connection on the passive
> side, only kernel is aware of a SYN_RECV socket)
> 
> Increasing TCP_SYNACK_RETRIES from 5 to 7 or 8 amplifies the
> SYN/synflood problem.
> 
> A valid client should retransmit its SYN packet for 180 seconds, I dont
> believe we should make sure the SYNACK will be sent for 180 seconds as
> well.
> 
> If we _really_ want to have a 3 minutes R2 for SYNACK, I suggest
> changing things to that we dont send more than 5 SYNACKS, maybe using
> RTO=6 after one retransmit
> 
> current situation :
> 1 sec
> 2 sec
> 4 sec
> 8 sec
> 16 sec
> ----
> total of 31 seconds
> 
> 
> 1 sec
> 12 sec  // switch to RTO = 6
> 24 sec
> 48 sec
> 96 sec
> -----
> total of 181 seconds
> 
> 
> 

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

[Eric Dumazet]

On Wed, 2012-08-22 at 10:48 +0200, Alex Bergmann wrote:
> On 08/22/2012 10:06 AM, Eric Dumazet wrote:
> >> 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.

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

[Alex Bergmann]

On 08/22/2012 10:58 AM, Eric Dumazet wrote:
> On Wed, 2012-08-22 at 10:48 +0200, Alex Bergmann wrote:
>> On 08/22/2012 10:06 AM, Eric Dumazet wrote:
>>>> 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?

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

[Eric Dumazet]

On Wed, 2012-08-22 at 11:29 +0200, Alex Bergmann wrote:

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

first one had a t0 + 0 delay. How can it count ???

> 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?
> 

First SYN is not a retransmit

R2 = time_of_last_SYN - time_of_initial_SYN (t0) = 31

If you read RFC it states :

"In particular, R2 for a SYN segment MUST
 be set large enough to provide retransmission of the segment
 for at least 3 minutes."


That means that the last _retransmit_ MUST happen after 180 seconds.

And not :

Send all the restransmits at t0 + 1, then wait 180 seconds before giving
connect() a timeout indication.

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

[Eric Dumazet]

On Wed, 2012-08-22 at 12:00 +0200, Eric Dumazet wrote:
> On Wed, 2012-08-22 at 11:29 +0200, Alex Bergmann wrote:
> 
> > Actual 6 SYN frames are sent. The initial one and 5 retries.
> > 
> 
> first one had a t0 + 0 delay. How can it count ???
> 
> > 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?
> > 
> 
> First SYN is not a retransmit
> 
> R2 = time_of_last_SYN - time_of_initial_SYN (t0) = 31
> 
> If you read RFC it states :
> 
> "In particular, R2 for a SYN segment MUST
>  be set large enough to provide retransmission of the segment
>  for at least 3 minutes."
> 
> 
> That means that the last _retransmit_ MUST happen after 180 seconds.
> 
> And not :
> 
> Send all the restransmits at t0 + 1, then wait 180 seconds before giving
> connect() a timeout indication.
> 
> 

Therefore, the minimal connect() timeout should be : 180 + 100 seconds

(allowing 100 seconds for the SYNACKs sent in answer of the very last
retransmit to come back)

(100 seconds is the R2 for non SYN frames)

RFC quote : The value of R2 SHOULD
            correspond to at least 100 seconds. 

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

[H.K. Jerry Chu]

On Tue, Aug 21, 2012 at 4:29 PM, Alex Bergmann <alex@linlab.net> wrote:
> Hi David,
>
> I'm not 100% sure, but it looks like I found an RFC mismatch with the
> current default values of the TCP implementation.
>
> Alex
>
> From 8b854a525eb45f64ad29dfab16f9d9f681e84495 Mon Sep 17 00:00:00 2001
> From: Alexander Bergmann <alex@linlab.net>
> Date: Wed, 22 Aug 2012 00:29:08 +0200
> Subject: [PATCH 1/1] tcp: Wrong timeout for SYN segments
>
> Commit 9ad7c049 changed the initRTO from 3secs to 1sec in accordance to
> RFC6298 (former RFC2988bis). This introduced a gap with RFC1122 that
> defines a minimum retransmission window for SYN segments of at least
> 180secs.
>
> 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
>
> To fulfill the MUST constraint in RFC1122 section 4.2.3.5 about R2 for
> SYN segments, the values of TCP_SYN_RETRIES and TCP_SYNACK_RETRIES must
> be changed to 7 reties.
>
>         ((2 << 7) - 1) * 1 secs = 255 secs
>
> This would result in an ETIMEDOUT of 4 minutes 15 seconds.

This issue occurred to me right after I submitted the patch for RFC6298.
I did not commit any more change because RFC compliance aside, 180secs
just seem like eternity in the Internet age.

(See my past post on this at
http://marc.info/?l=linux-netdev&m=130759078118866&w=2)

Jerry

>
> Signed-off-by: Alexander Bergmann <alex@linlab.net>
> ---
>  include/net/tcp.h |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/net/tcp.h b/include/net/tcp.h
> index 1f000ff..7eaae19 100644
> --- a/include/net/tcp.h
> +++ b/include/net/tcp.h
> @@ -98,10 +98,10 @@ extern void tcp_time_wait(struct sock *sk, int state, int timeo);
>                                  * 15 is ~13-30min depending on RTO.
>                                  */
>
> -#define TCP_SYN_RETRIES         5      /* number of times to retry active opening a
> +#define TCP_SYN_RETRIES         7      /* number of times to retry active opening a
>                                  * connection: ~180sec is RFC minimum   */
>
> -#define TCP_SYNACK_RETRIES 5   /* number of times to retry passive opening a
> +#define TCP_SYNACK_RETRIES 7   /* number of times to retry passive opening a
>                                  * connection: ~180sec is RFC minimum   */
>
>  #define TCP_TIMEWAIT_LEN (60*HZ) /* how long to wait to destroy TIME-WAIT
> --
> 1.7.8.6
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[H.K. Jerry Chu]

On Wed, Aug 22, 2012 at 3:03 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Wed, 2012-08-22 at 12:00 +0200, Eric Dumazet wrote:
>> On Wed, 2012-08-22 at 11:29 +0200, Alex Bergmann wrote:
>>
>> > Actual 6 SYN frames are sent. The initial one and 5 retries.
>> >
>>
>> first one had a t0 + 0 delay. How can it count ???
>>
>> > 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?
>> >
>>
>> First SYN is not a retransmit
>>
>> R2 = time_of_last_SYN - time_of_initial_SYN (t0) = 31
>>
>> If you read RFC it states :
>>
>> "In particular, R2 for a SYN segment MUST
>>  be set large enough to provide retransmission of the segment
>>  for at least 3 minutes."
>>
>>
>> That means that the last _retransmit_ MUST happen after 180 seconds.
>>
>> And not :
>>
>> Send all the restransmits at t0 + 1, then wait 180 seconds before giving
>> connect() a timeout indication.
>>
>>
>
> Therefore, the minimal connect() timeout should be : 180 + 100 seconds
>
> (allowing 100 seconds for the SYNACKs sent in answer of the very last
> retransmit to come back)
>
> (100 seconds is the R2 for non SYN frames)
>
> RFC quote : The value of R2 SHOULD
>             correspond to at least 100 seconds.

I agree if you take RFC1122 literally the last retransmission must
happen no less than 3 minutes from the 1st SYN... Oh actually it'd be
3 minutes plus initRTO because the 3 minutes applies only to
"retransmission" as in

"R2 for a SYN segment MUST be set large enough to provide retransmission
of the segment for at least 3 minutes.:

But IMHO 6 retries providing 1+2+4+8+16+32 = 63 secs retransmission plus
64 secs wait time totaling 127 secs is really plenty enough.

You have a good point on SYN-ACK.

Jerry

>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Alex Bergmann]

On 08/22/2012 06:41 PM, H.K. Jerry Chu wrote:
> On Tue, Aug 21, 2012 at 4:29 PM, Alex Bergmann <alex@linlab.net
> <mailto:alex@linlab.net>> wrote:
>
>     Hi David,
>
>     I'm not 100% sure, but it looks like I found an RFC mismatch with the
>     current default values of the TCP implementation.
>
>     Alex
>
>      From 8b854a525eb45f64ad29dfab16f9d9f681e84495 Mon Sep 17 00:00:00 2001
>     From: Alexander Bergmann <alex@linlab.net <mailto:alex@linlab.net>>
>     Date: Wed, 22 Aug 2012 00:29:08 +0200
>     Subject: [PATCH 1/1] tcp: Wrong timeout for SYN segments
>
>     Commit 9ad7c049 changed the initRTO from 3secs to 1sec in accordance to
>     RFC6298 (former RFC2988bis). This introduced a gap with RFC1122 that
>     defines a minimum retransmission window for SYN segments of at least
>     180secs.
>
>     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
>
>     To fulfill the MUST constraint in RFC1122 section 4.2.3.5 about R2 for
>     SYN segments, the values of TCP_SYN_RETRIES and TCP_SYNACK_RETRIES must
>     be changed to 7 reties.
>
>              ((2 << 7) - 1) * 1 secs = 255 secs
>
>     This would result in an ETIMEDOUT of 4 minutes 15 seconds.
>
>
> This issue occurred to me right after I submitted the patch for RFC6298.
> I did not commit any more change because RFC compliance aside, 180secs
> just seem like eternity in the Internet age.
>
> (See my past post on this at
> http://marc.info/?l=linux-netdev&m=130759078118866&w=2)

Okay, I missed that post during my search about the current situation.

Thanks,
Alex


> Jerry
>
>
>     Signed-off-by: Alexander Bergmann <alex@linlab.net
>     <mailto:alex@linlab.net>>
>     ---
>       include/net/tcp.h |    4 ++--
>       1 files changed, 2 insertions(+), 2 deletions(-)
>
>     diff --git a/include/net/tcp.h b/include/net/tcp.h
>     index 1f000ff..7eaae19 100644
>     --- a/include/net/tcp.h
>     +++ b/include/net/tcp.h
>     @@ -98,10 +98,10 @@ extern void tcp_time_wait(struct sock *sk, int
>     state, int timeo);
>                                       * 15 is ~13-30min depending on RTO.
>                                       */
>
>     -#define TCP_SYN_RETRIES         5      /* number of times to retry
>     active opening a
>     +#define TCP_SYN_RETRIES         7      /* number of times to retry
>     active opening a
>                                       * connection: ~180sec is RFC
>     minimum   */
>
>     -#define TCP_SYNACK_RETRIES 5   /* number of times to retry passive
>     opening a
>     +#define TCP_SYNACK_RETRIES 7   /* number of times to retry passive
>     opening a
>                                       * connection: ~180sec is RFC
>     minimum   */
>
>       #define TCP_TIMEWAIT_LEN (60*HZ) /* how long to wait to destroy
>     TIME-WAIT
>     --
>     1.7.8.6
>
>     --
>     To unsubscribe from this list: send the line "unsubscribe netdev" in
>     the body of a message to majordomo@vger.kernel.org
>     <mailto:majordomo@vger.kernel.org>
>     More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>


-- 
|. _ | _ |_   _  _ _|_
||| ||(_||_).| |(/_ |
email/sip/xmpp: alex@linlab.net
phone/enum: +49 2871 2355378

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

[Eric Dumazet]

On Thu, 2012-08-23 at 13:58 +0200, Alex Bergmann wrote:
> On 08/22/2012 06:41 PM, H.K. Jerry Chu wrote:

> > This issue occurred to me right after I submitted the patch for RFC6298.
> > I did not commit any more change because RFC compliance aside, 180secs
> > just seem like eternity in the Internet age.
> >
> > (See my past post on this at
> > http://marc.info/?l=linux-netdev&m=130759078118866&w=2)
> 
> Okay, I missed that post during my search about the current situation.

I would suggest to increase TCP_SYN_RETRIES from 5 to 6.

180 secs is eternity, but 31 secs is too small.

Can you repost a v2, only changing TCP_SYN_RETRIES ?

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

[David Laight]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 438 bytes --]

> I would suggest to increase TCP_SYN_RETRIES from 5 to 6.
> 
> 180 secs is eternity, but 31 secs is too small.

Wasn't the intention of the long delay to allow a system
acting as a router to reboot?
I suspect that is why it (and some other TCP timers)
are in minutes.

	David

ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

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

[Alex Bergmann]

On 08/23/2012 02:15 PM, Eric Dumazet wrote:
> On Thu, 2012-08-23 at 13:58 +0200, Alex Bergmann wrote:
>> On 08/22/2012 06:41 PM, H.K. Jerry Chu wrote:
> 
>>> This issue occurred to me right after I submitted the patch for RFC6298.
>>> I did not commit any more change because RFC compliance aside, 180secs
>>> just seem like eternity in the Internet age.
>>>
>>> (See my past post on this at
>>> http://marc.info/?l=linux-netdev&m=130759078118866&w=2)
>>
>> Okay, I missed that post during my search about the current situation.
> 
> I would suggest to increase TCP_SYN_RETRIES from 5 to 6.
> 
> 180 secs is eternity, but 31 secs is too small.
> 
> Can you repost a v2, only changing TCP_SYN_RETRIES ?

I hope the description is good enough.

Alex


>From be551f82499112e4775b6d579d58967510b6d492 Mon Sep 17 00:00:00 2001
From: Alexander Bergmann <alex@linlab.net>
Date: Thu, 23 Aug 2012 14:33:35 +0200
Subject: [PATCH 1/1] tcp: Increase timeout for SYN segments

Commit 9ad7c049 changed the initRTO from 3secs to 1sec in accordance to
RFC6298 (former RFC2988bis). This reduced the time till the last SYN
retransmission packet gets sent from 93secs to 31secs.

RFC1122 is stating that the retransmission should be done for at least 3
minutes, but this seems to be quite high.[1]

This patch increases the value of TCP_SYN_RETRIES to the value of 6,
providing a retransmission window of 63secs.

[1] RFC 1122 - 4.2.3.5 TCP Connection Failures

Signed-off-by: Alexander Bergmann <alex@linlab.net>
---
 include/net/tcp.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/include/net/tcp.h b/include/net/tcp.h
index 1f000ff..f309e93 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -98,7 +98,7 @@ extern void tcp_time_wait(struct sock *sk, int state, int timeo);
                                 * 15 is ~13-30min depending on RTO.
                                 */
 
-#define TCP_SYN_RETRIES         5      /* number of times to retry active opening a
+#define TCP_SYN_RETRIES         6      /* number of times to retry active opening a
                                 * connection: ~180sec is RFC minimum   */
 
 #define TCP_SYNACK_RETRIES 5   /* number of times to retry passive opening a
-- 
1.7.8.6

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

[Eric Dumazet]

On Thu, 2012-08-23 at 14:37 +0200, Alex Bergmann wrote:

> 
> From be551f82499112e4775b6d579d58967510b6d492 Mon Sep 17 00:00:00 2001
> From: Alexander Bergmann <alex@linlab.net>
> Date: Thu, 23 Aug 2012 14:33:35 +0200
> Subject: [PATCH 1/1] tcp: Increase timeout for SYN segments
> 
> Commit 9ad7c049 changed the initRTO from 3secs to 1sec in accordance to
> RFC6298 (former RFC2988bis). This reduced the time till the last SYN
> retransmission packet gets sent from 93secs to 31secs.
> 
> RFC1122 is stating that the retransmission should be done for at least 3
> minutes, but this seems to be quite high.[1]
> 
> This patch increases the value of TCP_SYN_RETRIES to the value of 6,
> providing a retransmission window of 63secs.
> 
> [1] RFC 1122 - 4.2.3.5 TCP Connection Failures
> 
> Signed-off-by: Alexander Bergmann <alex@linlab.net>
> ---
>  include/net/tcp.h |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/include/net/tcp.h b/include/net/tcp.h
> index 1f000ff..f309e93 100644
> --- a/include/net/tcp.h
> +++ b/include/net/tcp.h
> @@ -98,7 +98,7 @@ extern void tcp_time_wait(struct sock *sk, int state, int timeo);
>                                  * 15 is ~13-30min depending on RTO.
>                                  */
>  
> -#define TCP_SYN_RETRIES         5      /* number of times to retry active opening a
> +#define TCP_SYN_RETRIES         6      /* number of times to retry active opening a
>                                  * connection: ~180sec is RFC minimum   */
>  
>  #define TCP_SYNACK_RETRIES 5   /* number of times to retry passive opening a

Acked-by: Eric Dumazet <edumazet@google.com>

A change of the comment might be good, to help future readers.

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

[Eric Dumazet]

On Thu, 2012-08-23 at 13:35 +0100, David Laight wrote:
> > I would suggest to increase TCP_SYN_RETRIES from 5 to 6.
> > 
> > 180 secs is eternity, but 31 secs is too small.
> 
> Wasn't the intention of the long delay to allow a system
> acting as a router to reboot?
> I suspect that is why it (and some other TCP timers)
> are in minutes.

One could argue that if an application really wants to connect to a
peer, it should probably handle failures and retries.

But for unaware (basic ?) applications, the 3 -> 1 change reduced by a 3
factor the timeout. So a transient network failure has now more
chance to impact them.

Not all applications run inside a browser or under human control...

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

[Alex Bergmann]

> 
> Acked-by: Eric Dumazet <edumazet@google.com>
> 
> A change of the comment might be good, to help future readers.
> 

Okay, I've also changed the comments of SYN and SYNACK retries. 

Alex

>From 11a292b1cff772f930a02fda02d5b741f8ea5033 Mon Sep 17 00:00:00 2001
From: Alexander Bergmann <alex@linlab.net>
Date: Fri, 24 Aug 2012 14:09:49 +0200
Subject: [PATCH 1/1] tcp: Increase timeout for SYN segments

Commit 9ad7c049 changed the initRTO from 3secs to 1sec in accordance to
RFC6298 (former RFC2988bis). This reduced the time till the last SYN
retransmission packet gets sent from 93secs to 31secs.

RFC1122 is stating that the retransmission should be done for at least 3
minutes, but this seems to be quite high.

  "However, the values of R1 and R2 may be different for SYN
  and data segments.  In particular, R2 for a SYN segment MUST
  be set large enough to provide retransmission of the segment
  for at least 3 minutes.  The application can close the
  connection (i.e., give up on the open attempt) sooner, of
  course."

This patch increases the value of TCP_SYN_RETRIES to the value of 6,
providing a retransmission window of 63secs.

The comments for SYN and SYNACK retries have also been updated to
describe the current settings.

Signed-off-by: Alexander Bergmann <alex@linlab.net>
---
 include/net/tcp.h |   18 ++++++++++++++----
 1 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/include/net/tcp.h b/include/net/tcp.h
index 1f000ff..d43d6b3 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -98,11 +98,21 @@ extern void tcp_time_wait(struct sock *sk, int state, int timeo);
                                 * 15 is ~13-30min depending on RTO.
                                 */
 
-#define TCP_SYN_RETRIES         5      /* number of times to retry active opening a
-                                * connection: ~180sec is RFC minimum   */
+#define TCP_SYN_RETRIES         6      /*
+                                * This is how many retries it does to active
+                                * opening a connection.
+                                * RFC1122 says the minimum retry MUST be at
+                                * least 180secs. Nevertheless this value is
+                                * corresponding to 63secs of retransmission
+                                * with the current initial RTO.
+                                */
 
-#define TCP_SYNACK_RETRIES 5   /* number of times to retry passive opening a
-                                * connection: ~180sec is RFC minimum   */
+#define TCP_SYNACK_RETRIES 5   /* 
+                                * This is how may retries it does to passive
+                                * opening a connection. 
+                                * This is corresponding to 31secs of 
+                                * retransmission with the current initial RTO.
+                                */
 
 #define TCP_TIMEWAIT_LEN (60*HZ) /* how long to wait to destroy TIME-WAIT
                                  * state, about 60 seconds     */
-- 
1.7.8.6

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

[David Miller]

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 23 Aug 2012 14:49:45 +0200

> On Thu, 2012-08-23 at 14:37 +0200, Alex Bergmann wrote:
> 
>> 
>> From be551f82499112e4775b6d579d58967510b6d492 Mon Sep 17 00:00:00 2001
>> From: Alexander Bergmann <alex@linlab.net>
>> Date: Thu, 23 Aug 2012 14:33:35 +0200
>> Subject: [PATCH 1/1] tcp: Increase timeout for SYN segments
>> 
>> Commit 9ad7c049 changed the initRTO from 3secs to 1sec in accordance to
>> RFC6298 (former RFC2988bis). This reduced the time till the last SYN
>> retransmission packet gets sent from 93secs to 31secs.
>> 
>> RFC1122 is stating that the retransmission should be done for at least 3
>> minutes, but this seems to be quite high.[1]
>> 
>> This patch increases the value of TCP_SYN_RETRIES to the value of 6,
>> providing a retransmission window of 63secs.
>> 
>> [1] RFC 1122 - 4.2.3.5 TCP Connection Failures
>> 
>> Signed-off-by: Alexander Bergmann <alex@linlab.net>
>> ---
>>  include/net/tcp.h |    2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>> 
>> diff --git a/include/net/tcp.h b/include/net/tcp.h
>> index 1f000ff..f309e93 100644
>> --- a/include/net/tcp.h
>> +++ b/include/net/tcp.h
>> @@ -98,7 +98,7 @@ extern void tcp_time_wait(struct sock *sk, int state, int timeo);
>>                                  * 15 is ~13-30min depending on RTO.
>>                                  */
>>  
>> -#define TCP_SYN_RETRIES         5      /* number of times to retry active opening a
>> +#define TCP_SYN_RETRIES         6      /* number of times to retry active opening a
>>                                  * connection: ~180sec is RFC minimum   */
>>  
>>  #define TCP_SYNACK_RETRIES 5   /* number of times to retry passive opening a
> 
> Acked-by: Eric Dumazet <edumazet@google.com>
> 
> A change of the comment might be good, to help future readers.

Alex, this patch doesn't apply, it was completely corrupted by your email
client.

Make a fresh submission, with this fixed.  But before you do, email the
patch to yourself and make sure you can actually apply the patch you
receive in your inbox.  Because that's exactly what I'm going to have
to do.

Thanks.

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

[Alexander Bergmann]

On Fri, Aug 24, 2012 at 01:42:31PM -0400, David Miller wrote:
> Alex, this patch doesn't apply, it was completely corrupted by your email
> client.
> 
> Make a fresh submission, with this fixed.  But before you do, email the
> patch to yourself and make sure you can actually apply the patch you
> receive in your inbox.  Because that's exactly what I'm going to have
> to do.

Sorry I messed it up the last time. This time I've double checked as 
you suggested. I'll keep that in mind.

>From 11a292b1cff772f930a02fda02d5b741f8ea5033 Mon Sep 17 00:00:00 2001
From: Alexander Bergmann <alex@linlab.net>
Date: Fri, 24 Aug 2012 14:09:49 +0200
Subject: [PATCH 1/1] tcp: Increase timeout for SYN segments

Commit 9ad7c049 changed the initRTO from 3secs to 1sec in accordance to
RFC6298 (former RFC2988bis). This reduced the time till the last SYN
retransmission packet gets sent from 93secs to 31secs.

RFC1122 is stating that the retransmission should be done for at least 3
minutes, but this seems to be quite high.

  "However, the values of R1 and R2 may be different for SYN
  and data segments.  In particular, R2 for a SYN segment MUST
  be set large enough to provide retransmission of the segment
  for at least 3 minutes.  The application can close the
  connection (i.e., give up on the open attempt) sooner, of
  course."

This patch increases the value of TCP_SYN_RETRIES to the value of 6,
providing a retransmission window of 63secs.

The comments for SYN and SYNACK retries have also been updated to
describe the current settings.

Signed-off-by: Alexander Bergmann <alex@linlab.net>
---
 include/net/tcp.h |   18 ++++++++++++++----
 1 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/include/net/tcp.h b/include/net/tcp.h
index 1f000ff..d43d6b3 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -98,11 +98,21 @@ extern void tcp_time_wait(struct sock *sk, int state, int timeo);
 				 * 15 is ~13-30min depending on RTO.
 				 */
 
-#define TCP_SYN_RETRIES	 5	/* number of times to retry active opening a
-				 * connection: ~180sec is RFC minimum	*/
+#define TCP_SYN_RETRIES	 6	/*
+				 * This is how many retries it does to active
+				 * opening a connection.
+				 * RFC1122 says the minimum retry MUST be at
+				 * least 180secs. Nevertheless this value is
+				 * corresponding to 63secs of retransmission
+				 * with the current initial RTO.
+				 */
 
-#define TCP_SYNACK_RETRIES 5	/* number of times to retry passive opening a
-				 * connection: ~180sec is RFC minimum	*/
+#define TCP_SYNACK_RETRIES 5	/* 
+				 * This is how may retries it does to passive
+				 * opening a connection. 
+				 * This is corresponding to 31secs of 
+				 * retransmission with the current initial RTO.
+				 */
 
 #define TCP_TIMEWAIT_LEN (60*HZ) /* how long to wait to destroy TIME-WAIT
 				  * state, about 60 seconds	*/
-- 
1.7.8.6

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

[Eric Dumazet]

> From: Alexander Bergmann <alex@linlab.net>
> Date: Fri, 24 Aug 2012 14:09:49 +0200
> Subject: [PATCH 1/1] tcp: Increase timeout for SYN segments
> 
> Commit 9ad7c049 changed the initRTO from 3secs to 1sec in accordance to
> RFC6298 (former RFC2988bis). This reduced the time till the last SYN
> retransmission packet gets sent from 93secs to 31secs.
> 
> RFC1122 is stating that the retransmission should be done for at least 3
> minutes, but this seems to be quite high.
> 
>   "However, the values of R1 and R2 may be different for SYN
>   and data segments.  In particular, R2 for a SYN segment MUST
>   be set large enough to provide retransmission of the segment
>   for at least 3 minutes.  The application can close the
>   connection (i.e., give up on the open attempt) sooner, of
>   course."
> 
> This patch increases the value of TCP_SYN_RETRIES to the value of 6,
> providing a retransmission window of 63secs.
> 
> The comments for SYN and SYNACK retries have also been updated to
> describe the current settings.
> 
> Signed-off-by: Alexander Bergmann <alex@linlab.net>
> ---

Acked-by: Eric Dumazet <edumazet@google.com>

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

[Carsten Wolff]

Hi,

On Saturday 25 August 2012, Alexander Bergmann wrote:
> This patch increases the value of TCP_SYN_RETRIES to the value of 6,
> providing a retransmission window of 63secs.
> 
> The comments for SYN and SYNACK retries have also been updated to
> describe the current settings.

wouldn't it be nice, if the description of the corresponding sysctls in 
Documentation/networking/ip-sysctl.txt could be updated too?

Cheers
Carsten

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

[H.K. Jerry Chu]

On Sat, Aug 25, 2012 at 1:48 AM, Alexander Bergmann <alex@linlab.net> wrote:
> On Fri, Aug 24, 2012 at 01:42:31PM -0400, David Miller wrote:
>> Alex, this patch doesn't apply, it was completely corrupted by your email
>> client.
>>
>> Make a fresh submission, with this fixed.  But before you do, email the
>> patch to yourself and make sure you can actually apply the patch you
>> receive in your inbox.  Because that's exactly what I'm going to have
>> to do.
>
> Sorry I messed it up the last time. This time I've double checked as
> you suggested. I'll keep that in mind.
>
> From 11a292b1cff772f930a02fda02d5b741f8ea5033 Mon Sep 17 00:00:00 2001
> From: Alexander Bergmann <alex@linlab.net>
> Date: Fri, 24 Aug 2012 14:09:49 +0200
> Subject: [PATCH 1/1] tcp: Increase timeout for SYN segments
>
> Commit 9ad7c049 changed the initRTO from 3secs to 1sec in accordance to
> RFC6298 (former RFC2988bis). This reduced the time till the last SYN
> retransmission packet gets sent from 93secs to 31secs.
>
> RFC1122 is stating that the retransmission should be done for at least 3
> minutes, but this seems to be quite high.
>
>   "However, the values of R1 and R2 may be different for SYN
>   and data segments.  In particular, R2 for a SYN segment MUST
>   be set large enough to provide retransmission of the segment
>   for at least 3 minutes.  The application can close the
>   connection (i.e., give up on the open attempt) sooner, of
>   course."
>
> This patch increases the value of TCP_SYN_RETRIES to the value of 6,
> providing a retransmission window of 63secs.
>
> The comments for SYN and SYNACK retries have also been updated to
> describe the current settings.
>
> Signed-off-by: Alexander Bergmann <alex@linlab.net>
> ---
>  include/net/tcp.h |   18 ++++++++++++++----
>  1 files changed, 14 insertions(+), 4 deletions(-)
>
> diff --git a/include/net/tcp.h b/include/net/tcp.h
> index 1f000ff..d43d6b3 100644
> --- a/include/net/tcp.h
> +++ b/include/net/tcp.h
> @@ -98,11 +98,21 @@ extern void tcp_time_wait(struct sock *sk, int state, int timeo);
>                                  * 15 is ~13-30min depending on RTO.
>                                  */
>
> -#define TCP_SYN_RETRIES         5      /* number of times to retry active opening a
> -                                * connection: ~180sec is RFC minimum   */
> +#define TCP_SYN_RETRIES         6      /*
> +                                * This is how many retries it does to active
> +                                * opening a connection.
> +                                * RFC1122 says the minimum retry MUST be at
> +                                * least 180secs. Nevertheless this value is
> +                                * corresponding to 63secs of retransmission
> +                                * with the current initial RTO.
> +                                */
>
> -#define TCP_SYNACK_RETRIES 5   /* number of times to retry passive opening a
> -                                * connection: ~180sec is RFC minimum   */
> +#define TCP_SYNACK_RETRIES 5   /*
> +                                * This is how may retries it does to passive
> +                                * opening a connection.
> +                                * This is corresponding to 31secs of
> +                                * retransmission with the current initial RTO.

IMHO 31secs seem a little short. Why not change it to 6 as well because 63
secs still beats 93secs with 3sec initRTO and 5 retries.

Jerry

> +                                */
>
>  #define TCP_TIMEWAIT_LEN (60*HZ) /* how long to wait to destroy TIME-WAIT
>                                   * state, about 60 seconds     */
> --
> 1.7.8.6
>

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

[Eric Dumazet]

On Tue, 2012-08-28 at 21:34 -0700, H.K. Jerry Chu wrote:

> IMHO 31secs seem a little short. Why not change it to 6 as well because 63
> secs still beats 93secs with 3sec initRTO and 5 retries.
> 
> Jerry
> 

My rationale was that such increase were going to amplify SYN attacks
impact by 20% (if we count number of useless SYNACK sent)

If the active side sends SYN packets for 180 seconds, do we really want
to also send SYNACKS for additional 100 seconds ?

Sure, RFC numbers are what they are, but in practice, I doubt someone
will really miss the extra SYNACK sent after ~32 seconds, since it would
matter only for the last SYN attempted.

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

[H.K. Jerry Chu]

Eric,

On Wed, Aug 29, 2012 at 1:51 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Tue, 2012-08-28 at 21:34 -0700, H.K. Jerry Chu wrote:
>
>> IMHO 31secs seem a little short. Why not change it to 6 as well because 63
>> secs still beats 93secs with 3sec initRTO and 5 retries.
>>
>> Jerry
>>
>
> My rationale was that such increase were going to amplify SYN attacks
> impact by 20% (if we count number of useless SYNACK sent)

IMHO the main damage caused by SYN attack is DOS resulted from bogus
SYNs clogging the listener queue. I guess you've had numbers showing
that generating so many SYNACKs in response to bogus SYNs can be costly
too. But each bogus SYN that expires earlier will open up space sooner in the
listener queue for more bogus SYN so I'm not sure which one can induced
more damage.

Also if syn-cookie is enabled, it will dwarf the cost from
retransmitting SYN-ACK,
right?

>
> If the active side sends SYN packets for 180 seconds, do we really want
> to also send SYNACKS for additional 100 seconds ?

You have a good point. (I remember some folks in the past even question with
retransmitting SYN why SYN-ACK retransmit is necessary, other than for expedient
recovery purpose.)

But it probably matter slightly more for TCP Fast Open (the server
side patch has
been completed and will be posted soon, after I finish breaking it up
into smaller
pieces for ease of review purpose), when a full socket will be created with data
passed to the app upon a valid SYN+data. Dropping a fully functioning socket
won't be the same as dropping a request_sock unknown to the app and letting
the other side retransmitting SYN (w/o data this time).

>
> Sure, RFC numbers are what they are, but in practice, I doubt someone
> will really miss the extra SYNACK sent after ~32 seconds, since it would
> matter only for the last SYN attempted.

I'd slightly prefer 1 extra retry plus longer wait time just to make
TCP Fast Open
a little more robust (even though the app protocol is required to be
idempotent).
But this is not a showstopper.

Thanks,

Jerry

>
>
>

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

[Eric Dumazet]

On Wed, 2012-08-29 at 10:25 -0700, H.K. Jerry Chu wrote:

> But it probably matter slightly more for TCP Fast Open (the server
> side patch has
> been completed and will be posted soon, after I finish breaking it up
> into smaller
> pieces for ease of review purpose), when a full socket will be created with data
> passed to the app upon a valid SYN+data. Dropping a fully functioning socket
> won't be the same as dropping a request_sock unknown to the app and letting
> the other side retransmitting SYN (w/o data this time).
> 
> >
> > Sure, RFC numbers are what they are, but in practice, I doubt someone
> > will really miss the extra SYNACK sent after ~32 seconds, since it would
> > matter only for the last SYN attempted.
> 
> I'd slightly prefer 1 extra retry plus longer wait time just to make
> TCP Fast Open
> a little more robust (even though the app protocol is required to be
> idempotent).
> But this is not a showstopper.

Thats very good points indeed, thanks.

Maybe we can increase SYNACK max retrans only if the FastOpen SYN cookie
was validated.

This way, we increase reliability without amplifying the effect of wild
SYN packets.

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

[David Miller]

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 30 Aug 2012 06:12:30 -0700

> On Wed, 2012-08-29 at 10:25 -0700, H.K. Jerry Chu wrote:
> 
>> But it probably matter slightly more for TCP Fast Open (the server
>> side patch has
>> been completed and will be posted soon, after I finish breaking it up
>> into smaller
>> pieces for ease of review purpose), when a full socket will be created with data
>> passed to the app upon a valid SYN+data. Dropping a fully functioning socket
>> won't be the same as dropping a request_sock unknown to the app and letting
>> the other side retransmitting SYN (w/o data this time).
>> 
>> >
>> > Sure, RFC numbers are what they are, but in practice, I doubt someone
>> > will really miss the extra SYNACK sent after ~32 seconds, since it would
>> > matter only for the last SYN attempted.
>> 
>> I'd slightly prefer 1 extra retry plus longer wait time just to make
>> TCP Fast Open
>> a little more robust (even though the app protocol is required to be
>> idempotent).
>> But this is not a showstopper.
> 
> Thats very good points indeed, thanks.
> 
> Maybe we can increase SYNACK max retrans only if the FastOpen SYN cookie
> was validated.
> 
> This way, we increase reliability without amplifying the effect of wild
> SYN packets.

Can we come to a final conclusion on this last point and arrive at a final
patch?

Thanks.

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

[H.K. Jerry Chu]

On Thu, Aug 30, 2012 at 6:12 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Wed, 2012-08-29 at 10:25 -0700, H.K. Jerry Chu wrote:
>
>> But it probably matter slightly more for TCP Fast Open (the server
>> side patch has
>> been completed and will be posted soon, after I finish breaking it up
>> into smaller
>> pieces for ease of review purpose), when a full socket will be created with data
>> passed to the app upon a valid SYN+data. Dropping a fully functioning socket
>> won't be the same as dropping a request_sock unknown to the app and letting
>> the other side retransmitting SYN (w/o data this time).
>>
>> >
>> > Sure, RFC numbers are what they are, but in practice, I doubt someone
>> > will really miss the extra SYNACK sent after ~32 seconds, since it would
>> > matter only for the last SYN attempted.
>>
>> I'd slightly prefer 1 extra retry plus longer wait time just to make
>> TCP Fast Open
>> a little more robust (even though the app protocol is required to be
>> idempotent).
>> But this is not a showstopper.
>
> Thats very good points indeed, thanks.
>
> Maybe we can increase SYNACK max retrans only if the FastOpen SYN cookie
> was validated.
>
> This way, we increase reliability without amplifying the effect of wild
> SYN packets.

Ok, will use sysctl_tcp_synack_retries + 1 in tcp_fastopen_synack_timer() of my
upcoming TCP Fast Open server patch (hope to submit today).

Jerry

>
>
>

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

[H.K. Jerry Chu]

On Thu, Aug 30, 2012 at 9:45 AM, David Miller <davem@davemloft.net> wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Thu, 30 Aug 2012 06:12:30 -0700
>
>> On Wed, 2012-08-29 at 10:25 -0700, H.K. Jerry Chu wrote:
>>
>>> But it probably matter slightly more for TCP Fast Open (the server
>>> side patch has
>>> been completed and will be posted soon, after I finish breaking it up
>>> into smaller
>>> pieces for ease of review purpose), when a full socket will be created with data
>>> passed to the app upon a valid SYN+data. Dropping a fully functioning socket
>>> won't be the same as dropping a request_sock unknown to the app and letting
>>> the other side retransmitting SYN (w/o data this time).
>>>
>>> >
>>> > Sure, RFC numbers are what they are, but in practice, I doubt someone
>>> > will really miss the extra SYNACK sent after ~32 seconds, since it would
>>> > matter only for the last SYN attempted.
>>>
>>> I'd slightly prefer 1 extra retry plus longer wait time just to make
>>> TCP Fast Open
>>> a little more robust (even though the app protocol is required to be
>>> idempotent).
>>> But this is not a showstopper.
>>
>> Thats very good points indeed, thanks.
>>
>> Maybe we can increase SYNACK max retrans only if the FastOpen SYN cookie
>> was validated.
>>
>> This way, we increase reliability without amplifying the effect of wild
>> SYN packets.
>
> Can we come to a final conclusion on this last point and arrive at a final
> patch?
>
> Thanks.

Acked-by: H.K. Jerry Chu <hkchu@google.com>

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

[Alexander Bergmann]

On Fri, Aug 31, 2012 at 04:57:40AM -0700, Eric Dumazet wrote:
> On Tue, 2012-08-28 at 10:44 +0200, Carsten Wolff wrote:
> > 
> > wouldn't it be nice, if the description of the corresponding sysctls in 
> > Documentation/networking/ip-sysctl.txt could be updated too?
> > 

Thanks Carsten for pointing that out.

> 
> Carsten had a good point, any chance you can send a v3 of your patch,
> with the Documentation/networking/ip-sysctl.txt changed as well ?
> 

Hi Eric!

I've also changed the Documentation file. As usual, comments are welcome!


Alex


>From 848f34ce27f65401940ae98e0b2d395888d3986d Mon Sep 17 00:00:00 2001
From: Alexander Bergmann <alex@linlab.net>
Date: Fri, 31 Aug 2012 14:31:00 +0200
Subject: [PATCH 1/1] tcp: Increase timeout for SYN segments

Commit 9ad7c049 changed the initRTO from 3secs to 1sec in accordance to
RFC6298 (former RFC2988bis). This reduced the time till the last SYN
retransmission packet gets sent from 93secs to 31secs.

RFC1122 is stating that the retransmission should be done for at least 3
minutes, but this seems to be quite high.

  "However, the values of R1 and R2 may be different for SYN
  and data segments.  In particular, R2 for a SYN segment MUST
  be set large enough to provide retransmission of the segment
  for at least 3 minutes.  The application can close the
  connection (i.e., give up on the open attempt) sooner, of
  course."

This patch increases the value of TCP_SYN_RETRIES to the value of 6,
providing a retransmission window of 63secs.

The comments for SYN and SYNACK retries have also been updated to
describe the current settings. The same goes for the documentation file
"Documentation/networking/ip-sysctl.txt".

Signed-off-by: Alexander Bergmann <alex@linlab.net>
---
 Documentation/networking/ip-sysctl.txt |    8 ++++++--
 include/net/tcp.h                      |   18 ++++++++++++++----
 2 files changed, 20 insertions(+), 6 deletions(-)

diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index ca447b3..d64e531 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -439,7 +439,9 @@ tcp_stdurg - BOOLEAN
 tcp_synack_retries - INTEGER
 	Number of times SYNACKs for a passive TCP connection attempt will
 	be retransmitted. Should not be higher than 255. Default value
-	is 5, which corresponds to ~180seconds.
+	is 5, which corresponds to 31seconds till the last retransmission
+	with the current initial RTO of 1second. With this the final timeout
+	for a passive TCP connection will happen after 63seconds.
 
 tcp_syncookies - BOOLEAN
 	Only valid when the kernel was compiled with CONFIG_SYNCOOKIES
@@ -478,7 +480,9 @@ tcp_fastopen - INTEGER
 tcp_syn_retries - INTEGER
 	Number of times initial SYNs for an active TCP connection attempt
 	will be retransmitted. Should not be higher than 255. Default value
-	is 5, which corresponds to ~180seconds.
+	is 6, which corresponds to 63seconds till the last restransmission
+	with the current initial RTO of 1second. With this the final timeout
+	for an active TCP connection attempt will happen after 127seconds.
 
 tcp_timestamps - BOOLEAN
 	Enable timestamps as defined in RFC1323.
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 1f000ff..d43d6b3 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -98,11 +98,21 @@ extern void tcp_time_wait(struct sock *sk, int state, int timeo);
 				 * 15 is ~13-30min depending on RTO.
 				 */
 
-#define TCP_SYN_RETRIES	 5	/* number of times to retry active opening a
-				 * connection: ~180sec is RFC minimum	*/
+#define TCP_SYN_RETRIES	 6	/*
+				 * This is how many retries it does to active
+				 * opening a connection.
+				 * RFC1122 says the minimum retry MUST be at
+				 * least 180secs. Nevertheless this value is
+				 * corresponding to 63secs of retransmission
+				 * with the current initial RTO.
+				 */
 
-#define TCP_SYNACK_RETRIES 5	/* number of times to retry passive opening a
-				 * connection: ~180sec is RFC minimum	*/
+#define TCP_SYNACK_RETRIES 5	/* 
+				 * This is how may retries it does to passive
+				 * opening a connection. 
+				 * This is corresponding to 31secs of 
+				 * retransmission with the current initial RTO.
+				 */
 
 #define TCP_TIMEWAIT_LEN (60*HZ) /* how long to wait to destroy TIME-WAIT
 				  * state, about 60 seconds	*/
-- 
1.7.8.6

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

[Eric Dumazet]

On Fri, 2012-08-31 at 14:48 +0200, Alexander Bergmann wrote:

> Hi Eric!
> 
> I've also changed the Documentation file. As usual, comments are welcome!
> 
> 
> Alex
> 
> 
> From 848f34ce27f65401940ae98e0b2d395888d3986d Mon Sep 17 00:00:00 2001
> From: Alexander Bergmann <alex@linlab.net>
> Date: Fri, 31 Aug 2012 14:31:00 +0200
> Subject: [PATCH 1/1] tcp: Increase timeout for SYN segments
> 
> Commit 9ad7c049 changed the initRTO from 3secs to 1sec in accordance to
> RFC6298 (former RFC2988bis). This reduced the time till the last SYN
> retransmission packet gets sent from 93secs to 31secs.
> 
> RFC1122 is stating that the retransmission should be done for at least 3
> minutes, but this seems to be quite high.
> 
>   "However, the values of R1 and R2 may be different for SYN
>   and data segments.  In particular, R2 for a SYN segment MUST
>   be set large enough to provide retransmission of the segment
>   for at least 3 minutes.  The application can close the
>   connection (i.e., give up on the open attempt) sooner, of
>   course."
> 
> This patch increases the value of TCP_SYN_RETRIES to the value of 6,
> providing a retransmission window of 63secs.
> 
> The comments for SYN and SYNACK retries have also been updated to
> describe the current settings. The same goes for the documentation file
> "Documentation/networking/ip-sysctl.txt".
> 
> Signed-off-by: Alexander Bergmann <alex@linlab.net>
> ---

Thanks for your patience and followup, this seems good to me !

Acked-by: Eric Dumazet <edumazet@google.com>

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

[David Miller]

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 31 Aug 2012 06:25:50 -0700

> On Fri, 2012-08-31 at 14:48 +0200, Alexander Bergmann wrote:
> 
>> Hi Eric!
>> 
>> I've also changed the Documentation file. As usual, comments are welcome!
>> 
>> 
>> Alex
>> 
>> 
>> From 848f34ce27f65401940ae98e0b2d395888d3986d Mon Sep 17 00:00:00 2001
>> From: Alexander Bergmann <alex@linlab.net>
>> Date: Fri, 31 Aug 2012 14:31:00 +0200
>> Subject: [PATCH 1/1] tcp: Increase timeout for SYN segments
>> 
>> Commit 9ad7c049 changed the initRTO from 3secs to 1sec in accordance to
>> RFC6298 (former RFC2988bis). This reduced the time till the last SYN
>> retransmission packet gets sent from 93secs to 31secs.
>> 
>> RFC1122 is stating that the retransmission should be done for at least 3
>> minutes, but this seems to be quite high.
>> 
>>   "However, the values of R1 and R2 may be different for SYN
>>   and data segments.  In particular, R2 for a SYN segment MUST
>>   be set large enough to provide retransmission of the segment
>>   for at least 3 minutes.  The application can close the
>>   connection (i.e., give up on the open attempt) sooner, of
>>   course."
>> 
>> This patch increases the value of TCP_SYN_RETRIES to the value of 6,
>> providing a retransmission window of 63secs.
>> 
>> The comments for SYN and SYNACK retries have also been updated to
>> describe the current settings. The same goes for the documentation file
>> "Documentation/networking/ip-sysctl.txt".
>> 
>> Signed-off-by: Alexander Bergmann <alex@linlab.net>
>> ---
> 
> Thanks for your patience and followup, this seems good to me !
> 
> Acked-by: Eric Dumazet <edumazet@google.com>

Applied with some minor comment formatting and wording adjustments.

Thanks everyone.

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

[David Miller]

From: David Miller <davem@davemloft.net>
Date: Fri, 31 Aug 2012 15:42:34 -0400 (EDT)

> Applied with some minor comment formatting and wording adjustments.

BTW, please keep in mind that when you modify the value
of TCP_SYN_RETRIES, you are having an influence upon DCCP
as well.

TCP is not the only protocol which uses this value.