From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753420Ab2H3R7n (ORCPT ); Thu, 30 Aug 2012 13:59:43 -0400 Received: from mail-lb0-f174.google.com ([209.85.217.174]:36534 "EHLO mail-lb0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751275Ab2H3R7l (ORCPT ); Thu, 30 Aug 2012 13:59:41 -0400 MIME-Version: 1.0 In-Reply-To: <1346332350.2586.10.camel@edumazet-glaptop> References: <1345724123.5904.756.camel@edumazet-glaptop> <50362407.9070805@linlab.net> <1345726185.5904.835.camel@edumazet-glaptop> <20120824.134231.41073001349178209.davem@davemloft.net> <20120825084819.GD430@linlab.net> <1346230305.2522.15.camel@edumazet-glaptop> <1346332350.2586.10.camel@edumazet-glaptop> Date: Thu, 30 Aug 2012 10:59:39 -0700 Message-ID: Subject: Re: [PATCH 1/1] tcp: Wrong timeout for SYN segments From: "H.K. Jerry Chu" To: Eric Dumazet Cc: Alexander Bergmann , David Miller , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 30, 2012 at 6:12 AM, Eric Dumazet 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 > > >