Date: Mon, 28 Dec 2015 01:06:59 -0500 From: Patrick Kelsey <pkelsey@freebsd.org> To: Andrey Chernov <ache@freebsd.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-stable@freebsd.org, svn-src-stable-10@freebsd.org Subject: Re: svn commit: r292823 - in stable/10/sys: conf netinet Message-ID: <0E5C9BC6-F52E-45F6-A3F7-CCED1BD0F8C7@freebsd.org> In-Reply-To: <5680B53F.9040903@freebsd.org> References: <201512280243.tBS2hD7X008202@repo.freebsd.org> <5680A574.9050002@freebsd.org> <CAD44qMU2QEo2s2y_na5zw6U4mQWu=UWjw_vRjjFs3Q95o0iXNg@mail.gmail.com> <5680ABD5.7030206@freebsd.org> <FE066F76-3613-4C53-A0F8-CDAF2F77F24C@freebsd.org> <5680B53F.9040903@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Dec 27, 2015, at 11:06 PM, Andrey Chernov <ache@freebsd.org> wrote: >=20 > On 28.12.2015 6:45, Patrick Kelsey wrote: >>> On Dec 27, 2015, at 10:26 PM, Andrey Chernov <ache@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0E5C9BC6-F52E-45F6-A3F7-CCED1BD0F8C7>