From owner-svn-src-stable-10@freebsd.org Mon Dec 28 06:07:01 2015 Return-Path: Delivered-To: svn-src-stable-10@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 6E613A52A03; Mon, 28 Dec 2015 06:07:01 +0000 (UTC) (envelope-from pkelsey@gmail.com) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (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 3037F1CEA; Mon, 28 Dec 2015 06:07:01 +0000 (UTC) (envelope-from pkelsey@gmail.com) Received: by mail-qg0-x22c.google.com with SMTP id o11so141736601qge.2; Sun, 27 Dec 2015 22:07:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=oTRTSvqBcb39oL5q1JLnps574eIdZXB7NMV481Q0Mao=; b=Ujmp7qMSEjxvL5iJgtLlkQMqwheIe0E26VpqN08if0tyCswZELCR5zla6ZENPq9RYI cU3fGOAYzYENMI6v96XUUsTNWTvLAJK3/W0pnD6yIaB87JO86lHNQRpcI7AQZ0ZEebQM YtwvJTS9aPS5zQYGh9ZNA3t2teurdjLDFfHldmTGovki4/GBr53l9WfKsCDc3msQHSGU AKUK44sxZstLVfdekXH9OAUhaJPGGB5xhcP+6YolfENxyHZe6mIHM0ASScs/5d/TMQ1M edb5c/B7S/KJEkw/U4vX/1aT0mUtIi4+iQRzOQBf+Usz/GJw5hFMkF7qJGNj/RFtxXMl p0eQ== X-Received: by 10.140.17.213 with SMTP id 79mr68887794qgd.49.1451282820279; Sun, 27 Dec 2015 22:07:00 -0800 (PST) Received: from [172.16.0.133] (c-174-59-104-177.hsd1.pa.comcast.net. [174.59.104.177]) by smtp.gmail.com with ESMTPSA id d6sm26912182qkb.13.2015.12.27.22.06.59 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 27 Dec 2015 22:06:59 -0800 (PST) Sender: Patrick Kelsey Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: svn commit: r292823 - in stable/10/sys: conf netinet From: Patrick Kelsey X-Mailer: iPhone Mail (13C75) In-Reply-To: <5680B53F.9040903@freebsd.org> Date: Mon, 28 Dec 2015 01:06:59 -0500 Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-stable@freebsd.org, svn-src-stable-10@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <0E5C9BC6-F52E-45F6-A3F7-CCED1BD0F8C7@freebsd.org> References: <201512280243.tBS2hD7X008202@repo.freebsd.org> <5680A574.9050002@freebsd.org> <5680ABD5.7030206@freebsd.org> <5680B53F.9040903@freebsd.org> To: Andrey Chernov X-BeenThere: svn-src-stable-10@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SVN commit messages for only the 10-stable src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2015 06:07:01 -0000 > On Dec 27, 2015, at 11:06 PM, Andrey Chernov wrote: >=20 > On 28.12.2015 6:45, Patrick Kelsey wrote: >>> On Dec 27, 2015, at 10:26 PM, Andrey Chernov wrote: >>>=20 >>>> 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 defaul= t >>>> in the kernel build as a conservative measure until it is exercised mor= e >>>> 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 tha= t >>>> must be enabled before it can be used. >>>>=20 >>>> -Patrick >>>=20 >>> 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 >>=20 >> 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*, a= nd I consider the changes I made to the rest of the TCP stack, which is wide= ly deployed and used, to be intrusive enough to warrant being conservative i= n putting these changes into the default kernel build at this point. >>=20 >> *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. >=20 > 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. >=20 I don't think it is a matter of waiting for a Linux bug to be fixed - I only= cited this particular bug as something that has colored my thinking as to h= ow much close attention is being paid to TFO at the present time. The Mac O= S X client works better, so it is not really a question of quality clients e= xisting. I have just chosen to be conservative in the initial release of th= is functionality based on my impression that the current audience for it is n= ot very big and my desire for my implementation to see wider testing first. = I do expect the audience for TFO to grow over time and for this implementat= ion to receive wider testing. One thing to consider about RFC7413 that is not always apparent when first l= ooking at it is that it is not a general-purpose speedup that can be applied= transparently for any/all applications. One of the things that can happen w= hen using TFO that cannot happen when using the regular TCP three-way handsh= ake is that packet duplication in the network can result in application-leve= l request duplication. Because of this, TFO is only really suitable for app= lications that have some built-in mitigation for this or otherwise do not ha= ve to care about it. This is discussed in the RFC. Also, in my opinion, when using TFO, one has to accept certain ideas present= ed in the RFC about the relative importance or attractiveness to attackers o= f certain attack vectors that are introduced by TFO, or establish that your p= articular application can otherwise mitigate or tolerate them. Again, this i= s not a general purpose, set-it-and-forget-it kind of TCP performance improv= ement. -Patrick