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

On Thu, Aug 30, 2012 at 6:12 AM, Eric Dumazet [off-list ref] wrote:

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

quoted

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

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