svn commit: r292823 - in stable/10/sys: conf netinet

[Patrick Kelsey]

> On Dec 27, 2015, at 11:06 PM, Andrey Chernov <ache at freebsd.org> wrote:
> 
> On 28.12.2015 6:45, Patrick Kelsey wrote:
>>> On Dec 27, 2015, at 10:26 PM, Andrey Chernov <ache at freebsd.org> 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.
> 

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 how much close attention is being paid to TFO at the present time.  The Mac OS X client works better, so it is not really a question of quality clients existing.  I have just chosen to be conservative in the initial release of this functionality based on my impression that the current audience for it is not 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 implementation to receive wider testing.

One thing to consider about RFC7413 that is not always apparent when first looking 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 when using TFO that cannot happen when using the regular TCP three-way handshake is that packet duplication in the network can result in application-level request duplication.  Because of this, TFO is only really suitable for applications that have some built-in mitigation for this or otherwise do not have to care about it.  This is discussed in the RFC.

Also, in my opinion, when using TFO, one has to accept certain ideas presented in the RFC about the relative importance or attractiveness to attackers of certain attack vectors that are introduced by TFO, or establish that your particular application can otherwise mitigate or tolerate them.  Again, this is not a general purpose, set-it-and-forget-it kind of TCP performance improvement.

-Patrick