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

[Andrey Chernov]

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.

-- 
http://ache.vniz.net/