Thread (18 messages) flat view 18 messages, 6 authors, 2012-08-30

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

From: H.K. Jerry Chu <hidden>
Date: 2012-08-29 17:25:38
Also in: lkml

Possibly related (same subject, not in this thread)

Eric,

On Wed, Aug 29, 2012 at 1:51 AM, Eric Dumazet [off-list ref] wrote:
On Tue, 2012-08-28 at 21:34 -0700, H.K. Jerry Chu wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help