tcp: Wrong timeout for SYN segments
Subsystems (4)
PATCH 1/1 tcp: Wrong timeout for SYN segments
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
Quoted 1 line
From
8b854a525eb45f64ad29dfab16f9d9f681e84495Mon Sep 17 00:00:00 2001
From: Alexander Bergmann <[email protected]>
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 secsTo 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.
--- include/net/tcp.h | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)
include/net/tcp.h +2 -2
@@ -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
Signature · 1 line
1.7.8.6
Quoted 17 lines · 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
8b854a525eb45f64ad29dfab16f9d9f681e84495Mon Sep 17 00:00:00 2001
From: Alexander Bergmann <[email protected]>
Date: Wed, 22 Aug 2012 00:29:08 +0200
Subject: [PATCH 1/1] tcp: Wrong timeout for SYN segmentsCommit
9ad7c049changed 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.
Quoted 5 lines
Prior to
9ad7c049the 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.
Quoted 21 lines
To fulfill the MUST constraint in RFC1122 section 4.2.3.5 about R2 for SYN segments, the values of
TCP_SYN_RETRIESandTCP_SYNACK_RETRIESmust be changed to 7 reties.((2 << 7) - 1) * 1 secs = 255 secsThis would result in an ETIMEDOUT of 4 minutes 15 seconds.
Signed-off-by Alexander Bergmann <[email protected]>--- include/net/tcp.h | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)include/net/tcp.h +0
-0@@ -98,10 +98,10 @@ extern void tcp_time_wait(struct sock *sk, int state, int timeo);* 15 is ~13-30min depending on RTO. */
include/net/tcp.h extern void tcp_time_wait(struct sock *sk, int state, int timeo); · line 107
Quoted 10 lines
include/net/tcp.h +2
-2-#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
Quoted 8 lines · Eric Dumazet
Quoted 5 lines
Prior to
9ad7c049the 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 secsStrange maths ... here I have :
Quoted 7 lines
(1+2+4+8+16) * 3 = 93 secs
vs
(1+2+4+8+16) * 1 = 31 secsSo 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;
Quoted 31 lines
Quoted 31 lines
To fulfill the MUST constraint in RFC1122 section 4.2.3.5 about R2 for SYN segments, the values of
TCP_SYN_RETRIESandTCP_SYNACK_RETRIESmust be changed to 7 reties.((2 << 7) - 1) * 1 secs = 255 secsThis would result in an ETIMEDOUT of 4 minutes 15 seconds.
Signed-off-by Alexander Bergmann <[email protected]>--- include/net/tcp.h | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)include/net/tcp.h +2
-2@@ -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 */
Quoted 5 lines
include/net/tcp.h extern void tcp_time_wait(struct sock *sk, int state, int timeo); · line 107
Quoted 1 line
include/net/tcp.h +0
-0#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.
Quoted 44 lines
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_RECVsocket)Increasing
TCP_SYNACK_RETRIESfrom 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 seconds1 sec
12 sec // switch to RTO = 6
24 sec
48 sec
96 sec
-----
total of 181 seconds
Quoted 22 lines · Alex Bergmann
Quoted 8 lines · Eric Dumazet
Quoted 5 lines
Prior to
9ad7c049the 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 secsStrange maths ... here I have :
Quoted 7 lines
(1+2+4+8+16) * 3 = 93 secs
vs
(1+2+4+8+16) * 1 = 31 secsSo 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:
Quoted 7 lines
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.
Quoted 40 lines · Eric Dumazet
Quoted 22 lines · Alex Bergmann
Quoted 8 lines · Eric Dumazet
Quoted 5 lines
Prior to
9ad7c049the 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 secsStrange maths ... here I have :
Quoted 7 lines
(1+2+4+8+16) * 3 = 93 secs
vs
(1+2+4+8+16) * 1 = 31 secsSo 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:
Quoted 7 lines
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.
Quoted 6 lines
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?
Quoted 2 lines · Alex Bergmann
Actual 6 SYN frames are sent. The initial one and 5 retries.
first one had a t0 + 0 delay. How can it count ???
Quoted 5 lines
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.
Quoted 24 lines · Eric Dumazet
Quoted 2 lines · Alex Bergmann
Actual 6 SYN frames are sent. The initial one and 5 retries.
first one had a t0 + 0 delay. How can it count ???
Quoted 5 lines
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) = 31If 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."
Quoted 8 lines
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.
Quoted 36 lines · Eric Dumazet
Quoted 24 lines · Eric Dumazet
Quoted 2 lines · Alex Bergmann
Actual 6 SYN frames are sent. The initial one and 5 retries.
first one had a t0 + 0 delay. How can it count ???
Quoted 5 lines
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) = 31If 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."Quoted 8 lines
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
Quoted 7 lines
(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
Quoted 7 lines
--
To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 23 lines · 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
8b854a525eb45f64ad29dfab16f9d9f681e84495Mon Sep 17 00:00:00 2001
From: Alexander Bergmann <[email protected]>
Date: Wed, 22 Aug 2012 00:29:08 +0200
Subject: [PATCH 1/1] tcp: Wrong timeout for SYN segmentsCommit
9ad7c049changed 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
9ad7c049the 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
Quoted 7 lines
To fulfill the MUST constraint in RFC1122 section 4.2.3.5 about R2 for SYN segments, the values of
TCP_SYN_RETRIESandTCP_SYNACK_RETRIESmust be changed to 7 reties.((2 << 7) - 1) * 1 secs = 255 secsThis 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
Quoted 30 lines
Signed-off-by Alexander Bergmann <[email protected]>--- include/net/tcp.h | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)include/net/tcp.h +2
-3@@ -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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): CAFbMe2M7ekc94bQk7vTS1LhScPd49VZ-zKOCUXhqwxXtL-nkuA@mail.gmail.com
Quoted 35 lines · H.K. Jerry Chu
On Tue, Aug 21, 2012 at 4:29 PM, Alex Bergmann <[email protected] <mailto:[email protected]>> 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
8b854a525eb45f64ad29dfab16f9d9f681e84495Mon Sep 17 00:00:00 2001
From: Alexander Bergmann <[email protected] <mailto:[email protected]>>
Date: Wed, 22 Aug 2012 00:29:08 +0200
Subject: [PATCH 1/1] tcp: Wrong timeout for SYN segmentsCommit
9ad7c049changed 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
9ad7c049the 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 secsTo fulfill the MUST constraint in RFC1122 section 4.2.3.5 about R2 for SYN segments, the values of
TCP_SYN_RETRIESandTCP_SYNACK_RETRIESmust be changed to 7 reties.((2 << 7) - 1) * 1 secs = 255 secs
This would result in an ETIMEDOUT of 4 minutes 15 seconds.
Quoted 6 lines
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
Quoted 44 lines
Jerry
Signed-off-by Alexander Bergmann <[email protected]<mailto:[email protected]>>
---
include/net/tcp.h| 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)diff --git
a/include/net/tcp.hb/include/net/tcp.h
index 1f000ff..7eaae19 100644
---a/include/net/tcp.h
+++b/include/net/tcp.h
@@ -98,10 +98,10 @@ extern voidtcp_time_wait(struct sock *sk, int state, int timeo);
* 15 is ~13-30min depending on RTO. */-#define
TCP_SYN_RETRIES5 /* number of times to retry
active opening a
+#defineTCP_SYN_RETRIES7 /* number of times to retry
active opening a
* connection: ~180sec is RFC
minimum */-#define
TCP_SYNACK_RETRIES5 /* number of times to retry passive
opening a
+#defineTCP_SYNACK_RETRIES7 /* 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 [email protected] <mailto:[email protected]>
More majordomo info at http://vger.kernel.org/majordomo-info.html
Signature · 4 lines
|. _ | _ |_ _ _ _|_ ||| ||(_||_).| |(/_ | email/sip/xmpp: [email protected] phone/enum: +49 2871 2355378
Quoted 10 lines · Alex Bergmann
Quoted 6 lines · H.K. Jerry Chu
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 ?
Quoted 3 lines
I would suggest to increase
TCP_SYN_RETRIESfrom 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
Quoted 8 lines · David Laight
Quoted 3 lines
I would suggest to increase
TCP_SYN_RETRIESfrom 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...
Quoted 10 lines · Eric Dumazet
Quoted 9 lines · Alex Bergmann
Quoted 6 lines · H.K. Jerry Chu
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)
Quoted 7 lines
Quoted 1 line
Okay, I missed that post during my search about the current situation.
I would suggest to increase
TCP_SYN_RETRIESfrom 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
Quoted 1 line
From
be551f82499112e4775b6d579d58967510b6d492Mon Sep 17 00:00:00 2001
From: Alexander Bergmann <[email protected]>
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
--- include/net/tcp.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
include/net/tcp.h +1 -1
@@ -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
Signature · 1 line
1.7.8.6
Eric Dumazet
Acked-byQuoted 28 lines · Alex Bergmann
From
be551f82499112e4775b6d579d58967510b6d492Mon Sep 17 00:00:00 2001
From: Alexander Bergmann <[email protected]>
Date: Thu, 23 Aug 2012 14:33:35 +0200
Subject: [PATCH 1/1] tcp: Increase timeout for SYN segmentsCommit
9ad7c049changed 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_RETRIESto 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 <[email protected]>--- include/net/tcp.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)include/net/tcp.h +0
-0
include/net/tcp.h extern void tcp_time_wait(struct sock *sk, int state, int timeo); · line 104
Quoted 8 lines
include/net/tcp.h +1
-1@@ -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
A change of the comment might be good, to help future readers.
Quoted 5 lines
Acked-by Eric Dumazet <[email protected]>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
Quoted 1 line
From
11a292b1cff772f930a02fda02d5b741f8ea5033Mon Sep 17 00:00:00 2001
From: Alexander Bergmann <[email protected]>
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.
--- include/net/tcp.h | 18 ++++++++++++++---- 1 files changed, 14 insertions(+), 4 deletions(-)
include/net/tcp.h +14 -4
@@ -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 */
Signature · 1 line
1.7.8.6
David Miller
maintainerFrom: Eric Dumazet <[email protected]>
Date: Thu, 23 Aug 2012 14:49:45 +0200
Quoted 37 lines · Alex Bergmann
Quoted 36 lines
From
be551f82499112e4775b6d579d58967510b6d492Mon Sep 17 00:00:00 2001
From: Alexander Bergmann <[email protected]>
Date: Thu, 23 Aug 2012 14:33:35 +0200
Subject: [PATCH 1/1] tcp: Increase timeout for SYN segmentsCommit
9ad7c049changed 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_RETRIESto 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 <[email protected]>--- include/net/tcp.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)include/net/tcp.h +1
-1@@ -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 */
Quoted 5 lines
include/net/tcp.h extern void tcp_time_wait(struct sock *sk, int state, int timeo); · line 104
Quoted 1 line
include/net/tcp.h +0
-0#define TCP_SYNACK_RETRIES 5/* number of times to retry passive opening a Acked-by Eric Dumazet <[email protected]>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.
Quoted 7 lines · David Miller
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.
Quoted 1 line
From
11a292b1cff772f930a02fda02d5b741f8ea5033Mon Sep 17 00:00:00 2001
From: Alexander Bergmann <[email protected]>
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.
--- include/net/tcp.h | 18 ++++++++++++++---- 1 files changed, 14 insertions(+), 4 deletions(-)
include/net/tcp.h +14 -4
@@ -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 */
Signature · 1 line
1.7.8.6
Eric Dumazet
Acked-byQuoted 19 lines
From: Alexander Bergmann <[email protected]>
Date: Fri, 24 Aug 2012 14:09:49 +0200
Subject: [PATCH 1/1] tcp: Increase timeout for SYN segmentsCommit
9ad7c049changed 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."
Quoted 8 lines
This patch increases the value of
TCP_SYN_RETRIESto 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 <[email protected]>---
Hi,
Quoted 5 lines · Alexander Bergmann
This patch increases the value of
TCP_SYN_RETRIESto 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
A message that is not in the archive (sent off-list or not yet received): 1346414260.2591.8.camel@edumazet-glaptop
Quoted 5 lines · Eric Dumazet
Quoted 4 lines · Carsten Wolff
wouldn't it be nice, if the description of the corresponding sysctls in
Documentation/networking/ip-sysctl.txtcould be updated too?
Thanks Carsten for pointing that out.
Quoted 4 lines
Carsten had a good point, any chance you can send a v3 of your patch, with the
Documentation/networking/ip-sysctl.txtchanged as well ?
Hi Eric!
I've also changed the Documentation file. As usual, comments are welcome!
Alex
Quoted 1 line
From
848f34ce27f65401940ae98e0b2d395888d3986dMon Sep 17 00:00:00 2001
From: Alexander Bergmann <[email protected]>
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".
--- Documentation/networking/ip-sysctl.txt | 8 ++++++-- include/net/tcp.h | 18 ++++++++++++++---- 2 files changed, 20 insertions(+), 6 deletions(-)
Documentation/networking/ip-sysctl.txt +6 -2
@@ -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.
include/net/tcp.h +14 -4
@@ -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 */
Signature · 1 line
1.7.8.6
Eric Dumazet
Acked-byQuoted 30 lines · Alexander Bergmann
Hi Eric!
I've also changed the Documentation file. As usual, comments are welcome!
Alex
From
848f34ce27f65401940ae98e0b2d395888d3986dMon Sep 17 00:00:00 2001
From: Alexander Bergmann <[email protected]>
Date: Fri, 31 Aug 2012 14:31:00 +0200
Subject: [PATCH 1/1] tcp: Increase timeout for SYN segmentsCommit
9ad7c049changed 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_RETRIESto the value of 6, providing a retransmission window of 63secs.
Quoted 6 lines
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 <[email protected]>---
Thanks for your patience and followup, this seems good to me !
David Miller
maintainerFrom: Eric Dumazet <[email protected]>
Date: Fri, 31 Aug 2012 06:25:50 -0700
Quoted 36 lines · Alexander Bergmann
Quoted 35 lines
Hi Eric!
I've also changed the Documentation file. As usual, comments are welcome!
Alex
From
848f34ce27f65401940ae98e0b2d395888d3986dMon Sep 17 00:00:00 2001
From: Alexander Bergmann <[email protected]>
Date: Fri, 31 Aug 2012 14:31:00 +0200
Subject: [PATCH 1/1] tcp: Increase timeout for SYN segmentsCommit
9ad7c049changed 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_RETRIESto 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".
Quoted 6 lines
Quoted 2 lines
Signed-off-by Alexander Bergmann <[email protected]>---
Thanks for your patience and followup, this seems good to me !
Acked-by Eric Dumazet <[email protected]>
Applied with some minor comment formatting and wording adjustments.
Thanks everyone.
David Miller
maintainerFrom: David Miller <[email protected]>
Date: Fri, 31 Aug 2012 15:42:34 -0400 (EDT)
Quoted 1 line
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.
Quoted 58 lines · Alexander Bergmann
Quoted 7 lines · David Miller
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
11a292b1cff772f930a02fda02d5b741f8ea5033Mon Sep 17 00:00:00 2001
From: Alexander Bergmann <[email protected]>
Date: Fri, 24 Aug 2012 14:09:49 +0200
Subject: [PATCH 1/1] tcp: Increase timeout for SYN segmentsCommit
9ad7c049changed 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_RETRIESto 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 <[email protected]>--- include/net/tcp.h | 18 ++++++++++++++---- 1 files changed, 14 insertions(+), 4 deletions(-)include/net/tcp.h +6
-2@@ -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
include/net/tcp.h extern void tcp_time_wait(struct sock *sk, int state, int timeo); · line 114
Quoted 10 lines
include/net/tcp.h +7
-2+* 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
Quoted 7 lines
include/net/tcp.h +1
-1+*/ #define TCP_TIMEWAIT_LEN (60*HZ)/* how long to wait to destroy TIME-WAIT * state, about 60 seconds */ --1.7.8.6
Quoted 5 lines · H.K. Jerry Chu
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.
Eric,
Quoted 10 lines · Eric Dumazet
Quoted 5 lines · H.K. Jerry Chu
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?
Quoted 3 lines
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).
Quoted 4 lines
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
Quoted 3 lines
Quoted 14 lines · H.K. Jerry Chu
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 arequest_sockunknown to the app and letting the other side retransmitting SYN (w/o data this time).Quoted 4 lines
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.
Quoted 5 lines
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.
David Miller
maintainerFrom: Eric Dumazet <[email protected]>
Date: Thu, 30 Aug 2012 06:12:30 -0700
Quoted 22 lines · H.K. Jerry Chu
Quoted 15 lines
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 arequest_sockunknown to the app and letting the other side retransmitting SYN (w/o data this time).Quoted 4 lines
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.
Quoted 5 lines
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.
Quoted 7 lines
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.
H.K. Jerry Chu
Acked-byQuoted 30 lines · David Miller
From: Eric Dumazet <[email protected]>
Date: Thu, 30 Aug 2012 06:12:30 -0700Quoted 27 lines · H.K. Jerry Chu
Quoted 15 lines
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 arequest_sockunknown to the app and letting the other side retransmitting SYN (w/o data this time).Quoted 4 lines
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.
Quoted 5 lines
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.
Quoted 7 lines
Quoted 2 lines
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.
Quoted 22 lines · Eric Dumazet
Quoted 14 lines · H.K. Jerry Chu
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 arequest_sockunknown to the app and letting the other side retransmitting SYN (w/o data this time).Quoted 4 lines
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.
Quoted 5 lines
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.
Quoted 7 lines
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