From owner-svn-src-stable@freebsd.org Mon Dec 28 04:06:27 2015 Return-Path: Delivered-To: svn-src-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EF28EA52827 for ; Mon, 28 Dec 2015 04:06:26 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mail-lf0-f48.google.com (mail-lf0-f48.google.com [209.85.215.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 828F217FA for ; Mon, 28 Dec 2015 04:06:26 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by mail-lf0-f48.google.com with SMTP id p203so194688913lfa.0 for ; Sun, 27 Dec 2015 20:06:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=IVRgJsuxwARE5nwvIahxEhYUS9OVkWyoLPNMPwHT/Eo=; b=Xl7orJilxi4ulhwleXStRZItLNWJFAgNGymPnTlOHEx/67UaaPwTLnUITABDo/6JiQ tOGNX64U3NaK8nKZ2dP7qO3spX23gYc2cUDa+d9GdYcpFgKuag27+YHGbjQZuFZbq4xi kpRRbteJC/wxam7sMG4lBlTbUqr3JufsbT6Pr61ISY2QgVq8S706qsVpYXZplwYzlGGC EHP9r5b8N8LoYz8+IyGXT4JHlWGI6nbKcbPmIyH3CEnmjDaeE3gdPhEHfl9L+fe9BHip CNn2qQcjTvQDjIkmmFXXKNg+Kz1ixIMhjkXM65J4tCMLbaXSPpMaEv/yNghscZ3aLRhr avBQ== X-Gm-Message-State: ALoCoQkDKI7qrJz3dY33zbn2HEFIbz/InEXBmt5d5rU7BlGdt2p3/IXwvVYEJHxYYLI82ysERovMUwpKZXbkCi11SV4yaBJ9Lw== X-Received: by 10.25.165.133 with SMTP id o127mr9385380lfe.105.1451275584489; Sun, 27 Dec 2015 20:06:24 -0800 (PST) Received: from [192.168.1.2] ([89.169.173.68]) by smtp.gmail.com with ESMTPSA id p138sm6847431lfb.22.2015.12.27.20.06.23 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 27 Dec 2015 20:06:23 -0800 (PST) Subject: Re: svn commit: r292823 - in stable/10/sys: conf netinet To: Patrick Kelsey References: <201512280243.tBS2hD7X008202@repo.freebsd.org> <5680A574.9050002@freebsd.org> <5680ABD5.7030206@freebsd.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-stable@freebsd.org, svn-src-stable-10@freebsd.org From: Andrey Chernov X-Enigmail-Draft-Status: N1110 Message-ID: <5680B53F.9040903@freebsd.org> Date: Mon, 28 Dec 2015 07:06:23 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: svn-src-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SVN commit messages for all the -stable branches of the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2015 04:06:27 -0000 On 28.12.2015 6:45, Patrick Kelsey wrote: >> On Dec 27, 2015, at 10:26 PM, Andrey Chernov wrote: >> >>> On 28.12.2015 6:15, Patrick Kelsey wrote: >>> This is explained in the top comment in sys/netinet/tcp_fastopen.c, but >>> I will repeat it here and elaborate a little. It is disabled by default >>> in the kernel build as a conservative measure until it is exercised more >>> widely, given the modifications it introduces to the TCP state machine >>> code, syncache code, etc. When you do enable it in the kernel build >>> (and after some point in the future when it is enabled by default), >>> there is still a sysctl that governs its availability in the system that >>> must be enabled before it can be used. >>> >>> -Patrick >> >> Thanx, if I understand it correctly, is not ready for real use yet but >> just for experiments. See my other comment about TCP_RFC7413_MAX_KEYS >> > > It is a serious implementation that is believed to be complete, however I do not see much evidence that TFO is currently widely deployed and used*, and I consider the changes I made to the rest of the TCP stack, which is widely deployed and used, to be intrusive enough to warrant being conservative in putting these changes into the default kernel build at this point. > > *For example, the current Linux TFO client appears to be surprisingly > weak in that it does not ACK data in a TFO SYN|ACK, forcing a > retransmit of fast TFO server responses, which kind of defeats the > purpose. RFC7413 sounds very promising. Should we wait until Linux fix its bug you mention or just go further having TFO at least for FreeBSD machines on some internal net? If the second case is preferred by others, IMHO it will be better to control it via sysctl compiled in by default, controlled by rc.conf on the upper level. I don't see too much code added to make sufficient size bloat. -- http://ache.vniz.net/