Date: Sun, 27 Dec 2015 22:45:39 -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: <FE066F76-3613-4C53-A0F8-CDAF2F77F24C@freebsd.org> In-Reply-To: <5680ABD5.7030206@freebsd.org> References: <201512280243.tBS2hD7X008202@repo.freebsd.org> <5680A574.9050002@freebsd.org> <CAD44qMU2QEo2s2y_na5zw6U4mQWu=UWjw_vRjjFs3Q95o0iXNg@mail.gmail.com> <5680ABD5.7030206@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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 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. >>=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 d= o 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 p= utting these changes into the default kernel build at this point. I responded to your other message regarding TCP_RFC7413_MAX_KEYS. -Patrick *For example, the current Linux TFO client appears to be surprisingly weak i= n that it does not ACK data in a TFO SYN|ACK, forcing a retransmit of fast T= FO server responses, which kind of defeats the purpose.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FE066F76-3613-4C53-A0F8-CDAF2F77F24C>